5 ms·
I've only experienced Agile lengthening delivery cycles, but more critically Agile also greatly reduced quality, because the lack of global context and long ter
by p4wnc6 11y ago
I've only experienced Agile lengthening delivery cycles, but more critically Agile also greatly reduced quality, because the lack of global context and long term planning caused the products to suffer. All of the micro-planning to make tinier-scale adjustments merely sounds like it should incrementally improve quality. But when your short term sprints aren't informed by long-term planning, what happens is more like a random walk. Some sprints randomly add quality; some randomly reduce quality, and overall quality grows slowly, like sqrt(n) due to this random walk effect.
I also see a lot of this No True Scotsman fallacy of saying "when implemented correctly" that Agile, seemingly by definition, cannot fail.
The teams I've seen be most effective at delivering quality products quickly always just created their own methodologies, and they would scrap them and change them often particularly based on changing needs of the project, new personnel, and so forth.
Instead of the Agile approach of trying to say there is a one-size-fits-all / cookie-cutter solution (e.g. just use this timeframe for every sprint, just use this way of dividing up work for every project, just use this way of measuring progress for every team, ...), productive teams seem to negotiate this stuff organically, and with common sense.
Even teams that nominally used Agile but still managed to be productive did so precisely by only adhering to Agile as a ritual to appease managers, and outside of what managers wanted to see, the teams just eschewed Agile and found ways to be productive in spite of it. That may not be true everywhere, but it informs my experience in three different Agile organizations of varying sizes and ages.
- crdoconnor 11y ago>I've only experienced Agile lengthening delivery cycles Where agile is defined as what?
- p4wnc6 11y agoAttempted pure adherence to the commonly stated Agile principles, via common scheduling and reporting events in Scrum. Any vague attempt to do that, even with customization and variation within a given company, has always resulted in the same unplanned mess of randomized sprints and burndown graphs.
- bluejekyll 11y ago> saying "when implemented correctly" that Agile, seemingly by definition, cannot fail Poor choice of words, you are correct. And I actually agree with what you're saying in the rest of that response. Allowing scrum teams the ability to decide how to work together is huge, and I think correct as you point out some of the benefits of that. Rigid inflexible systems are horrible. One thing that I know puts me generally in conflict with most agile purists is that a sprint should only have a time estimate component, and not a firm end date. Shoot for two weeks,but if it's three so be it.
- p4wnc6 11y agoSometimes things need to be on a different order of magnitude than a few weeks. Sometimes a single sprint should be months, especially when the subtasks involved require novel research and pilots / prototypes (which is way more often, I find, than what typical "Agile thinkers" believe is true about business projects). You just cannot know what will be hard or what reasonable time estimates or how to divide up the work until you begin trying things for a significant amount of time and hitting the unanticipatable failure cases. Agile is great in small, well-controlled cases where the path to a solution is easily seen by everyone to consist of commoditized, been-done-a-million-times-before tasks. But the issue is that once you use the Agile hammer, now everything looks like a we-must-solve-it-in-only-the-been-done-a-million-times-before-and-fits-into-sprints nail. The other big thing is that so, so few Agile implementations are remotely like the Agile ideal that we should probably stop pretending there even is an Agile ideal. If everyone using a given tool consistently messes it up in the same ways, we should just stop trying to defend the tool and admit it's the tool's fault for being intrinsically easy to misuse/abuse, and seek to invent better tools that make it very hard to misuse/abuse them.
- bluejekyll 11y agoI don't think I can agree that things should be months long. You build in discovery at different points in the project, aka spikes. It should be possible to come up with tasks that can be accomplished in roughly two weeks. If you break it down, you probably already do this: 1) get build for project going, 2) get initial config/entrypoint for system up, 3) implement stubs for API, etc... you can break it down, but each of those is a constrained set of work. It might be part of a very large project that can't "ship" at the end of two weeks, but you can verify different components along the way. It also is a helpful exercise to allow for multiple people to collaborate on different portions of the problem.
- bmm6o 11y ago> the lack of global context and long term planning Just because you're iterating on 2 week cycles it doesn't mean there's no vision, direction, or planning on a longer time scale. The "backlog" user stories have to come from somewhere, right?