If "Agile" results in extra layers of bureaucracy and more meetings, that's a great sign that agile is being done terribly wrong. Which, to be fair, is very very common.
Remember the manifesto:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
My thought to every line quoted is "why?" What are the actual principles involved, and why don't we just jump straight to those when making process decisions? Manifestos do more harm then good because their vagueness enables reinterpretation.
> Manifestos do more harm then good because their vagueness enables reinterpretation.
That totally relates to my experience.
I've seen this scene repeated over and over:
- project begins
- something happens and delays the project (arrival of new team members who need some time to learn about the code base, for instance; it's not even an issue, it's just a natural consequence which makes the project go different than planned and put certain kinds of managers in distress)
- project start to get behind of the schedule or whatever tool in use to track progress
- "you are not a true Agilist"
I just can't understand why is it so easy to blame the old methods while it's so hard to identify weaknesses in the current ones.
Besides, the room they left for interpretation leads to a good amount of bike-shedding and witch hunting as soon as something goes wrong in the project -- if one assumes the method is perfect, the only possible explanation for a failure is that the method has been misfollowed.
I think when Agile is finally replaced by something else it will be because of:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Nothing in Agile has actually overcome the problems of horizontally scaling a team, and things like this stand in the way of scaling one vertically.
Scaling developers vertically requires having support tools, processes, and people to get past the things that trip them up and back to forward progress. They don't have to be big tools, or big processes. In fact it's much more important that they be reliable than that they have huge feature sets.
But Agile without tools and processes? Show me anyone who is pulling that off, and I'll show you someone who has mislabeled a bunch of things as 'not-tool' and 'not-process'.
The difference is one of intent. Having tools or processes to have processes is a bureaucratic mess which they Agile folks rightfully wanted to cut with a scythe. Sword. Scary sharp thing of your choice.
There's a difference between building tools and process, and building a culture of toolsmiths and process tweakers. The latter, I think, follows the spirit of Agile but not the letter of it. And lean is just... throw the baby out with the bathwater. It's bureaucracy as written by a minimalist.
> “If "Agile" results in extra layers of bureaucracy and more meetings, that's a great sign that agile is being done terribly wrong. Which, to be fair, is very very common.”
It’s so common that it’s been branded: SAFe, and it’s a complete abomination.
Remember the manifesto:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan