For a long time I thought that using Kanban excluded the use of the Scrum framework. In my mind you couldn’t use both at the same time.
The first time I was proven wrong was when I found “The Kanban Guide for Scrum Teams” written by Daniel Vacanti and Yuval Yeret. It describes the use of Kanban in an environment where people use Scrum.
Reading this guide got me more and more interested. It gave me the feeling that Kanban is filling a gap in the Scrum framework.
When I had the change to follow a Professional Scrum with Kanban training by Daniel Vacanti and The Liberators, I couldn’t let this one pass me by.
The Scrum framework
The Scrum framework focusses on how to organize your Scrum team. What are the roles, what do these roles mean, what events are there and what artifacts. The Scrum guide covers the responsibilities of the Scrum Master, the Product Owner and the Developers. Also it talks about delivering a product increment at least once every sprint.
Doing everything that is written in the Scrum Guide, doesn’t optimize the flow of handling Product Backlog Items. For example: the Scrum framework covers that the Development team creates a plan every day on how they are going to work together to achieving the Sprint Goal. One way to do this is by getting a Product Backlog Item (PBI) “done”. But how is the Development Team getting PBI’s done? And what if there is an issue that needs to be solved immediately? The biggest enemy of planned work is unplanned work. But in an environment where software is used, chances are there will be issues that needs to be solved fast.
Enter Kanban
The Scrum Guide states that: “The Product Owner is responsible for maximizing the value of the product resulting from the work of the Development Team”.
Now let’s take a look at Kanban. Let’s start with the definition: “Central to the definition of Kanban is the concept of flow. Flow is the movement of value throughout the product development system. Kanban optimizes flow by improving the overall efficiency, effectiveness, and predictability of a process.” (The Kanban Guide for Scrum Teams)
We have the maximizing of the value and we add optimizing the flow of value through the product development system. So we create as much value as possible, as efficient and effective as possible. This way the Scrum Team can get faster feedback on the value delivered so they can deliver higher value.
Metrics
Kanban uses 4 metrics to track flow in the product development system. These metrics are:
- Work in Progress (WiP): how much PBI’s did the Development Team start on but didn’t finish.
- Cycle Time: how much time did it take from starting on a PBI and finishing it.
- Work Item Age: when an PBI isn’t done, how long ago did the Development Team start working on it.
- Throughput: how much PBI’s were done in a set unit of time.
A lot can be discovered by analyzing these metrics. If a team of 5 developers has a WiP of 12, you can wonder if the team lags focus. If there is a high cycle time, are the PBI’s perhaps too large? If there is a high Work Item Age, is there a problem that needs to be addressed? Is there a low Throughput? Are the PBI’s to large or did some other problem occur?
This way these metrics can the Development Team during the Daily Scrum. As a Scrum Master you can help the Development Team to learn interpreted them and use them as a signal.
Optimizing flow
Kanban knows 4 practices that helps Scrum Teams with optimizing flow:
- Visualization of the workflow
- Limiting Work in Progress
- Active management of work items in progress
- Inspecting and adapting the team’s definition of “Workflow”
The visualization of the workflow is something a lot of Scrum Teams already partially do. They use a Kanban board to show their progress towards achieving the sprint goal. In the The Kanban Guide for Scrum Teams (Kanban Guide) you can find 5 points the visualization should include. Important is that every one has the same interpretation of the items forming the Kanban board. Think about things like when did work start, when was it done, what different states of an PBI do we have, how much WiP is allowed (WiP limit).
These things help optimizing the flow. For example; a WiP limit. A WiP limit, limits the amount of work you can have in a Kanban lane. In this example, the numbers between ( ) is the WiP limit.
Above there is no problem. Everyone is working on a PBI and if needed, work can be pulled into the Develop lane or the Deploy lane.
Above [PBI 5] is ready to be pulled into the Deploy lane. Only the Deploy lane is at the WiP limit. Also, no new PBI can be pulled into the Develop lane. Because Develop is also at the WiP limit. The best way the team can solve this is by helping pulling PBIs from Deploy into Done. This can be done by Swarming (whole team collaborating on a single PBI) or Mobbing (the whole team working on one task using one keyboard). When [PBI 2] is pulled into Done, [PBI 5] can be pulled into Deploy and [PBI 10] can be pulled into Develop.
To prevent these kind of situations, it’s important to perform active management of work items in progress. For example during the Daily a team member can state he’s almost done with [PBI 5]. Looking at the Kanban board shows that the Deploy lane is full. An other team member can offer to help to get work pulled from Deploy into Done.
As you can read, the system is all about the work, not about the worker. The goal is to get PBIs through the system as optimal as possible. The target is not to have everyone working as much as they can.
Inspect and adapt
One thing a lot of teams forget to do is inspect and adapt their workflow. During the retro teams take a look at the process, the people, relationships, tools and how to improve them. Something that is easily overlooked is taking a look at the definition of “workflow”. For example; does the Kanban board still optimally visualizes the different states the work is in. Or can we improve it by changing the name of a lane, adding a lane or removing one? Also, could we perhaps improve our throughput by lowering the WiP limit?
Unplanned work
As stated before; the biggest enemy of planned work is unplanned work. Think about how you handle unplanned work at the moment. Does someone in the team drop everything he or she is working on to solve the problem? Or does the person who reported the issue has to wait until the next sprint before someone starts working on it?
Imagine a situation where work flows through the system at a high pace. The lower the cycle time, the lower the need to drop work because of an issue that needs to be solved. If all the PBIs are pulled through the system at a high rate, bigger the chance the issue can be planned to pick up next. There is less need to drop work in progress.
The Sprint Backlog is not a fixed set of PBIs that need to be done at the end of the sprint. So it’s possible to place something on the Sprint Backlog during the sprint. And yes, you should always consider what adding something to the Sprint Backlog means to achieving the sprint goal. And also a lot of unplanned work can jeopardize achieving the sprint goal. So the goal is still to minimize unplanned work. But if your workflow is optimized, the chance a single piece of unplanned work prevents you from reaching the sprint goal is getting a lot smaller.
Filling the gab
I hope I’ve convinced you that Kanban can fill a gab in the Scrum framework; how to flow value through the software production system as optimal as possible. Kanban not only shows you 4 practices to do so, but it also provides you with metrics to measure how you are doing. Kanban and Scrum go hand in hand. To quote Daniel Vacanti: ”The second rule of Scrum with Kanban is, you don’t change a thing about the Scrum framework.” (The first rule is: “You don’t talk about Scrum with Kanban”. A reference to the movie Fight Club.)
If you want to read more, I recommend you read “The Kanban Guide for Scrum Teams”. You can find it on the scrum.org website. Also I would recommend taking the PSK training by Daniel Vacanti. The training is not only a great adition for Scrum Masters but for the whole Scrum Team.
