I was reading a bizarre post on Linkedin Pulse about some wacky new system for story point estimation. The details of it aren’t interesting or important. What is interesting is the motivation behind it.
The imaginary problem that many people think needs to be solved is that traditional managers, when moved (kicking and screaming) to an Agile environment, will need some quantitative management system to measure, compare and control their teams.
This is nonsense and one of the clearest signs that the organisation doesn’t understand agile and doesn’t want to do it. They just want to do traditional software development and management but call it agile).
The traditional curriculum of management, still being taught at universities around the world, has not really changed in over 100 years. Not since the publication of Frederick Taylor’s Principles of Scientific Management in 1911. The core ideas of Taylorism is that:
This is all of course ridiculous. The people best qualified to understand and define the work are the people who do the work, not the people who manage the people doing the work.
The Japanese figured this out (well not really, they actually learned it from an American named Deming) and this idea forms a key part of the Kaizen principle of continuous improvement, the holy grail at the heart of Lean Manufacturing.
The workers need to be in charge of their process and the improvement of that process. The job of managers should be to ensure the workers are able to do their work and continuously improve their doing of the work. This model, in contrast to “command and control”, is sometimes called “Servant Leadership”. The leaders are humble servants to the people doing the actual work.
You can think of taking a traditional organisation chart and turning it upside down. The workers, creating direct value, are at the top of the chart. The managers are underneath them, supporting them.
Another fallacy of traditional management theory is that you can’t measure enough things, especially the internal workings of the company. Jack Welch, who was for a long time CEO of General Electric and the poster child for traditional management in the last 50 years, famously declared “if you can’t measure it, you can’t manage it”. Catchy book titles tell us we can “measure anything!!!“.
Now I’m all for collecting and analyzing external metrics. How many customers do you have, which buttons do people click on your website, how long does it take for a web service call to run through your stack. How much memory do the app servers have under peak load. These are valuable measurements that can and should drive decisions.
The problem is the obsession with measuring the internal workings of the business: how many “function points” (don’t get me started) can your team build, how much “value” has this project created, how much “quality” did that team build into the app. These measurements can easily end up being used to compare people and teams, usually with unhappy results.
The problem with these “performance” or “efficiency” metrics isn’t just that they can be used to pit teams against one other or to denigrate people, or that they can be easily gamed. The main problem is that the data they are based on are generally useless.
Anyone with a rudimentary understanding of science or statistics will tell you that measurements are only valuable if they are controlled. More specifically: any kind of experiment generally has a dependent variable (the thing we are trying to measure), an independent variable (the thing we are changing to see if it has an effect on the dependent variable), and a bunch of other variables, which need to be controlled, i.e. they need to not change.
Say you are measuring the effect of increasing temperature (independent variable) on bacteria growth (dependent variable). You need to make sure all other factors in the environment are kept unchanged, otherwise, those variables could be skewing your results.
In an agile context, you might want to say, measure the effect of increased unit testing on velocity. But there a hundred other variables in the mix (the stories you’re working on that sprint, the health of your test environments and data, who is on leave that week, etc.), and those variables cannot be controlled. And if you can’t control those variables, your measurements are basically useless.
There is a disturbing trend for velocity scores of scrum teams to be seen as a sign of how “powerful” or “efficient” the team is (it isn’t really), that you can compare velocity scores of teams to see which is the better team (you definitely can’t) and that you can conduct experiments on how the teams work and see the results in changes in their velocity (not possible, too many uncontrolled variables.
I came across an anecdote (it rings true to me) that Ron Jeffries (one of the founders of the Extreme Programming movement) said “I am truly sorry that I created story points. They are now rarely used for their intended purpose of guiding the team in forecasting, and instead, are used pathetically by management as some form of performance measurement. Sad.”
So does an agile software development house need any kind of managers? Project managers? Line managers? Technical managers? Product managers? Financial managers? This is a huge topic that would require many posts to cover.
In short, any sufficiently large organisation will possess enough complexity and governance that some people with the job title “manager” will be required to function effectively. The important thing is to remember that their job is to support the people doing the work, not the other way around. Give people the tools and resources to do their job, and get the hell out of their way.
Question: have you worked in an environment where teams were measured and micro-managed by people who didn’t understand the nature of the work the team was doing?