I’ve created this quick guide off the back of feedback received after our monthly Keep Agile meetup (Last Wednesday of each month here). We were exploring how we like to visualise our work.
This article is based on the following beliefs commonly known as the 7 wastes of software development or if we look at their history the 7 wastes of lean manufacturing. I’ve listed them out so that they can be challenged or accepted but they are the vital context for the rest of the article.
- Inventory/partially done work is suboptimal
- Work left waiting for further processing becomes stale. It loses its value as the systems around it change and the customers need change. When talking about physical stock it takes up room which in turn costs money.
- Relearning is suboptimal
- Having to come back to a piece of work and relearn what was done, how it was done and why it was done cost time and cognitive load.
- Handoffs are suboptimal
- Passing work between teams or individuals requires effort and time to ensure that the context of the work is understood. This creates delays
- Task/Context switching is suboptimal
- Switching between areas of focus has a massive impact on cognitive lead and creates delays. It encourages handoffs, relearning, inventory and delays.
- Extra features are suboptimal
- Building features or functions that were not requested or required costs time to do but also costs time to maintain. Maintaining a product feature or areas of code that don’t get used is a waste.
- Delays are suboptimal
- Delays are usually the most common waste. In good news, it is often the easiest and cheapest waste to remove. Decentralise decision making and empowerment of the teams doing the work will often remove a large chunk of this waste.
- Defects are suboptimal
- An issue found in production necessitates changes to existing plans in order to resolve. It tends to costs many magnitudes more time and effort to resolve a defect than it would have done to ensure it didn’t reach production. The impact can also be damaging for the reputation or trust the customer has in your product.
What is a pull system?
A pull system is one where each process step pulls its activities from a backlog or queue of available work. As work is completed by a process step it will be put into a queue to be pulled in by the next process step.
In the cake shop example below you can see that “Mixing” has a WIP limit of 2 with one item done. The rest of the value chain has a WIP limit of 1.
What is a push system?
A push system is one where each process step has its activities push upon it from the previous process step.
Both push and pull systems can be optimised by limiting the work in progress at each process step. This article explores why it is easier to justify and implement WIP limits with a pull system.
Many of the agile/lean workflow management tools (ADO, JIRA, etc) are defaulted to push systems, although nearly all are configurable. I can only assume that this is the case as push systems are a simpler first step to model although I would disagree with the value of this notion.
So what are the benefits of a pull system?
In no particular order:
Each process step can only every process work according to the level of people, skills and resources available to it. If we view the entire process as a chain of process steps then the work will only ever flow as fast as the slowest link in that chain. A pull system allows you to easily identify the bottleneck in your chain (see Identification of bottlenecks) and understand its current capacity to process work (see Easier analysis of cycle time). The pull mechanism matched with sensible WIP limits will also reduce the chances of context switching and allow an ethos of stop starting new work and start finishing existing work to establish.
Identification of bottlenecks
A pull system will soon highlight bottlenecks in your value chain. Queues will start to form right before the bottleneck. This allows the team to explore what if any action they can take to reduce the bottleneck. More importantly, it can allow for discussion around the value of continually building up a queue of work before the bottleneck. Queues of work increase our inventory (partially done work) and that creates a number of other wastes such as relearning, reprocessing and the chance that the initial request is no longer valid (see Inventory is a waste)
Focused work with less pressure to context switch
A process step that pulls in work at the same rate that it completes work is functioning at its optimal capacity. By queuing the work we allow this to happen. Large queues may start to form however this is an indication of a bottleneck in the system (See Identification of bottlenecks) so is a good thing. When a process step has worked pushed into it then it is more at risk of context switching. The new work may be deemed a higher priority than the old piece of work hence attention is switched on it. This may seem beneficial however it generates several wastes (Relearning, inventory, task switching, delays) and slows down the entire process.
Easier analysis of cycle time
When a process step is in control of the work that it is processing it becomes easy to understand the cycle time for that step. You can simply measure the time it entered that process step and the time it left. When a process step has work pushed into it then the cycle time includes much more of the wait time it is being processed along with the associated wastes.
More informed use of WIP limits
Once armed with a good understanding of the cycle time and capacity of the team then WIP limits can be used across the system in order to optimise the flow of work. This is a very different mindset than optimising the time of the individuals doing the work. As defined if the process chain can only move as fast as its slowest link then there is no value in other links working faster. We can use WIP limits to ensure that this doesn’t happen. With the spare capacity of the people and skills, we can look to either cross-train (of the bottleneck is skills) or investigate other options for removing or reducing the bottleneck.
Pull systems allow us more transparency into the operational efficiency of our process/value chain. With this understanding, we can optimise the flow of work through the system and move away from measuring and optimising individuals busy time.
With some very simple steps, you can turn your push system into a pull system and introduce WIP limits. You can either split your active columns into “doing | done” or you can create queue columns between these states. I would recommend the former as this allows easier control of WIP limits. To start with WIP limits my advice would be to start by gaining agreement and commitment to stick to them. Without this, any existing culture of always having to be busy will often lead to stealth work. Look for agreement on how long you are going to experiment with a WIP limit before you decide to adjust it. Look to initially set this as low as the team are willing to go. A WIP limit of 1 will ensure that things flow quickly however if that means half the team are doing nothing then go a little higher. I’d certainly question a WIP limit that is greater than the sum of the capacity to do the work.
Lastly there is nothing stopping the team setting WIP limits across the value chain or horizontally. If the team has reached the Nirvana state where all members are cross functional this can really improve through-put.