It is said that improvement is eternal and infinite. It should be the duty of those working with Kanban to keep improving it with creativity and resourcefulness without allowing it to become fixed at any stage.

Taiichi Ohno

SAFe Team Kanban

Find a Course:

Implementing SAFe
Leading SAFe
SAFe for Teams
SAFe Scrum Master
SAFe Advanced Scrum Master
SAFe Product Owner / Product Manager
SAFe Release Train Engineer
SAFe DevOps

Team Kanban is a method that helps teams facilitate the flow of value by visualizing workflow, establishing Work In Process (WIP) limits, measuring throughput, and continuously improving their process.

As described in reference [1], “Kanban comprises the following three practices working in tandem:

  • Defining and visualizing a workflow
  • Actively managing items in a workflow
  • Improving a workflow.”

In SAFe, Kanban systems manage the backlog and flow of work at every level of the Framework. Each reflects a team’s unique process for delivering value and its current workflow and capacity.

Details

Most Agile Teams use SAFe ScrumXP as their primary method to deliver value. However, some teams have a rapid and uneven arrival of work and fast-changing priorities that lowers the value of detailed planning.  These teams often choose SAFe Team Kanban as their operating model. For example, System Teams, operations, support, hardware, and various business teams (e.g., Marketing, Sales, People Operations), often find SAFe Team Kanban a better choice for their context.

In addition, the level of visibility and flow that Kanban provides is causing it to spread to different parts of the organization. Today, many organizations adopt Kanban to help embrace Lean-Agile principles across all aspects of business, from marketing to finance, human resources to legal, security to compliance, operations to Agile Teams, and more.

Like all SAFe Agile Teams, Kanban teams determine how they manage their work. They create and refine backlog items—typically expressed as Stories with acceptance criteria—to define and achieve their Team PI Objectives. They then build, integrate, test, validate, and deploy the new functionality, ensuring built-in quality.

And since Kanban teams typically have all the roles and skills needed to develop and deliver increments of value, they are designed to operate with the minimum possible constraints and dependencies with other teams. A self-managed and cross-functional Kanban team creates a more enjoyable, fun, and productive work environment with constant communication, constructive conflict, and dynamic interaction.

The SAFe Team Kanban Board

A Kanban system is generally characterized by a ‘Kanban board’ that includes or references the elements shown in Figure 1.

Figure 1. Elements of a Kanban board
Figure 1. Elements of a Kanban board
  • Work in Process (WIP) limits set the maximum number of items that can exist in an individual workflow state.
  • Columns represent a series of steps, each representing an activity that collectively defines the team’s workflow.
  • Cards represent work items, such as user stories and enablers.
  • Swim lanes group and highlight related work items to define the team’s workflow. Typical use of swim lanes includes separating work for different classes of service, cross-team dependencies, features, and more.
  • Policies specify how work is managed, such as exit or entry criteria for moving a work item from one state to another or defining the rules for service classes.

The SAFe Team Kanban Method

While the Kanban method provides guidance for managing work in a flow-based system, it is not explicit with respect to the roles, responsibilities, and events that teams use to apply Kanban as their Agile practice.

SAFe addresses this as illustrated in Figure 2 below. Each element of the SAFe Team Kanban method is described in the following sections.

Figure 2. SAFe Team Kanban method overview
Figure 2. SAFe Team Kanban method overview

Team Backlog

The Team Backlog contains all the upcoming work needed to advance the solution. Teams continually refine the backlog to ensure it always has some stories ready for implementation without significant risk or surprise.

During PI planning, Teams decompose Features into stories in the backlog and establish their PI Objectives. The team’s local concerns (other new functionality, defects, refactors, tech debt, and maintenance) are also in the backlog. These stories reload the team backlog for the upcoming PI. But since PI planning is high level, teams will likely need to adjust their plans as stories are refined, acceptance criteria are established, and other new facts emerge,  Moreover, feedback from prior increments, the System Demo, and other groups with whom they collaborate provide rolling wave updates to the backlog and flow of work.

Plan

Although the flow of work is continuous, planning is valuable in Agile and Kanban teams are no exception. Many Kanban teams plan weekly to coordinate their work, replenish stories in the backlog, and address dependencies and fixed date commitments. Many Kanban teams find it convenient to align their weekly planning with the iteration cadence of the ART. Once complete, the team records the planned work in a visible place, such as a physical Kanban board or Agile project management tooling. A weekly planning time box of 60-90 minutes is typical.

Deliver

In SAFe, teams apply Kanban within the development cadence and synchronization requirements of the Agile Release Train (ART). They like others, Release on Demand. This facilitates alignment, dependency management, and fast integrated learning cycles (SAFe Principle #4) across the ART.

The Kanban system visualizes all active and pending work, workflow states, and WIP limits. A work item can be pulled into a state only when the number of items currently in that step is below the WIP limit. A few activities (typically beginning and end) may not be limited. WIP limits are defined and adjusted by the team, allowing it to adapt quickly to the variations in the flow of complex system development.

Team Sync

In addition to the weekly planning meeting, Kanban teams coordinate their work throughout the week. The team decides if these syncs are cadence-based or ad hoc. The tempo and timing can vary significantly based on stages of development. A typical pattern is holding a team sync weekly around midweek. Kanban teams typically discuss the following kinds of topics during this time:

  • Review how work is flowing and remove impediments
  • Peer review of WIP and adjust upcoming planned work
  • Review and accept stories into the system baseline
  • Discuss improvements to the team’s process
  • Planning for the system demos that occur throughout the PI
  • Monitoring fix date commitments and flow metrics

In a flow-based system, it is desirable that much of the work can be released into later stages without formal signoffs or approvals other than as described in the team’s policies. Therefore pairing and swarming are routine and informal to help better assure built-in quality prior to deployment.

System Demos

Like all SAFe Agile teams, Kanban teams participate in the ART’s System Demos, representing another form of syncing within the team and across the ART. This ensures the team’s work is integrated into the solution, and progress is demoed where appropriate. It also fosters and enables collaboration with other teams and stakeholders to assess the solution, making mid-course corrections as necessary.

Increment

Kanban teams deliver small increments of value throughout the PI, representing how new functionality evolves. Each increment is additive and is a working, tested, and usable solution element.

Retrospect

Kanban teams periodically reflect and identify new ideas to improve their process. This retrospective helps instill the concept of relentless improvement—one of the SAFe Core Values, ensuring that the team makes improvements continually. Teams may conduct a retrospective at any time, but most typically they happen towards the end of a PI, prior to the ART’s Inspect & Adapt (I&A) event. In this way, the knowledge from their team retrospective can inform the problem-solving part of the ART I&A.

Kanban Roles

While Kanban is generally less specific on team roles than Scrum, SAFe applies the same two special Agile team roles as defined in ScrumXP. These roles —the Product Owner and the Scrum Master—have emerged in practice as being equally helpful to SAFe Kanban teams (Figure 3).

Figure 3. Typical SAFe Kanban team
Figure 3. SAFe Kanban team roles

The Product Owner (most typically a full-time role) understands the needs and expectations of customers and facilitates the selection and ordering of work items that the team will work on next. They serve as the Kanban process intake owner and prioritize the team backlog to help ensure the team is building the right thing.

The Scrum Master (which may be a part-time role) is responsible for helping coordinate the flow of work, in this case, coaching Kanban, rather than Scrum, practices. They mentor the team in Lean-Agile principles, help remove impediments to progress and facilitate team self-organization and management. They also foster an environment for high performance and relentless improvement.

Establishing the Team Kanban

Implementing an effective Kanban system adapted to meet the needs of a specific Agile team is based on the type of work performed (e.g., software development, hardware, marketing), the team members’ skills, and the team’s role in the ART. Establishing the Team Kanban system is best done by involving the entire Agile Team with the guidance and facilitation of an experienced coach. The SAFe extended guidance article, Applying Kanban in SAFe, describes how to establish a Kanban system as well as how the Kanban systems are connected in SAFe. Figure 4 below illustrates an example of a more fully elaborated Team Kanban system.

Figure 4. Example team Kanban system
Figure 4. Example team Kanban system

Improving and Measuring Flow

Measuring Flow

Kanban systems provide a rich set of data that can identify bottlenecks and improve flow due to the nature of the work items and the specific states and dates tracked. Several standard metrics can measure different aspects of flow. These include—Flow Distribution, Flow Velocity, Flow Time, Flow Load, Flow Efficiency, and Flow Predictability (see Measure and Grow).

Optimizing Flow

A team’s Kanban board should evolve iteratively and continuously adapt to fit the team’s needs. After defining the initial process and WIP limits and executing for a while, bottlenecks should become visible. If not, the team refines the process or further reduces some WIP limits until it becomes evident that a workflow state is overloaded or starving. Other changes to optimize flow might include merging or splitting steps, adding buffers, or redefining workflow states.

Estimating Work

Due to the rapidly changing nature of work items, there is typically less emphasis on estimation than in Scrum. Instead, Kanban teams look at the work needed, right-size it by splitting large items where necessary, and pull the resulting work through the Kanban system to completion.

However, SAFe teams estimate the demand for work against their capacity during PI planning and help contribute to story point estimates for larger cross-team backlog items (Features, Epics).

 


Learn More

[1] https://prokanban.org/the-kanban-guide/

[2] Anderson, David J. Kanban: Successful Evolutionary Change for Your Technology Business. Sequim, Washington: Blue Hole Press, 2010.

Last update: 26 July 2022