As organizations deploy SAFe we typically see several questions from people wanting to have more information about how Kanban is deployed in a SAFe environment at the team level. People indicate that Kanban may be the more suitable practice for their situation. Others feel that the nature of SAFe makes it difficult to implement Kanban, at least superficially.
This page is aimed at working through those issues to provide an understanding of some specific recommended practices, especially as the team integrates into a larger ART structure. In addition, we will provide a background understanding of both the “why” and “how” to think about these practices so you can adapt them to your context. These are expected to be (at best) a starting point for implementation of your practices. You will improve on these base practices as part of your relentless improvement program.
We will begin buy reviewing the basics of a textbook implementation of both Kanban and Scrum, and then look pragmatically at approaches we can apply both at the team and train level. We will look to leverage the good parts of both Kanban and Scrum to improve our practice.
Spoiler alert! In the end Scrum teams can benefit from Kanban approaches and Kanban can benefit from Scrum approaches. While not a formal method (like Scrum and Kanban) some call this combined approach Scrumban.
How Would You Describe Kanban in a Nutshell?
As you can see, Kanban is very lightweight and requires a lot of (self-)discipline to implement on a team. The specific practices that Kanban teams might use include:
Kanban board shows all work of the team
Kanban board shows flow of work of the team so we can find and work bottlenecks
Different service levels (classes of service) for distinct types of work (e.g., expedite, fixed date, standard) are identified and supported
WIP limits in place and enforced
Kanban boards are processed “Right to left, top to bottom”
Continuous improvement occurring
Cycle time and throughput tracked, and improvements focused on improving these numbers
What Are the Differences Between Scrum and Kanban?
For folks that are into the details of these two methods. They clearly come at the problem of managing knowledge work from different perspectives. The following table provides a clear breakdown of these differences:
Scrum | Kanban |
Time-boxed iterations prescribed | Time-boxed iterations optional.
* Can have separate cadences for planning, release, and process improvement.
* Can be event driven instead of time-boxed. |
Team commits to a specific amount of work for this iteration (Sprint) | Team commits to work when it is brought to the board for execution |
Uses velocity as default metric for planning and process improvements | Uses lead time as default metric for planning and process improvements |
Cross functional teams prescribed | Cross functional teams optional
* Specialist teams allowed |
Items must be broken down so they can be completed in an iteration | No item size is prescribed although small(-er) sized work is highly recommended |
Burn down chart is prescribed | No diagram type is presecribed |
“Change agent” is “commitment” | “Change agent” is “WIP limits” |
WIP limited indirectly
* Per iteration | WIP limited directly
* Per workflow state |
Estimation prescribed | Estimation optional |
Cannot add items to ongoing iteration | Can add items whenever capacity is available |
Prescribe 3 roles
* Product Owner
* Scrum Master
* Team | No prescribed roles |
Prescribes 4 events
* Planning
* Daily Scrum
* Review
* Retrospective | No prescribed events |
Scrum board is reset between each iteration | Kanban board is persistent |
Prioritized backlog is prescribed | Prioritization is optional |
Which is Best for My Team? Kanban, Scrum or ...?
If you treat Kanban and Scrum as if they are competing approaches, or adopt a textbook approach to their implementation, then the advice to choose one approach over the other usually breaks down as follows:
Question | Kanban | Scrum |
Primary Consideration | | |
* Work for the team is more than 50% demand driven (team's priority is responsiveness) | X | |
* Work for the team is most project driven (team's responsibility is predictability, forecasting and productivity) | | X |
Secondary Consideration | | |
* Team questions value of estimation and planning | X | |
* Team struggles to break items into small pieces | | X |
* No or low appetite for significant process change | X | |
* Some or high appetite for significant process change | | X |
* Team members have significant self-discipline | X | |
* Team members have limited self-discipline | | X |
Some people feel like Kanban is easier to implement and so opt for that. The reality is that the WRONG reason to implement Scrum is because the Team is simply unwilling to do Scrum-like events or find that they cannot finish a Story in one Iteration.
A notes on this criterion. Many teams whose work is the result of a ticketing system assume that all their work is demand driven, and that Kanban is therefore their only option. This is a problem in that if the team can plan work, they usually are also able to deliver better and faster over time.
Experience has shown that work coming from the ticketing system does not mean that we must treat every work item as interrupt-driven and therefore you are unable to plan it. For example, teams that are pure production support have different classes of incoming problems and so can vary how quickly you would need to respond to that problem. A production site is down request is going to need a more urgent response than say a minor defect because of a workflow problem. This gives as an option to plan more items and would mean that Scrum practices are useful. For example, if we can suggest to the customer “that they wait for (on average for a 2 week Iteration) 1 week for us to work this defect” then we can treat this as an input into the next planned Sprint (iteration) in a Scrum implementation.
In some instances up to 65% of the incoming work for a Team can be treated this way.
In some ways the discussion about whether you use EITHER Scrum OR Kanban is misleading. Like all agile approaches the best idea is to leverage Kanban and Scrum to improve how you deliver value. Scrum teams can benefit from ideas like understanding the workflow, WIP limits, classes of service. Kanban teams benefit from an understanding of the purpose of Scrum events, roles, and artifacts and incorporate some or all of them into their practice.
Here are some more specific approaches people have tried:
What Are the Guidelines for Kanban Teams Operating in a SAFe Environment?
A Kanban team within an ART needs to adapt to some of the requirements prescribed by SAFe to ensure alignment to the ART while still maintaining the benefits of the Kanban flow. The following guidelines address some of those conditions to maintain alignment and allow Kanban teams to contribute effectively within an ART.
Roles
While there are no prescribed team roles in textbook Kanban, SAFe calls for the nomination of someone on the Kanban team to fill the roles of a Scrum Master and Product Owner as you would see on a typical Scrum team. The following are the ways you would apply these roles on a Kanban or Scrumban team:
Product Owner (aka Service Request Manager or Service Manager)
Single point of contact for the work of the Kanban team in the Team Backlog (incoming, in progress, etc.)
Representation on the Product Management team (PMs, POs for the Train) who define the work of the ART and Teams
Attend the PO Sync and represent at the System Demo
Accepts User Stories as complete
Assigns the User Story to the iteration it is completed in (used for Velocity)
Scrum Master (aka Service Delivery Manager, Delivery Manager, or Flow Master/Manager)
Experience has shown that there is usually an advantage to having someone who worries about how well the team works even for Kanban teams, aka: the coach of the Team
Attend SoS and be on point to provide metrics, work impediments, etc.
Focus on team performance and improvements
Report on team Velocity
Cadence & Events
ART Events
SAFe is based on a series of events (meetings) held on a cadence, to synchronize activities across multiple teams. This means that at the ART (team-of-teams) level, Kanban teams that are integrated into an ART need to support these events “as is.”
Team Events
There is benefit for Kanban teams to establish cadences (e.g., ensures time is taken to do the work, makes unpredictable events more predictable, etc.), but unlike Scrum, Kanban teams do not have to use the same cadence for all events. By understanding the purpose of an event, we can determine approaches we could bring into our Kanban implementation.
Daily Standup - Kanban Teams meet daily, but rather than just answer questions aimed at understanding whether we will meet the Iteration goal, these meetings are usually needed to prioritize work and plan the teams’ work for the day.
Planning – Kanban Teams focus more on prioritizing the next pieces of work than planning an iteration of work. This is done in the Daily Standup, where teams will decide which stories they will be working on that day and ensuring they are story pointed. If needed, teams may schedule a separate prioritization or refinement meeting which should then be on a cadence (e.g. every week).
Refinement - For Kanban teams this is usually incorporated in the daily prioritization/planning discussions.
Review/Demo - The purpose of the review / demo is to get feedback on the work completed. Kanban teams often demo individual stories as they are completed to get feedback. Many Kanban teams also report lack of participation from customers to these demonstrations, and so see a benefit in setting up a regularly scheduled Review event every couple of weeks where multiple stories are demonstrated.
Retrospective - The purpose of a retrospective is to take time to improve how we work. Many Kanban teams set up a cadence of retrospectives to ensure it gets done.
At a minimum recommendation is to set up a retrospective at least once every two weeks, so once an iteration.
Consider a shorter cadence to improve faster (e.g. weekly, daily)
-
Be sure to move improvement items into the team’s backlog
Visualizing Work on a Kanban Board
A Kanban board is an agile project management tool designed to help visualize work, limit work-in-progress, and maximize efficiency (or flow). When implementing a Kanban board for your team, it's important to include the following:
Metrics
Cycle Time
In Kanban, Cycle Time is a key metric for measuring team performance, process efficiency and identifying bottlenecks.
Cycle time is calculating the actual work-in-progress or the time between the work on a user story beginning to the time it is accepted. Keeping track of your cycle times enables you to measure your team performance.
Low cycle times mean that your team is efficient. Keeping cycle times down keeps lead time down. The key to keeping cycle time down is managing WIP limits – maybe you’ve heard the phrase… “Stop Starting, Start Finishing”
High cycle times indicate stalls, bottlenecks, and backlogs.
A Cumulative Flow Diagram (CFD) visualizes your teams’ workflow (cycle time, WIP, bottlenecks) by charting the total number of work items in each workflow state per day. It’s a fundamental Kanban tool used to understand where teams may need to focus to make their process more predictable and efficient. Ideally you want to see evenly rising bands on the chart as opposed to sudden spikes or flat lines, so watch out for the following:
An expanding “work in progress” state may be an indication of a bottleneck or potential problem.
A narrowing state may indicate that you have too much capacity in that state.
Stepped flat lines suggest work is being batched rather than continuously flowing.
Velocity
Traditional Kanban teams use cycle time and through-put to understand how much work they can take on (capacity) and forecast when items will be completed. Scrum Teams in SAFe use story points and velocity to accomplish the same thing. The ART Product Management Team needs to be able to understand capacity of the ART and forecast completion. We therefore need a common unit of measure for all teams on the ART – story points!
In SAFe, Kanban teams estimate their work in story points, and as stories are completed it’s important to that the PO updates the Iteration it was completed in when they accept the stories. This then allows teams to report back their “velocity” by calculating how many story points they completed in the previous two weeks.
Kanban teams estimate all incoming items (including defects, KTLO, etc.) in story points prior to working on the item using:
Relative size estimation based on modified Fibonacci numbers – 1, 2, 3, 5, 8, 13, 20, 40, 100
Normalized per SAFe guidance so that stories with estimates of 8 and below can typically be completed in a two-week period (iteration).