Pushing Productivity Makes No Sense

Recently, I have been explaining agile to a medium-sized company dealing with insurance. It all went pretty well and I started to think that the managers get the idea. Then, an awakening question came when one of them asked “so, when we do this agile stuff, we will be able to constantly increase our productivity, right?”. Wrong.

I believe that the purpose of agile (or any sane leadership approach) isn’t to indefinitely increase our productivity. Let me pause there for a moment and explain what do I mean by “productivity”. My definition of increased productivity is: generating more output when the input parameters (such as number of people you have) remain constant. Once we have this definition, it is pretty obvious that there are some key things missing, right? Let’s focus on them in more detail.

Productivity increase does not bring increase in delivered value

If you deliver more stuff, it does not automatically guarantee you will deliver better stuff. Usually, the opposite happens, as when you try to produce more output with the same amount of people, you have even less time to think about the value of what you are delivering. The above is true unless you are talking about some kind of highly repetitive and mechanical tasks (where looking at productivity makes sense). That surely is not the case of software product development, as this is a highly specialized, creative and intellectual work.

Agile is centered around delivering value and delighting customers while being able to quickly react to change. Your customers surely won’t be delighted when you often ship them a lot of crappy features (or features they wanted a year ago). Firstly, they would need more and more time to learn these features (or learn how to get rid of them) — effectively blocking them from getting done the things they want to get done. And secondly — even if the features you deliver are actually the ones your customers want, there is a great chance they will be poorly designed — again blocking your customers from doing what they want to do.

Said in another way, you will increase quantity, but significantly decrease quality of what you are delivering. And by quality I don’t mean number of defects, but how usable your product actually is.

Pushing productivity deteriorates culture

If you impose productivity-increase mantra onto your teams, culture is going to suffer. By doing so, you are removing any slack time teams may have and you are preventing them from learning and getting better. This is similar to the known anecdote where the lumberjacks reply “we have no time to sharpen our tools, we are to busy woodcutting” to the person who suggests they actually stop, learn and improve.

Learning is another important part in agile. We want people to develop new skills, to help each other, to share knowledge. We want them to collaborate on problems, because this is much more effective and leads to better solutions in the long time perspective. Focusing on productivity does not help that.

Pushing productivity kills innovations

Similarly to the previous point. Innovation cannot be planned, it cannot be targeted. The best you can do is setup an innovative environment and wait patiently.

For innovation to happen, people must have some time to play with things, to look at problems from different perspectives. They need to have the time and environment to experiment and learn from their failures. This has nothing to do with productivity.

Pushing productivity doesn’t make employees happier

When you start pushing productivity, all sorts of negative and unwanted behavior may follow. Because maximizing output is the key measure, everybody will start doing just that — maximizing his own input, without caring about how he is contributing to bigger goals. It can even lead to people blaming each other — nobody wants to be seen as the least productive one, so if actual productivity is below the target, search for the sacrificial lamb will begin.

All of this does not make people happy at work. People generally want to do a good job (and they know how to do it). What they need is clarity on what the results are supposed to be, skills necessary to achieve them and trust to just get the work done.

The real success metrics are different

If productivity is not a measure of success in software product delivery, what is? Well, here is a list of things I use to measure how well are we doing:

• Shorter delivery times for the most valuable features that make the difference for our customers.
• Constant flow of good and innovative ideas coming from the teams.
• Technical excellence and code quality.
• Happiness of people working in the company and their engagement.

If we focus on these instead of productivity, we will achieve much better results, especially in the long-term perspective.