5 ms·

When companies lose value (or are overvalued) why don't we ever highlight it when they use Agile / Scrum? Since those techniques are expressly marketed as value

by p4wnc6 11y ago

When companies lose value (or are overvalued) why don't we ever highlight it when they use Agile / Scrum? Since those techniques are expressly marketed as value- and productivity-enhancing techniques, I think it's very fair to call out attention to cases when they aren't working. Of course there are confounding factors. Maybe Agile/Scrum are working well in Tumblr but other things are keeping them from achieving their higher value. Or, maybe Agile/Scrum bleed away productivity and fail to extract value from engineers. Or maybe it's a mixture. In either case it seems useful to point it out, ask questions about it, and so on. We shouldn't let Agile-adhering failures go un-called-out, whatever the post-mortem analyses might bring.

bluejekyll 11y ago
What methodology do you subscribe to? Agile, when implemented and executed correctly, really just shortens delivery cycles and allow for small corrective changes along the development path. What it's best at is delivering a product that more closely aligns with needs, than something like Waterfall. In many cases the overall delivery time might be longer with agile, but the correctness of the project is better. Which means less QA at the end of the cycle, and more throughout the entire process.
- 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 ago
      Attempted 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 ago
      Sometimes 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.

by p4wnc6 11y ago

bluejekyll 11y ago

What methodology do you subscribe to? Agile, when implemented and executed correctly, really just shortens delivery cycles and allow for small corrective changes along the development path. What it's best at is delivering a product that more closely aligns with needs, than something like Waterfall. In many cases the overall delivery time might be longer with agile, but the correctness of the project is better. Which means less QA at the end of the cycle, and more throughout the entire process.

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 ago
    Attempted 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 ago
    Sometimes 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.