How we transformed our Scrum with Kanban (part 2)
Bringing Kanban ways of working can supercharge your Scrum. In this next part, I’ll share what we did to limit WIP.
You can build a Kanban system around three key practices. All of them are compatible with Scrum and will even enhance it.
- Defining and visualising the workflow
- Actively managing work in progress (WIP)
- Inspecting and adapting (improving) your workflow.
Keeping your WIP limits low improves your flow and will give you better cycle times.
Limit your WIP
One of the more interesting things about limiting your WIP is just how counterintuitive it is. Restricting and balancing your flow as much as possible will lead to more work done, to a higher quality.
If you have a scrum master, play the pennies game to show this. Otherwise, Actionable Agile has published a free game that can be played individually or in teams, which brings this and the other principles to life.
The reason why we should work towards smaller WIP limits is that people aren’t good at multitasking. Cal Newport talks about this in his Deep Work book, which is very good on this subject. Context switching kills productivity and makes it hard to focus.
Also, adding more people to a team won’t necessarily speed up work, particularly in the short term. Creating a team takes time. Onboarding and knowledge sharing also takes time, especially if the new person needs to develop new skills. If you want to improve your flow in the short term, remove unnecessary work, set strict WIP limits, and keep them. That will then help remove distractions.
You have to apply WIP limits to each stage of your Kanban system once you have defined and visualised your workflow.
Work with your team on setting the WIP limits. We kept ours low and balanced across the system. This meant fewer bottlenecks and an even flow from start to finish. If you are trying to keep to kaizen principles of small incremental change and think your team will struggle to work this way, start with higher limits. Then gradually reduce as time goes on.
Another way to set WIP limits might be to think about the cycle time you’re trying to achieve, though this is harder if you’re not sure what the smallest units of value are. Cycle time is a metric with the clock starting when an item first enters the start of system to when it leaves. It’s a key metric in answering the question any stakeholder will ask: ‘when will it be done?’
Either way, when WIP limits force people to finish work, it should encourage the team to swarm around issues as they emerge — mainly to remove bottlenecks or queues forming.
Another tip is to keep your WIP limits and not to change them often. If you find yourselves continually having to break your WIP limits, then change them. We discovered that we sometimes had to break our limits temporarily. This is fine, mainly if the team had to work on an urgent issue. Sometimes your stakeholders might take some time to get back to you, or an external unit is responsible for testing code, for example. Build waiting time into your limits accordingly.
You can maintain your WIP limits by frequently reviewing your system. Ask yourselves if the work is flowing well. Is your approach balanced, or do you see bottlenecks or any part of the system starved of tickets? Are you able to fix your problems, or are the issues too complex?
Staying firm on the limits meant the team took them more seriously. It also forced them to focus on managing stakeholders and getting answers quickly. Previously the team would work on an issue, inform the stakeholder and then come back sometime later once they got a response. Now, with firm limits, that’s not an option. We had to set agreements with our stakeholders when we needed feedback to keep items moving through the system. While a few stakeholders grumbled, within six weeks, our cycle times fell by nearly 30%. As our stakeholders were having their items delivered faster, virtually all were delighted.
We work in a large enterprise environment. There’s complexity and always a waiting time. While the ideal is one work item per person at any one time, that just wouldn’t have worked for us. After factoring in waiting time, we worked as a team to optimise our WIP limits. Since implementing them, we’ve only made one small change.
