Why Process Standardization Is a Terrible Idea
One of my colleagues wants to standardize all his agile teams on one process. He happens to like iterations, so he wants everyone to use two-week iterations. He wants them to use Scrum rituals and ceremonies.
I understand what he wants to accomplish: gaining the ability to look across the projects and see the same metrics, when teams are stuck, and progress across the organization. That makes sense.
But the teams do not work on similar projects. Some projects have interrupting work in addition to their project work. Some teams aren’t cross-functional, so they can’t deliver features on their own. Some teams are geographically distributed, so the Scrum ceremonies and rituals don’t work because the team members are in too many time zones.
Each team will need its own way to deliver value.
Ask for Results instead of Standardization
My colleague is not bone-headed. He is, however, mistaken. It rarely makes sense to standardize on one process for all, unless all the teams and all their work is the same. Instead of standardizing the process, look at the results you need.
My colleague thinks velocity charts will tell him what he needs to know about progress and productivity. But velocity is a measure of capacity, not productivity. Each team has its own unique capacity. Capacity can change over time for any number of reasons: team members change, the team works in a different area of a product or on a new product, or team members might be on vacation. Measuring capacity is not useful.
On the other hand, measuring throughput—results, as in running, tested features you could release—is the essence of what teams produce: their results. Teams can measure what they complete and when they complete it. If it’s useful, the team can measure the cycle time (on average, how long a feature takes to finish) and lead time (how long it takes for a feature to go from ready to the customer).
Then, if a team has trouble, you can see what options you and the team might have to increase the throughput. They might be working at maximum throughput because of their geographic distribution or because of the part of the product they work on. Just as you cannot change the number of hours in a day, you might not be able to change a team’s throughput. Once you measure running, tested features, you can see results and consider options.
Optimize Each Team’s Process
Back in the plan-driven days, many people focused on the overall project process because they could not see results until the project was mostly done. We had no other way of measuring the project.
Now, if you’re agile, you can ask the teams to optimize their process with retrospectives so they can deliver results in the form of running, tested features.
You might want to standardize some parts of your product development: a look and feel for the GUI, how teams use the API, or product problems that require collaboration across the organization. But the process? No. Let each team optimize for its unique problems and throughput.
