What is WIP and when is it a problem?
WIP means Work in Progress (or “Work in Process” for the lean folks out there). You already knew that, but what it actually means is “work that has started but has not yet completed”. That is a simple and useful definition.
But why do we need to talk about WIP, and why are all these lean & agile coaches obsessing about it all the time? Here’s a super short version of the answer: speed. Don’t worry, let’s also provide a more useful but slightly longer version of the answer.
Inventory
In manufacturing of physical stuff, there’s the concept of inventory- stuff made that has not yet been sold. Inventory used to be considered an asset, because it was just waiting to be transformed into money. Then some lean folks came along and realised that this stuff was actually just sitting around taking up space, and should be considered a cost instead. Not only that, but what if demand dramatically surged? Then all this inventory would be complete waste! So, managing inventory became a crucial part of lean manufacturing. The trick is to manage the balance between supply and demand. When your supply is at a higher rate than demand, your inventory increases (which is bad beyond some limit). If demand is higher than supply, it’s also bad. The limits and thresholds depend on context and the changing environment, but the best solution in theory is when the time it takes to produce something is so short you can do it “on demand”. This way your inventory remains close to zero. Of course, this then invokes all the concepts of how to keep creation times (cycle time) low, how to scale production up and down, etc. Ok, we’re done with manufacturing, let’s see how this translates into software.
Software Inventory
What does even inventory mean in our world? The general notion still applies; inventory means stuff created that does not yet generate value (we might extend it to include not only the generation of value, but also the protection of existing value).
Often the code we write makes up pieces that need to go together in order to realise some value, much like in a factory where we might have different machines creating different parts of an entire product. Unlike in a factory, we rarely create the exact same thing twice, so we need clever engineers to create new parts and put them together when we make products. Until the product is put together and available in production, all the parts being created are inventory. Economically speaking, our need to keep this inventory low is just as real as in manufacturing. The longer we keep inventory, the more space it claims. In our case, it most evidently takes up cognitive space.
Work In Progress
As mentioned above, a way to balance inventory is to minimize the time it takes to produce the product. This allows for on-demand production, which theoretically keeps inventory close to zero. To do this we need to keep cycle times as short as possible, and this is where WIP comes in.
High WIP
High WIP is not a problem in itself. In fact, the ability to maintain high WIP without negative consequences can be translated to high capacity. So what are the negative consequences?
Started > Completed
When you start more things than you complete, your WIP increases. This means there are more things entering the system than exiting it (in a given timeframe). If we imagine a bucket with a hole in the bottom, and we fill it up with water at the same rate as water is running out, we have constant WIP; completed = started (equilibrium). As soon as we add more water than what is coming out, we have increasing WIP; started > completed. In this state it takes longer for work in progress to complete (on average), which is typically not what we want. So, when WIP is continuously increasing we continuously increase time spent in progress (cycle time). When WIP is stable, we can use cycle time to assess our capacity (how long work will take to complete, how much, etc). With increasing or unstable WIP, we cannot do that anymore. This is one bad consequence of increasing WIP.
Adaptability, Responsiveness and the Cost of Change
Another issue with (too) high WIP is the cost of change. When WIP is very high, it usually indicates the system is on or beyond capacity. A system at full capacity is very sensitive to shocks, and this is true for teams too. If the “shock” is a change of plans, a team with high WIP is less able to adapt to it, because it implies many things in progress just became waste or subject to significant change. In a factory, we’d see this very clearly when lost inventory is piling up in the junkyard, but in software it’s silent and hidden, but still there.
If the “shock” is an incident or similar, all the ongoing WIP is paying (in cycle time) for the time now spent addressing the incident. Similarly, if the “shock” is the sudden loss of team members or change in team dynamics, all WIP is paying for that. Lastly, if WIP is high because of siloing (when work is siloed to certain team members), the system is very fragile; when a member catches a cold, nobody can cover for the work and we get delays.
Here’s a common argument we need to address:
“What’s the difference between something having been started vs not started? If work is simply waiting to get started it’s still paying cycle time until it’s completed, even if it’s not actively worked on, right?”
This is true, but it relies on a critical assumption; that it will, or should, get started at all. Plans change and the decision to build X may or may not be relevant in a few months. If it is, we’ll start it, but the longer we can defer that decision the more optionality we can maintain. A quick detour to explain what we mean by optionality is justified here.
Detour: Optionality
In our context, optionality could be translated into “opportunities to make decisions”. As an example, if we are building foundational infrastructure to support a long term strategy, it would serve us well to maximise the opportunities to abandon it for something else, with minimum waste. This may sound silly; why would we want to do that? When we value our ability to make new decisions based on new information (market changes, opportunities, etc), we want to ensure we’re always ready to change direction. Having long running projects in progress hampers this ability to be responsive. In fact, the larger the project, the more critical it is we create “breakpoints” where we can stop and make a new decision. This is the core of iterative development, where we don’t want small increments only because of feedback opportunities, but because we want to maximise our opportunities to change our minds. There is an “old” software engineering principle that highlights this: “optimise for speed of change, not speed of work”. There is a cost associated with high optionality, which is the cost of making sure we are “done” as often as possible. We do this by being “always releasable” with CI & CD, by using XP practices such as TDD, by continuous refactoring, thoughtful APIs, separation of concerns and other practices and patterns optimising for small steps.
In an industry as volatile and rapidly changing as ours, we ought to treat optionality as a very valuable resource. In terms of process and ways of working, well managed WIP helps us do that.
Once work has started, it will claim cognitive and physical space, making up “inventory”. It introduces complexity, decisions, tests, documentation, and all sorts of things we include in software engineering. It prevents other things from entering the system, which may be more important. This is why there is a significant difference between delaying the start of work, and delaying started work.
“Multitasking” and the Cost of Switching
High WIP often translates into “multitasking”; we have many ongoing things and juggle between them. That is often detrimental to productivity, because of the need to context switch (the cost of which can amount to up to 20% productivity tax per activity!). For our purposes, this mostly happens when we have high WIP of different themes, doing a little bit on each of them. This may at times seem like a viable solution to handling many requests, but apart from the tax on productivity, it dramatically slows down each of the themes seen from their perspective.
From the point of view of a “project”, WIP has other implications. A team (or several) may certainly manage their WIP well, but from a value delivery perspective it is crucial to also keep an eye on the project point of view. Below is illustrated the impact of switching between different projects.
The topmost illustration shows an example where three projects are started and kept in progress roughly simultaneously. In this simplistic illustration it results in them also completing roughly at the same time. This is in contrast to the illustration below, where one project is run to completion before starting another. From a project perspective, the time spent in progress is dramatically reduced in the second illustration; the “pink” project completes in ≈33% of the time compared to the multitasking setup.
We could easily imagine an even higher impact of this scheduling approach, by simply invoking the cost of context switching:
Given available research in this area, the above illustration is probably also optimistic. In any case, it should be clear that if we want to optimise for minimising lead times of projects, we should sequence them. To tie it back together, this is another type of “WIP” (perhaps “Projects in Progress”?) that is related but not necessarily evident from simply looking at the definition posted in the beginning (“work started but not yet completed”).
As a last comment on the illustration, it seems that the gains for the “yellow” project are rather slim. While true, we need to remind ourselves that the decision to delay the start offers an increase in optionality. Given that we value optionality based on the reasoning outlined above, increasing the ability to change our minds about “yellow” for a longer time, suggests increased value in optionality. This includes the option to change the start order of “yellow” and “teal”, if need be. If we value optionality, this would be quite valuable indeed.
Reasons for High WIP
Bias for Starting Work
There are multiple reasons for why teams find themselves with more WIP than what is sustainable. A very common reason is that there is a bias for starting work. This is primarily a systemic issue, not a mindset or behaviour fault. In many operating models there is simply a lot of focus on planning (where we want to go), and quite frankly not so much focus on progress (where we are at). Paired with an impressive willingness to help out and support each other, it is simply very easy to fall into the planning fallacy and as a result start more work than can be completed. This adds up to increasing WIP, in turn leading to an increase in cycle times. The remedy? By keeping track of WIP, making sure not more work is started than is completed during a given time frame (like a sprint), you will get some well needed data to help you maintain a sustainable WIP allowing for change and disruption.
Efficiency and Effectiveness
Another subtle way that WIP builds up over time is when we mix up efficiency and effectiveness. We could also dub this the “utilisation problem”, because it’s essentially the same thing. The illustration above (with the green, yellow, teal projects) illustrate this well; it might be efficient for a team to divide their work into three parallel work streams, and often they can motivate such a division by looking at utilisation; everyone is busy. But it is clearly not effective from the perspective of the project, which now shares cycle time with any other ongoing project. The solution is simple in principle, but often hard in practice; only work on the one project at a time. The challenges arise when we learn that the team cannot do that for different reasons — it will get too crowded, there’s only one person with the required skills, or similar.
This highlights a constraint (in these cases a constraint in ability to collaborate or a constraint in available skills), and when highlighted it offers a great opportunity to address it by investing the time not in the other projects, but in removing the constraints. Now the other projects are still paying cycle time, but this time by investing in removing a constraint.
Hidden Work
It’s quite common that additional work “sneaks in”, usually by way of a desire to help out, unblock someone else, or similar. I include in this the “While we’re at it”-pattern; under the illusion that we “know” what the requirements are, we might add endpoints or functionality for later “while we’re at it”. This might make sense for a carpenter or electrician when renovating a house, but it’s not great in software engineering since what we think is a requirement very often turns out to change. Those “while we’re at it” things will then cause extra work (again). From a WIP perspective, much of this is often invisible.
The remedy is of course increased visibility, but seeing it doesn’t necessarily prevent it. Utilising well defined pull-policies and having we defined slicing heuristics is invaluable to minimise the impact of this. The pull policies help the team hold each other accountable for what enters the system, and the slicing heuristics help us stay pragmatic about the scope we are looking to implement.
