How to improve Scrum using Kanban
This article assumes that the reader has an understanding of Scrum and Kanban.
Scrum has well-defined ceremonies and roles. At times, the team can get bogged down in Scrum ceremonies and lose the focus on the flow of delivering features. This can happen often, as such Zombie Scrum is officially a thing now with symptoms, causes and treatment.
Our team (not as bad as acting like a Zombie) felt that we needed to improve our Scrum. We decided to bring in Kanban principles and integrate with our Scrum to see how this will work out.
This is how we did it.
At its core, Kanban is very simple. Kanban helps the teams to
- Unhide work
- Optimise their flow
With these simple principles, Kanban can be applied to any existing process. From our experience, it is a natural fit for Scrum.
Unlike Scrum, Kanban does not describe any particular roles and ceremonies. We decided to keep the Scrum framework as it is but focus on the two key principles of Unhinding work and Optimise the flow
Unhide Work
We decided as a rule to add everything a team member needs to do into our electronic board as a task or story. Once we have this rule, it is surprising to see how much work was being done without them realising it. This helped us in the next rule of Kanban — Optimise Flow
Optimise Flow
Optimise flow — The team need to have a strategy of how to optimise flow. Kanban recommends achieving this with the following approach
- WIP or Work in Progress Limits
- Focus on finishing not starting
- Reduce multi-tasking
- Reduce context switching
- System’s thinking and Swarming
We decided to follow the Kanban approach. To do this, we first created our Kanban process flow as shown below.
Once we have the flow sorted-out, we set WIP limits for each column. We decided to reduce work in progress. We committed to not start the work until we finish what is in WIP.
There is a cultural shift that is required. The developer’s motivation generally is that they would like to finish their contribution to a work item and start the next one immediately. They are mainly driven by learning and growth. We needed to create a systems thinking mindset, where each team member considered the work item within the context of the whole process flow and not just only related to their contribution. The team members need to be aware of the WIP limits and swarm to help other team members to finish work before starting new work.
The standup team meetings were changed and we decided to focus on ‘walking the board’ by asking probing questions instead of the three standard questions as prescribed by Scrum. This means our standups became more engaging and informative without increasing the meeting time (15 mins). Some of the examples of probing questions that we started asking are
- What can we finish today
- Are we breaking our WIP limits
- Is there any suboptimal card that requires swarming
You can decide what questions make sense for your team.
Even though Kanban is simple but there is a tremendous amount of sophistication hidden in the simplicity. There is a lot of information that can be taken out of a Kanban system. With team focusing on unhiding work and optimising the workflow (WIP limits, focus on finishing and not starting, system’s thinking and swarming, reducing context switching) and more engaging and informed standups, there is a definite uplift in the team’s capability to deliver more features efficiently.
We have now successfully used Kanban to improve the flow of feature delivery while still using Scrum roles and ceremonies.
Let me know what you think. If you would like to have a discussion about this, please feel free to leave a comment or contact me.
