Writing code is not the same as fitting nuts and bolts onto car parts. It is not a mechanical skill. It does not involve repetitive actions. Building great software requires creativity. Yet, we are so keen to pursue processes influenced by manufacturing paradigms. The lean principles outlined in Mary and Tom Poppendieck's book Lean Software Development, have been widely interpreted and applied without context to software development. Even the Kanban method (which is essentially a way of managing the supply of components in Japanese manufacturing based on pull or capacity to work) can rarely be applied to the context of software development without sufficiently modifying the paradigms to suit the nature of software development itself.

Manufacturing deals with repetitive tasks, equal-sized chunks of work and supply and demand that can be predicted/tweaked based on trends and optimizing process scheduling, assembly line structures , and so on. The question is, what do we gain by measuring throughput (amount of work done in a given cycle/period of time) in software product development?

An often-quoted example of Goodhart's Law is about the nail factories in the Soviet Union. When the factories were given a target, based on the number of nails manufactured, the operators produced plenty of tiny nails. When targets were based on the weight of nails produced, operators produced heavy nails. In both cases, the nails were useless! With software this gets even trickier. There are some parts which are very automation-friendly (repeatable and rule-based), while there are others where creativity and ingenuity matter a lot. Throughput measurement only makes sense when you want to reliably predict when things will be done. This is possible only when there is some aspect of repeatability.

In a similar way to the Soviet nail factories, I have heard quality analysts in software teams tell stories about how their performance appraisal was based on the number of defects found. They would then go about finding every sort of defect. Instead of working with the developers to try and find solutions to deliver value, the focus was on maximizing bug counts.

Can we measure throughput for creative, artistic ventures? I can best explain this based on my artistic interludes with painting. Painting requires some preparation, such as choosing the right paints and material, getting brushes ready, priming canvases, and so on. Then there is the creative part of painting itself. The preparation part is repeatable and can be handed off to someone with no artistic skills too. It can be done by a robot. I can more or less predict my cycle time in the preparation part. However, if you attempt to predict how long I will take to complete my painting, you're bound to fail. Even if you have all the data about my past paintings and how long I took to complete each of them, there is a big variable that you cannot account for: me.

Even when the technique of painting can be taught, the creativity and flair is highly influenced by the artist's personality. For instance, when I am in the groove, I paint with much speed and abandon. When I am not, I may be slow and deliberate, or I may churn up strokes that need a rework or I might just start all over. There are phases in the painting when I have to be slow and deliberate, especially with the finishing touches. There are then phases when unrestrained creativity must take over.

Choosing the painting media can also be very personality-centric. The media (for example, paints) that we choose and how well we work with them, can depend on our personality. I tend to experiment with a lot of media — acrylics, water colors, oil and charcoal. Each medium has a characteristic, in terms of how pliable it is, how soon it dries, how much control we have over the medium , and so on. For instance, oil, paints are extremely pliable and so they are wonderful to work with, but they can take forever to dry. Acrylics, on the other hand, dry fast and they are somewhat pliable like oils. Now, the medium that I choose and my personality sort of decide how long I will take to paint, and also how I want to plan my paintings. I know for sure that I cannot predict my cycle time when painting.

Software development is not very different from producing a painting. There are aspects that are repeatable and need technique, which can be taught. There are also aspects that require expertise, creativity, and flair. While some ideas from process optimizations in manufacturing can apply to software, we need to be cognizant that software development is largely a creative field. There are small pockets of repetitive work, and those can be automated. For instance, regression testing of an application can be automated. However, measuring throughput from a regression testing suite is as absurd as measuring throughput from a software developer writing code for a custom business need.

There are phases where you should build with abandon. There are also phases where you should be slow and deliberate. All of this should work in tandem, and with great orchestration among dissimilar personalities. People bring relationships, trust, and personality to a team. There's no framework to predict how passionate, creative people can make magic. There's no magic pill that can measure human potential with numbers and graphs. Any process framework that treats its teams as less human will always fall flat on its face. Undermining people will get us 'hands on board', but not commitment.

The core Agile principles capture the essence of this: "Individuals and interactions over processes and tools." However, we have translated that into frameworks that have created meaningless processes and tools. A process framework should be for organizing stuff, not for predicting people or measuring productivity. Typically, throughput measurement is needed when we want to accurately predict when we can deliver a piece of work. We have become quite adept at defining our piece of work in terms of user stories and comparing the size of user stories in terms of story points. However, in software development, the specific team context, business/technology domain, culture, and individual personalities can have a bearing on how soon or late a piece of work can be delivered. Two user stories estimated to be 'small' are comparable, but are not the same. They may or may not take the same time to build.

Even the same story, if developed by another developer, could take less or more time. In a setup where budgets and scope are fixed, knowing how long it would take to develop the given scope, without burning budget, is important. For instance, software consultancies and services may need to justify throughput, in terms of working software delivered versus hours clocked, especially when in a time and materials contract. Hence, the emphasis on velocity, iterations, cycle time, time sheet management, and so on.

Today, even consultancies are moving away from time and budget-based models to outcome-based, income-sharing type models, where human productivity is no longer measured by number of hours clocked, but by the value of the product that has been created. So, in products where the scope is evolving based on customer/market demands, and budgets are decided based on the business' capacity to make revenue or raise investments, the emphasis should be less about time taken to build, and more about the impact that we can create. The smarter we are about delivering impact, the easier it is to move forward as a business. We need to recognize that measuring throughput isn't the best use of a product team's time. Throughput indicators don't matter for products. Outcome indicators do.

So, why should product teams have any process that measures throughput? Now that we have outlined the three basic reasons for process wastes, let's look at some solutions for tackling each reason discussed above.