Your Agile Process is not a Template
I spend a reasonable amount of time on discussion groups talking about agile process. Nothing will make you think more about the Agile manifesto and the twelve principles of Agile better than being presented with problems and contexts that you haven’t encountered first hand. I have encountered my fair share of issues, problems and pains dealing with people on groups, but what I’m talking about here strikes to the very heart of the problem with some Agile practitioners.
The problem I’m encountering more and more is that people are performing the rituals of Agile and handling the artefacts of Agile with insufficient understanding of the principles of Agile.
Basically, people are running stand-up meetings, retrospectives, planning sessions, and wielding stories with points on, and creating teams with the right people on… but they don’t know why they are doing any of it.
In some cases, they have previously worked on a successful team and are emulating the agile process that was used. In other cases they are running things “by-the-book”, blindly applying rules regardless of the context. A common source of this “looks like Agile, isn’t Agile” problem is when people come from a heavyweight method and try to standardise what they see as another kind of procedure.
In any of these cases, they are doing it wrong.
Here is a paraphrased version of a “success story” that shows this problem in action (original story on Leanblitz): One of several teams were allowed to experiment with their process to see if they could make it better. The result of this experiment was that customer satisfaction went up, profits went up and waste went down.
“…the owner was happy. He was so happy, in fact, that he instituted our ideas into the other [teams] – a sharing of a best practice.”
Oh dear. The whistling noise this one makes as it misses the point is almost deafening. That isn’t to say the company is doing it all wrong, they are just missing the point a bit.
If you truly want to emulate the success of “Team 1” in this story, you can’t take the output of their experiment and enforce the best practices on the other teams. The valuable part of what “Team 1” did is not a checklist or process. What made “Team 1” a success is that they were given context (make customers happy / make the company more efficient) and then left to work out how to do it.
The correct way to make the other teams a success would be to let them do the same experiment.
I would expect every team to improve when working out their own process. They may improve to different extents, but they will all improve. When the different teams sit down together and talk about their different ways of solving the problem, they can start to introduce other ideas and help each other to become even more effective.
You want people to work in a better way – but you want them to learn how to discover better ways for themselves so they can continue to improve the process.
This is why you’ll find these two principles behind the Agile manifesto…
Principle 5: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done”
Principle 11: “The best architectures, requirements, and designs emerge from self-organizing teams.”
But this isn’t just about two principles. It is about 12 principles and a manifesto that fronts them. I challenge you to judge your own practices against the Agile manifesto in order to better understand why you are performing the rituals and to better understand what will make them work.