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

Program and Solution Kanban

The Kanban systems help Agile Release Trains (ARTs) and Solution Trains match demand to capacity based on Work in Process (WIP) limits, and visualizing bottlenecks in each process state helps identify opportunities for relentless improvement (described in the SAFe House of Lean). The Kanban system also includes policies governing the entry and exit of work items in each state.

Details

Implementation and management of the program and solution Kanban systems occur with the support of Product and Solution Management. Implementing the Kanban systems requires an understanding of Lean and Agile development and how capacity is available for new development, business-as-usual maintenance, and support activities. When these are understood, the Enterprise can then evaluate Essential and Large Solution level initiatives logically and pragmatically, supporting their analysis and forecasted timing for implementation based on appropriate metrics.

Kanban systems are the primary mechanism to achieve SAFe Principle #6 – Visualize and limit WIP, reduce batch sizes, and manage queue length, as well as the Lean concept of flow. These systems provide many benefits:

• Increase visibility into existing and upcoming work, and better understand the flow of work
• Ensure continuous refinement of new value definition and acceptance criteria
• Foster collaboration across disciplines, functions, and levels
• Support economic decision-making by setting the policies for the pull-based mechanism
• Establish connections between the ARTs, Solution Train, and Portfolio

The Program Kanban

The program Kanban facilitates the flow of Features through the Continuous Delivery Pipeline. Figure 1 illustrates a typical program Kanban, as well as example policies and WIP limits governing each state.

New ideas begin with Continuous Exploration and may originate locally from the ART or come from an upstream Kanban (e.g., solution or Portfolio Kanban). Local content authority, Product Management, and System Architects manage this Kanban. The following process states describe its flow:

• Funnel – All new ideas are welcome here. They may include new functionality,  enhancement of the existing system functions, or Enabler work.
• Analyzing – New ideas that align with the Vision and support the Strategic Themes are further explored by Agile Teams when they have available capacity. Refinement includes the collaboration to turn the loosely-formed idea into one or more well-formed features with descriptions, business benefit hypotheses, acceptance criteria, and sizes in normalized story points. Each feature may require prototyping or other forms of exploration by Agile Teams. The WIP limit for this state must account for the availability of Product Management as well as the capacity of teams and other subject matter experts.
• Program Backlog – The highest-priority features that were analyzed and approved by Product Management advance to this state, where they are prioritized with Weighted Shortest Job First (WSJF), relative to the rest of the backlog, and await implementation.
• Implementing -Features are pulled into the Implementing state as teams start working on them during the Program Increment (PI). During the PI Planning process, Features are split into stories, planned into iterations, and subsequently implemented by teams throughout the PI.
• Validating on staging – During each iteration, features that are ready for feedback get pulled into this state. The teams integrate and test them with the rest of the system in a staging environment (or its closest proxy) and then present to Product Management and other stakeholders for approval. Approved features move to the ‘ready’ part of this state, where they’re prioritized again using WSJF to await deployment.
• Deploying to production – When capacity becomes available for deployment activities (or immediately in a fully automated continuous delivery environment) the feature gets moved to production. In systems that separate deployment from release (see Continuous Deployment for more details), the feature moves to the ‘ready‘ part of this state to await release. In other systems, the feature automatically moves to the releasing state because once it arrives in the production environment, users can immediately access it. This state is WIP limited to avoid the buildup of features that are deployed but not yet released.
• Releasing – When there’s sufficient value, market need, and opportunity, features are released to some or all of the customers, where the evaluation of the benefit hypothesis happens. While the feature moves to the ‘done‘ state, new work items may be created based on the learning gathered from the feature.

The Kanban system described here provides a good starting point for most ARTs. However, it should be customized to fit the ART’s process, including the definition of WIP limits and the specific policies for each process state.

Program Epic Kanban System

Some ART initiatives are simply too big to be completed in a single PI.  These Program Epics, identified and managed in a separate Kanban system, as shown in Figure 2. Also, some portfolio epics may require splitting into solution and program epics to facilitate incremental implementation. While mainly a local concern, program or solution epics have an impact on financial, human, and other resources that might be large enough to warrant a Lean business case, discussion, and financial approval from Lean Portfolio Management (LPM). Epics whose estimates exceed the portfolio epic threshold require review and approval. This is an important Guardrail on budgetary spending.

The primary purpose of this Kanban system is to analyze and approve program epics, splitting them into features that will be further explored and implemented using the program Kanban. Depending on how frequently program epics occur in the local context of the ART, this Kanban system may not be required.

The program epic Kanban may require the engagement of large solution or portfolio stakeholders to explore and approve the program epics. The process states in this Kanban usually follow those in the Portfolio Kanban, for example:

Funnel – All big program initiatives are welcome in the ‘funnel‘ state. There is no WIP limit.

Reviewing – This is where subject matter experts and stakeholders perform the review of the epics and prioritize them using WSJF to determine which ones should move on for more in-depth exploration. Again, WIP limits apply.

Analyzing – During this diagnostic and exploration state, subject matter experts and stakeholders are encouraged to:

• Refine size estimates, and WSJF relative to other epics
• Consider solution alternatives
• Identify possible Minimum Viable Products (MVPs) and Minimum Marketable Features (MMF)
• Determine the costs involved, technology and architectural enablement, infrastructure, using a Lean business case (described in the epics article).

Guided by analysis and insights, Product Management along with  Business Owners (and typically Lean Portfolio Management personnel) approve or reject the epics. Approved epics then get split into features and transitioned to the funnel of the program Kanban, where they will be prioritized based on WSJF. WIP limits also apply to the analyzing state.

Similar to the portfolio level, program epics may require Epic Owners to help with the definition, exploration, and implementation.

Managing the Program Kanban with the ART Sync

One significant program event is the ART sync event (see Program Increment), where Product Management and Product Owners review the program Kanban system and pull in more work based on the available capacity at each state. Participants discuss new work, prioritize, schedule meet-afters, and make deployment and release decisions as needed.

Further, the Program Board (see PI Planning) facilitates reviewing items in the ‘implementing’ state, including discussion of dependencies and execution.

The Solution Kanban Systems

This article described the program Kanban systems in depth. For organizations using Large Solution SAFe, the solution Kanban follows the same structure and process used for the program level. However, Solution Management and Solution Architects manage this Kanban, which operates with Capabilities instead of features. Also where useful, teams employ a Solution Epic Kanban for solution epics that mirror the Program Epic Kanban.

Last update: 10 February 2021