Engineering leadership · Book notes
The Agile Manifesto won and became the process it fought
The manifesto was a great critique that won so completely that big-company Agile grew the same scar-tissue rules it was written to tear out.
I think the Agile Manifesto has been completely a victim of its own success. This was absolutely a contrarian movement when it started. From what I understand about how software used to be developed, everything about Agile seems to be an improvement over it, from these massive waterfall projects.
The Manifesto for Agile Software Development is a single page. It was written by 17 people in a ski lodge in Snowbird, Utah, in February 2001. It contains 4 pairs of values, the first of which is “Individuals and interactions over processes and tools.” The entire argument is contained in the single line beneath them: “While there is value in the items on the right, we value the items on the left more.”
I think like all revolutionaries, they’re very good at critique and very, I would say, debatable on implementation of their utopian future.
This kind of fits.. The manifesto is a critique of how we build software, and it’s a good critique. But nobody at the lodge has documented how a large company with hundreds of engineers actually runs this on a Monday morning.
People say true Agile has never been tried. There is some truth to that, but there’s also truth to the idea that if it hasn’t been tried yet and it’s been 20 years and everyone and their dog says that they use Agile, then maybe there is no such thing as true Agile.
If everyone claims it and almost nobody does it, I think the definition is the problem.
Let’s say you have a bad release that brings down production on a Friday. Your company decides to put a change board in place that approves every deploy. A year later, you have a sign-off form attached to the board. Nobody on your team remembers which outage that form was supposed to prevent.
The organization gets burned some point in its past, and they make a rule so that they can protect themselves from getting hurt. But that rule actually gets in the way of the fact that you’re now harming all of the autonomous and self-actualized software engineers that could actually be trusted.
This is where the “processes and tools” side gets back in charge, but with an Agile badge. People inside the movement saw this coming within ten years. After the Snowbird reunion, Philippe Kruchten wrote Agile’s Teenage Crisis?, describing how Agile had become like a teenager adopting fads and jargon, and offering criticisms including how commercial interests can mask failure. It reads as the movement running a retrospective on itself.
The rebels won. The rebels overthrew the empire and are in some ways the empire now.
And once the rebellion becomes the rule book, I always wonder what a team needs to get back from it. Do we need a new manifesto, or do we just need the nerve to delete the one rule that’s still guarding a wound that healed years ago?