Some time ago, we hosted an experience interview with Daniel Vacanti. Daniel is the co-founder of ProKanban.org, a venture conceived of, by, and for the Kanban community. Its mission is to support all Kanban practitioners (new or old) by providing a safe and inclusive forum to learn about Kanban. He is also the co-author of the Kanban Guide and author of the books “Actionable Agile Metrics for Predictability” and “When Will It Be Done?”
During this meetup, Daniel answered a wide variety of questions raised by our Patreon community.
For example:
- What would be a 2-minute explanation of Kanban?
- What’s the difference between the Kanban Method and Kanban?
- Is there such a thing as Zombie Kanban? If so, what are the warning signs?
- If an organization or team decides to adopt Kanban, are there any common pitfalls that should be avoided?
- What’s the story behind ProKanban? How did it come into existence?
- How to explain to a team that the size of the items (effort) doesn’t impact the overall cycle time?
- What happens if a team is overly obsessed with the metric work item age and starts to rush everything?
- How do you estimate the impact on the throughput when adding new people to the team?
- How is it that Kanban often gets labeled/ dumped as a tool for production support items?
Interested to learn how Daniel answered these, and many other questions? Check the video!
In this blog post, we focus on one specific topic that emerged:
“Can Scrum teams use Scrum and Kanban, simultaneously?”
Scrum
My hunch is that most of our readers are familiar with the basics of the Scrum framework. But this is obviously an assumption, so to prevent any misunderstandings, here’s how we describe Scrum in a nutshell. The Scrum framework is being applied successfully to complex problems in a wide variety of domains. From marketing to organizational change. And from scientific research to software development. The Scrum framework, wherever you use it, is built on three pillars that allow empirical process control:
- Transparency: you gather data — like metrics, feedback, and other experiences — to find out what is going on;
- Inspection: you inspect the progress with everyone involved and decide what that means for your ambitions;
- Adaptation: you make changes that you hope will bring you closer to your ambitions;
This cycle repeats as often as necessary to catch deviations, unexpected discoveries, and potential opportunities that emerge as the work is done. Rather than making decisions based on assumptions about potential futures, you’re instead making decisions on the data you’ve collected up to this point. This is empiricism. And as such, Scrum is a framework for empirical process control. It offers five repeating events to work on three artifacts, three accountabilities to support this plus several principles & rules to glue this together into a cohesive whole. For a more detailed explanation, check the paper we wrote “Scrum — A Framework To Reduce Risk And Deliver Value Sooner”. But this short description is the essence of Scrum.
You can download a high-resolution version of this illustration here.
Kanban
The online Kanban Guide does a great job of describing the essence of Kanban as follows:
“Kanban is a strategy for optimizing the flow of value through a process that uses a visual, pull-based system. There may be various ways to define value, including consideration of the needs of the customer, the end-user, the organization, and the environment, for example.
Kanban comprises the following three practices working in tandem:
- Defining and visualizing a workflow
- Actively managing items in a workflow
- Improving a workflow
In their implementation, these Kanban practices are collectively called a Kanban system. Those who participate in the value delivery of a Kanban system are called Kanban system members. Central to the definition of Kanban is the concept of flow. Flow is the movement of potential value through a system. As most workflows exist to optimize value, the strategy of Kanban is to optimize value by optimizing flow. Optimization does not necessarily imply maximization. Rather, value optimization means striving to find the right balance of effectiveness, efficiency, and predictability in how work gets done.”
Scrum With Kanban
Zombie Scrum flourishes in environments where there’s a lack of transparency. For example, it’s not clear how much time it actually takes to get one Product Backlog item done. Or how much time it takes from the moment a stakeholder expresses the wish for a new feature until it’s released to production. Or during the Sprint Retrospective, the team feels annoyed about the lack of collaboration and is stressed because they’re working on so many different things simultaneously, but nobody really understands what’s going on. And during each Daily Scrum, team members share they can’t finish their work because there’s a problem, dependency, or bottleneck. Nobody really understands the root cause and its impact.
As described in the Scrum Guide, transparency enables inspection. So, without full transparency, inspection is misleading and wasteful. And as a result, adaptation becomes pointless as well, because you’ll make decisions based on potentially wrong data, information, and assumptions.
In order to prevent or fix Zombie Scrum, teams can use Kanban. Put differently, teams should use Kanban. When Kanban practices are applied with Scrum, they provide a focus on improving the flow through the feedback loop; optimizing transparency and the frequency of inspection and adaptation for both the product and the process (from the Kanban Guide for Scrum Teams). So, in order to increase transparency and make inspection & adaptation more valuable, our recommendation to Scrum teams is to start using the following metrics of flow:
- Work in Progress (WIP): the number of Product Backlog items started but not finished. Teams get more done when they work on less at the same time. Optimizing flow by limiting work in progress is built on this counterintuitive truth.
- Cycle Time: the time that transpires between when work begins on an item and when the item ships.
- Work Item Age: the amount of time between when a work item started and the current time. This applies only to items that are still in progress.
- Throughput: the number of work items finished per unit of time.
- Lead time: the time that transpires between when a stakeholder request enters the Product Backlog and when it’s fulfilled to that stakeholder through a release.
Lead and cycle times are great measures for agility; the shorter they are, the faster you ship and the more responsive you are. In environments with Zombie Scrum, these timings are much longer than environments where Scrum works well. Without these 5 metrics, everyone feels & sees things don’t work, but can’t really put the finger on why. With these metrics, you visualize the system and its workflow, you can inspect using real data, and make the necessary adaptations accordingly.
An example of a Scrum board with work-in-progress limits and flow-based metrics. From our book, the Zombie Scrum Survival Guide.
So, What’s The Verdict?
So, to answer the primary question of this blog post: yes, you can use Scrum and Kanban simultaneously. I would even strongly recommend all Scrum teams to use Kanban. As long as you use Scrum and Kanban as intended. So, don’t cherry-pick. Don’t select some elements of the Scrum framework and only a couple of practices and metrics of Kanban. Both only work in their entirety. While implementing only parts of Scrum is possible, the result is not Scrum. The same goes for Kanban. This doesn’t mean you can’t experiment. Please do, just be mindful of the consequences, and don’t remove stuff from Scrum or Kanban because your reality is too difficult. The more reasons you have to actually use it! Visualize your system and workflow, and continuously inspect & adapt!
“I would even strongly recommend all Scrum teams to use Kanban. As long as you use Scrum and Kanban as intended. So, don’t cherry-pick.”
Interested to learn more?
- Read the essence of Kanban in the Kanban Guide;
- Study the Kanban Guide for Scrum Teams;
- Check the website ProKanban.org;
- Check the article from Christian Hofstetter “How to do a Sprint Retrospective using Flow Metrics?”;
- Read the books by Daniel Vacanti “When Will It Be Done?” and “Actionable Agile Metrics For Predictability”;