Productivity Focus

It seems that product development organizations care about productivity the most. This is reflected by the common misunderstanding about adopting agile development for higher productivity while agile development is about flexibility and adaptiveness. In this article, we will take a look at why focusing on productivity is often not a good idea, and surprisingly, focusing on others, such as value, quality, speed and flexibility, eventually leads to higher productivity.

There are a few challenges for productivity focus. Firstly, what is the measure of productivity? For knowledge work, it is not as simple as counting the number of items produced in the factory. We have tried the lines of code, the number of features, and so on, produced per time unit. These are useful to some extent, but focusing on them often leads to local and short-term optimization. In order to deliver more features or lines of code, we select only those familiar features or tasks, and we take shortcuts. We may get higher productivity in the local view and short term, while we suffer in the whole and long term.

What are other focuses in product development organizations? Let's look at value, quality, speed and flexibility, as well as how they relate to productivity.

Value vs. Productivity

This is about outcome vs. output. Outcome is the value, while output is the feature. Usually, we define productivity in terms of output. There is a sense of futility when talking about that we should focus more on outcome. Everybody on the development side agrees easily that this is a major problem, but unfortunately they can't do anything about it.

The silo between product/business and development seems the thickest and deepest, however, this is also where change can have the most leverage. We simply develop too much low-value stuff, partly because it is inherently difficult to identify value, partly because that we are not disciplined enough while exploring and validating value. By the way, agile product development is supposed to increase our discipline via short feedback loop. If we can stop developing half of the low-value stuff, we will have more time to develop those high-value ones with higher quality.

Quality vs. Productivity

It is common that development organizations sacrifice quality in order to meet schedule. The productivity seems improving in the short term, however, productivity deteriorates further in the longer term, exactly because of bad quality. How do we respond by then? We sacrifice quality even more. This is perhaps the most ubiquitous vicious cycle in our industry.

We seem always lacking time to produce quality, but always having time to fix quality. While the defects shipped to users impact quality, the defects found then fixed internally impact productivity. Actually, as there is no easy way to directly measure productivity, I usually suggest to take the number of internal defects as one of the proxies for productivity, because it indicates rework. So, instead of sacrificing quality for productivity, we ensure quality for productivity. In my old days as the quality manager, there was tremendous pressure on meeting schedule in our organization, and my favorite comment was "when we focus on schedule, we don't meet schedule (as our quality suffers, then schedule slips further); while when we focus on quality, we meet schedule too".

Speed vs. Productivity

People often mix up these two concepts - speed and productivity. When they say that they want to go faster, they really mean that they want to produce more. The former is the speed in terms of cycle time, and the latter is the productivity in terms of throughput.

The end-to-end cycle time is critical for product development, not only because it decides when the value is delivered to end customers, but also because it decides when we get feedback for adaptation. How can we reduce cycle time, even with the same throughput? By focusing on the high value work and limiting WIP.

In the book "this is lean", it introduces the above efficiency matrix, which distinguishes flow efficiency and resource efficiency. Behind it is customer focus (speed) vs. resource focus (productivity). Interestingly, the strategy advocated in the book is first focusing on flow efficiency. As improving flow efficiency can reduce a lot of superfluous work and waste, it improves resource efficiency too.

Flexibility vs. Productivity

In my experience, flexibility is not something most organizations focus on, even though It is the means to maximize value in uncertain environment, thus the essence of agile development.

Over-specialization in various dimensions is probably the biggest obstacle for flexibility. It is perceived more productive to keep working in specialized areas, however, it is a local optimization, leading to delivering many features with low value - rarely or never used; or even worse, high amount of WIP - partly done features never delivered to users. How do we break down the over-specialization? Via multi-learning. I have described this topic in the series "Number of backlogs and multi-learning". Although multi-learning is aimed for flexibility, the broad knowledge coming out of it also enables more effective collaboration and integration, which helps productivity as well.

The focus on learning s worth further pondering. Don't we need to learn and improve in order to get more productive? Indeed, if our focus on productivity means the focus on learning, then, it is a good idea. We train and coach developers to write clean code and tests, and help them adopt modern engineering practices. However, this is not what most people usually mean when talking about productivity. Upon a bit reflection, it is common that focusing on productivity means to deliver more by adding more pressure and working longer hours, rather than learning and removing impediments.

In summary, if the productivity focus means to help developers learn and improve, go for it! Otherwise, we'd better focus on:

• value: because only doing high-value work, we have the time needed to do our job properly
• quality: because producing fewer defects, we have less rework
• speed: because flowing better, we have less waste
• flexibility: because expanding knowledge scope, we have more effective collaboration and integration

then, productivity takes care of itself.