The gap between deciding to Limit WIP and actually lowering WIP
One of the key Kanban practices we discuss in the Kanban Guide for Scrum Teams is Limiting Work in Process.
Some of us have the luxury of designing processes for greenfield systems meaning there is no history/legacy to deal with.
Typically though, we are dealing with Brownfield/Legacy systems - This usually means there is some work in the system already, there are outstanding commitments, and some existing queues between steps in our processes.
All of which means that the moment you decide that your definition of Workflow includes a WIP Limit, you typically have a gap between the desire to have a lower amount of WIP in your Scrum Team's workflow, and the actual amount of WIP you currently have and foresee having.
These examples might seem familiar:
- We already have a commitment to deliver V10 with 20 features by end of October.
- Our testing department is backlogged - its still dealing with the previous release V9 while development is already working on those 20 features for V10.
- V10 is critical to the business.
So how do we get from the current situation with way too much WIP (what I call "the swamp") to the right amount of WIP for us (what I call "the river")? Here are some patterns I found useful over the years when working with Kanban and Scrum teams:
The Freeze
Essentially prioritize all work. Anything that is in process but above the WIP limit, goes to the freezer - a new temporary lane/area where work is put on freeze until there is room for it.
The immediate effect would be the acceleration of all work inside the WIP limit, and significant risk to the commitment made about the frozen work. Yes, you say that the original commitment took all the work into account so why is there a risk just due to changes in parallelism? Well, because we focus on the higher priority work, the reality is that we might spend more effort on it, to deliver it with reasonable quality (not necessarily an attribute of previous releases...), we might spend more time investing in Versatility in order to sustain a lower more focused work in process limit. So, it would be prudent to negotiate the commitment level on a couple of lower priority features from the release... and give the business a heads up this might happen.
This is one of the fastest ways to achieve a new inventory/WIP level in the system. If we are looking to show quick results and are able to negotiate a temporary change in service levels with the business, this can be a great approach.
This strategy is elaborated in depth in the Theory of Constraints body of knowledge.
When it comes to Scrum Teams this means a tough discussion during Sprint Review of which PBIs we want to freeze, and taking that into account during the next Sprint Planning. Hopefully, most PBIs are getting Done during the Sprint, but in real life we know that doesn't always happen, especially when WIP is too high...
In addition, there's the scenario where the Dev Team delivers PBIs that are valuable but not really marketable, because a higher-level entity (call it Epic, Feature, large PBI, whatever) requires more PBIs to really be marketable. In this situation, we should apply flow thinking and limit higher-level PBIs in progress as well, and freeze some of them until we establish a reasonable high-level flow.
The Sprint Goal can reflect the focus on draining this swamp we got on our hands.
No New Work
This is a more evolutionary version - don't freeze current work, but deny new work until we reach the desired work in process levels. This means anyone finishing work on something will look into how he can help someone else, instead of starting something new. There will still be effects on the release commitment, but milder ones.
The price we pay here is that it will take more time to reach the new inventory/WIP level. It's easier to negotiate with the business, but the results will show more slowly...
For a Scrum Team, this again means looking at both the high-level PBIs in the Product Backlog and Sprint-level PBIs.
During Sprint Planning the preference should be first to finish PBIs that are in process and then if there's still capacity to pull PBIs that help finish high-level PBIs that are already in the process instead of starting completely new ones. The same rationale applies during Daily Scrum as well.
Visualize now, Limit Later
This is an even more evolutionary version. You start with Kanban principle #1 - Visualize work. You don't put any WIP limits for now. You see how work looks like, you try to manage WIP, but don't limit it. Perhaps when negotiating commitments to the next release V11 you take into account a period of cleaning the system/queues and the implications of lowering the WIP, and at that point you go into a Freeze/No New Work period, with a bit more confidence in how this will look like, based on a few weeks/months of visualizing your work.
This clearly is the risk-averse approach. Just be careful of running out of improvement energies and forgetting that just Visualizing Work is not enough...
To be clear, if you're just visualizing WIP and not limiting it, you're not applying Professional Scrum with Kanban yet. You don't really have a pull-based Kanban System, and you cannot use Lean/Flow metrics for predictability...
Differentiated Service
A tweak on all of the approaches above can be to treat different work types differently.
For example, Normal work above the WIP limit will be frozen. Fixed date work will hopefully be inside the WIP limit and be allowed to finish. New Fixed date work can be allowed to start, with the condition that a Normal work will be frozen in exchange for introducing it. If all work currently in the system is Fixed Date, we can decide whether to allow the new Fixed date to start (should be a comfort zone for most organizations ;-) or to have a serious discussion with the business on the risks it introduces and how we want to address them.
We can also say we visualize all work, but limit specific types of work.
Feedback
What do you think about those approaches?
Which of the above did you find useful in real life?
Do you have other strategies for starting up in the real world?
To learn more about limiting and lowering WIP on Scrum teams using Flow/Kanban, check out a Professional Scrum with Kanban class or the Kanban Guide and Applying Professional Kanban class at ProKanban.org.