> At the hands of an uncreative person any tool will be the wrong tool. This is what people fail time and time again to understand.
I think most commenters on HN understand this.
But then what problem does capital-A Agile solve? It was meant to surface problems faster and empower people in teams, and benefit the customer, avoiding waste and nasty surprises. Yet we've seen enough horror stories in these past decades to understand Agile (Scrum et al) can fail just just as often and is as prone to mismanagement and meddling as the methods it was meant to replace.
It takes a strong team (leadership and stakeholders included) to make Agile work and reap its benefits. But such a strong team will probably work well with whatever methodology -- strong teams are effective regardless.
What about average teams, which Agile was supposed to be helping? In my experience, they'll fail just as often.
A method that works for a team of focused superheroes is not really applicable to the general population of developers.
Capital-A Agile is for companies that want the benefits of agile (higher velocity) but don’t want to trust their employees or make any meaningful changes in how the management team operates (micromanagement, committing to rigid feature scopes on rigid schedules).
Obviously this doesn’t increase work but companies get to say they are “agile” and the management team gets to keep doing all the counterproductive management they were doing before. No hard conversations about changing how management operates or unpredictable things like giving engineers autonomy.
This sounds cynical on its face but it is my experience as well. Management does not actually trust engineers to provide value without close oversight (sometimes with good reason!), so any framework that purports to give engineers more autonomy will eventually be subverted by the management. And since management always has more power than line engineering, they always win.
The only way for "true" agile to really take root would be for management to trust engineering to add more value on their own than when being micromanaged. That's a tall order, and gets much taller in larger organizations.
Agile is not there for higher velocity! It is sold to management that way often, but intrinsically - no.
Agile though is meant to reduce waste. In other words, you don't march faster, but are supposed to spend more time marching in the right direction. (I personally loathe agile and find it intrinsically broken.. I just find it kind of funny that a process oriented around dynamic environments is supposed to give predictability and speed, when it gives neither. If anything, a lack of predictability since direction can change)
I think most commenters on HN understand this.
But then what problem does capital-A Agile solve? It was meant to surface problems faster and empower people in teams, and benefit the customer, avoiding waste and nasty surprises. Yet we've seen enough horror stories in these past decades to understand Agile (Scrum et al) can fail just just as often and is as prone to mismanagement and meddling as the methods it was meant to replace.
It takes a strong team (leadership and stakeholders included) to make Agile work and reap its benefits. But such a strong team will probably work well with whatever methodology -- strong teams are effective regardless.
What about average teams, which Agile was supposed to be helping? In my experience, they'll fail just as often.
A method that works for a team of focused superheroes is not really applicable to the general population of developers.