SAFe® Kanban

September 29, 2013 — Posted by Al Shalloway

When people ask “can Kanban be done under SAFe at the team level?” they are typically referring to Kanban practices.  The starting point to answering this question, however, must be to look at the mindset underneath these approaches.  This is a bit more complicated, but provides more power because mindsets create the context for practices 

What is Kanban?

Before proceeding, however, we must be clear what we mean by ‘Kanban’.   Kanban is an overloaded term meaning three distinct things:

  • Kanban (sometimes referred to as “small-k kanban”) is merely the mechanism of managing work via a pull signaling. 
  • Kanban (sometimes called Kanban Thinking, Lean-Kanban, Team-Kanban) is the approach Net Objectives and most Kanban consultants not affiliated with Lean Kanban University espouse.  This is based on using kanban as one method to manage work in process (WIP) within the bigger picture of managing flow.
  • The Kanban Method.  This is the proprietary approach of Lean-Kanban University.   This approach espouses using Kaizen (small changes) only and using WIP limits to manage flow.  It ignores other methods of flow management at the beginning of a transition.

When one makes these distinctions, it is clear that doing kanban and Kanban within SAFe may be possible while doing the Kanban Method is, by definition, not. Our experience is that when SAFe is called for, using the notions of Lean can provide the value of the Kanban Method without its limitations. For more on the differences between the different Kanban methods watch the webinar presented at Agile 2013 – De-Mystifying Kanban: Understanding Its Many Faces, or read article: De-Mystifying Kanban which is similar but a little older.

Three Mindsets in Agile – Lean, The Kanban Method and Classical Scrum

Common Aspects of All Mindsets

All of the above mindsets include the following:

  • Respect people
  • Decentralize control
  • Deliver value quickly
  • Respond to new knowledge
  • Create fast feedback loops
  • Attend to quality

The differences relate to:

  • Management’s role
  • The importance of flow
  • To what extent do you create visibility
  • Should you have explicit policies
  • The role of time-boxing
  • The need for estimation

The Lean Mindset (used by Kanban-Thinking et al, and SAFe®)

We’ll start with the Lean mindset because this is the mindset SAFe is based on. This mindset suggests to:

  • Attend to systems – most errors are due to the system – so that they can support people
  • Shift your attention from the people to the workflow (people are important, but focusing on workflow enables better decisions)
  • Managers have an important role to play and must be included.  This includes taking initiative and providing leadership, not merely helping teams as they ask for it.
  • Attend to flow, that is, attend to time and delays in your workflow
  • Create visibility throughout your workflow
  • Make work policies explicit

Note: SAFe adds some practices to Lean, including time-boxing and estimation, but it does this as a means to improve flow across the enterprise.  There are no Lean principles violated by SAFe.  Many practices that sometimes appear to be a violation (the large batch of a PI) is an explicit accommodation of systems that need to improve.

The Classical Scrum Mindset

There is no longer a single mindset followed by Scrum practitioners. and to a lesser extent, the Scrum Alliance, tend to hold onto many of the ideas first presented in Scrum almost two decades ago.  Practitioners and consultants who have studied Lean principles have adjusted this mindset to be closer to the Lean mindset above.  Nevertheless, if you’ve had certified training in Scrum, it is likely this is the mindset the instructor was coming from: 

  • Management’s role is to support the teams and to remove impediments
  • Visibility of what goes into the sprint and what comes out of the sprint and what is active is important.  But how things are worked on is best left as a ‘black-box’ process so as to allow flexibility and avoid interfering by management.
  • Explicit policies within the sprint are either ignored or discouraged

Flow is typically not discussed, but fortunately is implicitly implemented via time-boxing. Time-boxing and estimation, of course, are key Scrum practices.

The Kanban Method Mindset

From David Anderson’s user group, Kanbandev:

Foundational principles:

  • Start with what you do now
  • Agree to pursue incremental, evolutionary change
  • Initially, respect current roles, responsibilities and job titles

Then adopt the core practices:

  • Visualize
  • Limit WIP
  • Manage Flow
  • Make Process Policies Explicit
  • Implement Feedback Loops
  • Improve Collaboratively, Evolve Experimentally (using models/scientific method)

The principles described above are similar to Lean’s.  The role of time-boxing and estimation is ignored, as is:

  • Balancing workload demand to existing team capacity
  • Creating small batches to come from the portfolio and program level
  • Structuring the organization so that it can deliver value quickly (this means ignoring the potential of forming teams and how teams relate to each other)
  • Looking at the workflow to improve flow through the value stream

These practices are considered to be “orthogonal to the method.” But as I discuss in Why You Should Be Concerned When a Consultant Says “That’s Orthogonal”, there are severe dangers to this attitude. The challenge with this is that many of the up-front changes that are either required or can easily provide value to the organization are ignored and left to later – which often doesn’t happen due to framework myopia.

Re-Framing The Question For SAFe® Practitioners

Once we’ve agreed upon a Lean/SAFe mindset, the question of “can I do Kanban within SAFe?” becomes much simpler.  Now it is more about practices than it is about principles.  And, in fact, many of these practices should be adopted by folks doing Scrum anyway.  In fact, we’re seeing many of these practices being adopted by Scrum practitioners outside of SAFe already.

Kanban at the team level uses the following practices:

  • Create visibility by creating a Kanban board with explicit policies re the workflow
  • Limit WIP levels by focusing on finishing tasks.  This may be via one or more of the following:
    • Dynamic feature teams (short-lived teams that have all the skills needed to complete a feature)
    • Encourage team members to work together, thereby working on fewer things at any one time
    • Not allowing more work in process than mutually agreed upon for each step of the workflow
  • Include management  by providing them visibility in every step of the team’s process

Kanban does not have time-boxing nor estimation.  However, nothing precludes its use.  If one adds these to Kanban the result is a process called Scrumban.  Scrumban was designed as a transition method from Scrum to Kanban, but, in fact, can be used by teams doing Scrum to incorporate the Lean mindset and the Kanban practices of limiting WIP.

Kanban Within SAFe®

Doing Kanban instead of Scrum with SAFe merely requires a fairly normal Kanban implementation that adds coordinating the work of the team with the rest of the teams in the release train.  Strict time-boxing does not need to be implemented.  Here’s how teams would do Kanban at the team-level within SAFe:

Standard Kanban practices to follow (basically, all of them):

  • Create a Kanban board with the following:
    • Explicit workflow policies
    • Agree to methods to manage work in process.  Use one or more of the following:
      • WIP limits at each step
      • Pair or otherwise collaborate to limit number of items in work
      • Focus on finishing instead of starting
  • Manage work with a pull system
  • Implement Acceptance Test-Driven Development (while perhaps not a Kanban standard, this is a standard practice for Net Objectives trained Kanban teams)

SAFe practices to add:

  • Participate in the ART planning
  • Estimate features and stories
  • Break features into small stories
  • Measure velocity based on how many items have been completed since the end of the last ART iteration
  • Work with a product owner to drive what to work on

What Kanban Teams Have to Attend to When Working in SAFe®

Normally, Kanban teams work on items in the order they are on in the backlog.  Little attention is given to items not near the top of the list.  However, Kanban within SAFe requires teams to attend to dependencies across the teams.  Doing this requires picking items to work on not just based on what the team wants to work on but also attending to what stories others are depending upon require. ART planning will identify these dependencies.

While teams don’t necessarily commit to specifics in the upcoming iteration (that is, true iteration planning isn’t necessary), they must commit to a certain velocity (which they have been tracking) as well as select those items others are dependent on within the iteration as needed.

Compared with Kanban Outside of SAFe®

The reality is that many of these additional practices are often useful even when SAFe is not being used. While many in the Kanban community have been berating the use of estimation, velocity and small stories, at Net Objectives, we’ve been espousing these methods even when SAFe is not in use.  Hence, the overhead SAFE puts on what Kanban teams should be doing anyway is somewhat minimal.

Advantages of Knowing Kanban in SAFe®

There are several advantages to understanding Kanban for companies undertaking SAFe.  First, Kanban is used at the portfolio level so understanding Kanban can only help.  However, most large companies have a shortage of certain key players.  These are often subject matter experts (SMEs), architects, people with knowledge of legacy systems and just highly specialized folks.  Kanban can be used to manage the availability of key folks by having a Kanban board just for them and limiting how much they can be given each iteration.

In Summary

Because SAFe is based on Lean, many of the principles that Kanban is based on are already in SAFe.  The practices that Kanban requires can fit into the SAFe framework with little difficulty.  The extra practices that SAFe requires, can fit into Kanban, with little overhead.  Our experience is that as long as teams align within the practices of SAFe teams should be free to do either Scrum or Kanban.

If you are considering doing SAFe please give me a call.  Learn more at our SAFe resources page. See our listing of open-enrollment classes.

Al Shalloway
CEO, Net Objectives

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban