Standardisation is the Enemy of Success
There is a pattern evident in business that is clearly destructive, yet keeps on repeating. It starts with a group of people doing something good, but ends in wasteful practices.
For example, some people on an administration team find that a check-list massively reduces their errors and re-work and essentially makes their customers happy. They share the idea with other teams and some of them decide to do the same. Then standardisation happens. Everyone is told they are going to use check-lists. Then a template comes out. Then all the check-lists get placed under the control of a team who will ensure they are controlled and that teams are audited to ensure they are complying with the check-list.
I’m sure you can spot that we have over-shot the sweet spot by quite some margin.
Are check-lists the right answer to the problems faced by all of the teams? Not likely. Do check-lists actually slow some people down? Almost certainly, especially once you start getting audited. Where should it all have stopped? The correct place for this to stop would be before you start “rolling out” and “standardising”.
This is true of any process, but when it comes to Agile it is also more important, because the manifesto includes two principles that should remind you about this.
Despite the utter clarity given by the Agile manifesto and supporting principles, standardisation keeps on cropping up as an issue. Why do two teams have different velocities? How do we make sure different teams mean the same thing when they say a story is small, medium or large? Why do we have different processes in different teams?
The answer to all these questions is because we know that standardisation is the enemy of success. Standardisation sits very nicely alongside “resources”. Standardisation requires resources, not people. Look around you – do you have resources, or do you have people?
The process should flex to suit the people, not the other way around. If one team finds that Fibonacci numbers ain’t working, they should be able to use something else. If one team finds that a three-week sprint works better than a four-week sprint, that’s fine too.
It is when we try to standardise that we ruin all of the good work that Agile has done and standardisation is just command and control – and we recognise that command and control is not Agile.
If a team is being effective, you have what you want. If they aren’t, you bring it to the retrospective and they will work out how to change what they are doing to make it effective – and you’ll give them the time they need to experiment and adjust their process in order to become great.
And this is where I am drawing the line. I refuse to call something Agile when it is implemented from the top or standardised in an effort to make “management” easy. Management isn’t easy, because every person is different and you need to get to know everyone who works with you to work out strengths and weaknesses and aspirations. That takes effort, whereas standardisation is easy.
If you want great results, though, perhaps you’ll realise you need to avoid standardisation vigorously.