Does work in progress matter in software?
A key barrier to effective delivery is Parallelism – teams working on multiple items at once. A highly tuned team will focus on a piece of work to complete it and deliver it. Everyone in the team knows what the most important work is and where the priorities lie. And everyone is contributing to making that happen.
But many teams lose that focus. Instead they are working on multiple features in parallel. This may seem harmless. There is a tendency to think that all work is good work and that being busy is sufficient. But unfocussed work can be expensive.
Being busy is not enough
What is Work in Progress?
Work in Progress (often abbreviated “WiP”) refers to any work which has been started but not yet completed. Lean views work as a continuous process. Although applied to software this is inspired initially by manufacturing. Because the work has started it has incurred a cost. However, because it is not yet complete it has not realised a value.
WiP in manufacturing
It is very obvious in a manufacturing environment that incomplete products cost money. We buy parts and sell integrated products. Every incomplete product represents a set of expensive parts sitting in a factory.
Let us imagine that we are making cars and that our car sells for twenty thousand dollars. Every car has a bill of parts which cost ten thousand dollars. We could make our first car, for which we borrow ten thousand dollars to cover the parts cost. We sell the car for twenty thousand dollars. That gives us the money to pay off the loan and make a second car. After that we are in profit. Working on individual items we have a good profit margin and are rapidly making money.
But what if our factory has a long production line with a thousand cars in the process of being built? Our “Work in Progress” is a thousand cars. We need to borrow a million dollars before a single car rolls off the production line. This gives a million dollars of debt. Then we need to sell five hundred cars before we pay off the debt. What about the interest on that debt? And what about the cost for a factory with space for a thousand cars in various stages of production?
Cost and complexity is far greater in the second example. And yet the basic finances are the same. All of this has increased because we have a substantial level of Work in Progress over the simple model of making one car at a time.
A half-built car simply ties up resources that could be used to create value or save money.
Jeff Sutherland
Anything that’s ‘in process’ costs money and energy without delivering anything.
Work in Progress in software
In the virtualised world of software, the cost of Work in Progress is often overlooked. But the situation is very similar. It is just far, far less visible in most organizations. Cost in software development is almost entirely down to people (and associated development costs such as licenses or compute resource). If we make one new feature that takes ten weeks of effort we have invested a cost equal to a quarter of a year’s salary for an engineer. We then ship that feature to customers. Assuming it is a valuable feature we start seeing a return on the work. This is the equivalent of our “one car factory”.
However, few businesses have only a single feature being developed. In our scaling start-up organization, how many incomplete pieces of work are there? How many are there in your organisation? There are projects that have been started and then deprioritised when something more important came along. Each of these took some investment but have not been finished. Imagine if rather than our single item we work on a dozen items at once. Now we have three years’ salary invested before we deliver.
As with the car-making example, initial costs have increased, time to realise value has increased, and customers are seeing less responsiveness.
Good Practices
Excessive Work in Progress will increase the cost we spend before we see a return. It also increases the time before customers see our product. These go wholly against the ideas we are trying to promote with Agile development. Agile, as the name suggests, should enable responsiveness. A backed up queue of work does not encourage this.
We should constantly review and report on how much work teams have in progress. Individual teams should avoid working on multiple features and individuals should avoid context switching.
Teams are rarely familiar with the concept of Work in Progress and you may need to coach them about why this is important.
Leave a Reply