Is it SAFe to Kanban?

In the beginning, the Scaled Agile Framework (SAFe) advocated using Scrum at the team level. As the framework grew in popularity, practitioners started to ask if teams must use Scrum or if team-level kanban was an acceptable alternative. I recall discussions about Scrumban as an approach, and I remember it being dismissed, but I don't recall why. Anyway, the result was that the framework was updated so teams could use either Scrum or Kanban in SAFe. 

On the surface, this seemed like a simple solution that would make both Scrum and Kanban teams happy. Of course, like with many things, the devil is in the details.

For this post, I am defining kanban using the three simple kanban principles from Kanban in Action by Marcus Hammarberg and Joakim Sundén: make work visible, limit work in process, and help the work to flow.

Kanban in SAFe Scrum Teams

As a lean-agile framework, SAFe has always advocated for Scrum teams to use some level of kanban. In the original book on SAFe, Dean Leffingwell's Agile Software Requirements, Dean suggests agile teams should use Big Visible Information Radiators (BVIRs) and apply work-in-process or work-in-progress (WIP) limits. (Fun fact: the WIP limit exercise in the current Leading SAFe and SAFe for Teams classes has been in these courses since the beginning of SAFe!) When it comes to kanban teams in SAFe, they also visualise their work and apply WIP limits, so there is no difference there. 

Kanban and SAFe Cadences

While kanban does not specify cadence-based events in the same way as Scrum, it does have the concept of cadence for recurring events like intake, stand-ups, prioritisation, delivery, and retrospectives. However, in the words of the Kanban Method thought leader David Anderson, "Kanban dispenses with the time-boxed iteration and instead decouples the activities of prioritisation, development, and delivery. The cadence of each is allowed to adjust to its own natural level."

In practice, kanban teams on an Agile Release Train (ART) usually adhere to the ART's iteration cadence and align their cadence-based events. In the context of SAFe, this is particularly useful as synchronised cadences help multiple teams manage interdependencies and integration.

Agile Team Roles and Responsibilities  in Kanban and SAFe

Agile Teams in SAFe have a Scrum Master / Team Coach and a Product Owner. Kanban, being more principles-based, does not have any specific roles. In practice, some Kanban teams will have a Team Coach and a Product Owner. In SAFe, these roles are essential as they form part of the mechanics in the Agile Release Train team-of-teams dynamic.

Why do SAFe Agile Teams Choose Kanban?

I have very rarely seen 100% Kanban teams on ARTs. When a team suggests they want to use Kanban because they “can’t plan their work,” I always find this an interesting assertion, and I like to dig a little deeper. The “why” is often the same: “Our world is too unpredictable.” It turns out that the nature of the work tends to fall into one of three categories. 

Operational Activities

The first is incident management or other highly operational functions where the team's work is entirely unpredictable.

Business and Infrastructure Functions

The second is business teams in functions like HR, recruitment or legal contracting and teams working with large infrastructure initiatives, like setting up a new data centre. This type of work can be challenging to estimate and plan into iterations due to the elapsed time often being weeks or months rather than days. (I'm not saying you cannot use Scrum for this work; I'm just making an observation that these types of teams often prefer kanban).

A Significant Portion of Backlog is Unpredictable

The third group is the most common scenario I encounter. Approximately half of the work is unpredictable, like category one (operational activities), whereas other work can be planned, such as patches, upgrades, and small change requests. In this situation, I ask the team to identify the work they already know about and will need to complete over the next few months.

The second question I ask is what proportion of their work they consider planned versus unplanned. This question will sometimes lead to us building a list of the types of requests the team receives and categorising them into plannable and unplannable.

From there, we can make an educated guess (or pull data from your support tool) to characterise the split, which is usually something between 30/70 per cent and 50/50 per cent. This information is generally good enough to set an initial capacity allocation for the first PI. We can always adjust the allocation based on the outcomes of the first or subsequent PIs. Unlike the first two groups, these teams rarely end up practising pure kanban.

Can SAFe Agile Teams Move From Scrum to Kanban?

The most common reason teams want to move from Scrum to kanban is that team members are complaining that “Scrum is too hard.’  This is not a good reason to move to kanban! It is worth asking what is “too hard” about Scrum.  If a team is struggling with Scrum, they will likely struggle even more with kanban. Scrum comes with a playbook—the Scrum Guide. I think of this as training wheels for new agile teams. 

While there are some great books on kanban, there is not a 13page publicly available playbook. Teams will need to be disciplined about setting WIP limits, establish a kanban system with clear policies for moving from through the states, and then actively work to reduce WIP limits and improve the flow of work.  In my view, kanban is not a good choice for teams that lack discipline. 

It is okay for teams to move from Scrum to kanban. Sometimes, this means overlaying kanban practices as per the SAFe approach mentioned above. For others, this could be a complete change in approach, driven by continuous improvement, because they have outgrown the training wheels provided by Scrum. Of course, these teams will still need some structure to align with other teams on the ART.

PI Planning for Kanban Teams

PI Planning evolved from the Scrum practice of Release Planning or, as Mike Cohn has reframed it, Medium-Range Planning. In the context of Scrum and SAFe, this practice is quite simple, as we have a medium-term product backlog that teams can estimate (at a high level) and an understanding of capacity based on historical velocity. With this, teams can produce a PI Plan.

Teams with a reasonable proportion of plannable work can follow this process for the plannable portion of their backlog. The remaining capacity is reserved for unpredictable or unplannable work items, which teams often use kanban to visualise and manage.

When it comes to a 100% Kanban team, PI Planning will likely feel uncomfortable. The best place to start is by understanding the purpose of PI Planning—"to gain alignment and commitment around a clear set of prioritised objectives." At a team level, this means being able to define and commit to a set of PI Objectives, agreeing on cross-team dependencies and identifying ART PI Risks that could derail the plan. Often, these teams will write PI Objectives that are different from those with plannable work. Their PI Objectives might reference Service-Level Agreements as well as significant specified dependencies.

Scrum Teams create a PI Plan by taking Features and breaking them down into high-level user stories. These stories are then estimated and scheduled into iterations until the team's capacity is close to full. Kanban teams need to achieve the same outcome but do not need to follow the same process. We also don't expect them to fill iterations close to capacity as they are not managing work using a capacity planning-based method. High-performing Kanban teams should have flow velocity and flow time data they can use to inform their PI Planning.

Commonly, we see kanban teams with a mix of unplannable work and plannable dependencies for other teams. PI Planning for these teams involves cross-team collaboration to map out the dependencies work they need to contribute to or deliver for the ART. Sometimes, these teams are also a conduit to connecting with other technical specialities outside the ART, which can be enormously valuable. 

No matter how they get there, the SAFe Kanban team needs to be able to define and commit to PI Objectives and agree on dependencies with other teams on the train. In the language of kanban, these are likely to be fixed-date tickets to which a fixed-delivery-date class of service would be applied. 

Can Kanban Teams Work in SAFe?

While SAFe initially used Scrum at the team level, including kanban as an alternative provided flexibility for teams. However, teams that opt for kanban often face unique challenges, particularly around planning. Whether the work is entirely unpredictable or a mix of planned and unplanned, there is usually a way to find a balance between the two.

Ultimately, kanban teams, much like Scrum teams, must still align to the purpose of PI Planning—creating and committing to a clear set of prioritised objectives. High-performing Kanban teams rarely use Scrum events and processes; instead, they use flow metrics to inform their PI plans.

Whether teams apply Scrum, kanban or a hybrid approach, all agile teams in SAFe should have the same goal: delivering value through collaboration and commitment to shared objectives across the ART.