Limit Your WIP
Last week I read The Phoenix Project. It's entertaining and it offers a way for IT departments to make their work matter inside organizations that lack IT expertise. WIP is one of the things that the book got me thinking about.
Work in progress (WIP) is the work that has been started but not finished. There is WIP in manufacturing and there is WIP in software development. WIP is an unavoidable step in all production operations. But while WIP is inescapable, it's harmful in excess; when WIP goes up, due date performance goes down.
In manufacturing the more WIP you have in the production area, the more cluttered your work stations are. When there is a pile of unfinished work waiting for the operators to continue where they left off, those operators end up spending more time thinking what to do next instead of moving from one task to another. WIP makes the manufacturing work slower and more unorganized in big and small ways.
Manufacturing and software development have their differences but it's not difficult to see the waste WIP generates in our software projects: Each pending change to our codebase makes introducing new code changes harder. When developers have multiple tasks in progress, they have to do more context-switching. Some WIP requires us to keep the rest of our team up-to-date with the current task status.
Teams can try to control their WIP by limiting the number of tasks developers can work on at any given time. These are called WIP limits and while they might seem counterintuitive, they work when managing production performance.
However, setting WIP limits for small teams building custom software sounds troubling to me. Instead of defaulting to more management, we should first try to coach small teams to take more ownership of their ways of working. Taking more responsibility over different parts of the system and having the ability to change direction fast are the key strengths of small teams. We want our small teams to realize this opportunity instead of doing all the management and thinking on their behalf.
Here are three reasons your small team might be facing out-of-control WIP. For each of these issues there exists an alternative to WIP limits.
1. You don't control how tasks move from backlog to WIP
The pressure to deliver features might be so intense that your colleagues constantly push you to start yet another task before finishing the last one. You are allowing too much work to enter your WIP lane.
If something has a high priority, it moves further up in the backlog. It doesn't enter the production area because we don't want to introduce more clutter and context-switching to our workspace. If you want more finished work, you make the flow of work faster. More WIP means slower flow. Which of your extra tasks are so critical that they allow the overall development speed of your team to drop?
2. Bottlenecks prevent you from finishing
Are these bottlenecks temporary or do they seem to persist even when you move to different features? Dealing with persisting bottlenecks are likely to yield more benefits to your team compared to any refactoring or test coverage efforts (unless the bottleneck is related to poor code quality). Theory of constraints teaches us that improvements made at the bottleneck make the system faster. Improvements made anywhere else are illusionary because a chain is no stronger than its weakest link.
3. You try to maximise activity instead of output
We often give false value to busyness. Many work cultures reward people who look busy running around from meeting to meeting with a phone in their hand. It's the best way to make yourself look important, right?
Because we think busyness is important, sometimes when we face an obstacle with our task at hand, we freak out and start working on another task in order to avoid the risk of inactivity. This is not a good habit. Effectiveness is ultimately about output—not activity. We should all try to get better at finishing instead of getting better at starting.