On Kanban Teams in Scaled Agile
In a Scaled Agile organization (specifically referencing SAFe) we occassionally consider the need for a team to follow Kanban rather than the more common Scrum. This decision makes sense in many cases, but comes with special considerations for how to handle integrating a Kanban team into a SAFe Release Train that has primarily been using Scrum.
First we need to be clear between a team using Kanban, and a Release Train or Scrum team that is using a Kanban board. In SAFe we use Kanban boards at every level to help visualize the work in progress. Here we are specifically addressing an agile team within a Release Train that is choosing to use Kanban flow rather than Scrum and iterations.
Why Kanban in a Scaled Agile Organization
The decision to use Kanban in a SAFe organization is a decision to focus on flow of work to better manage the nature of the work. This is typically work that will come in quickly, where the team may need to shift priorities based on the class of work.
Some teams try to make this decision based solely on the perceived overhead of planning, or limitations of timeboxes, with Scrum and iterations. Take caution here. The planning involved in Scrum is invaluable, as is the timebox, both of which tie in with the broader planning and forecasting that is critical to a Scaled Agile organization. When making this decision focus on the type and predictability of the work, and any need for flexibility to plan on-the-fly and adjust priorities.
The Kanban approach often works well with System Teams, various types of operations and support teams, and Shared Services teams.
Considerations for PI Planning
As a Kanban team coming into PI Planning, we likely have a different purpose and approach than many of the other teams in the planning session. However, our outcome is essentially the same, a plan and commitment for the scope of work we expect to complete during the PI.
Coming Into PI Planning
Coming into PI Planning we will prepare in a few different ways.
First, we will define the scope and responsibilities of the team, and share that with the rest of the teams in the Release Train. This will outline the types of work the team expects to cover, likely to include the type of support they provide to other teams, and/or work they will be doing independent of other teams. This outline helps those other teams know what they can expect from the Kanban team, and should help those other teams know what is expected of them by the Kanban team. We may even want to review this in day 1 of the PI Planning session.
Second, we need to have a plan for how we forecast what the team can accomplish within the PI. With a Scrum team we may have forecasted based on some anticipated velocity per iteration, extrapolated to the number of iterations within the PI. With a Kanban team we will forecast based on an anticipated capacity, but will look at capacity across the full PI rather than per iteration, assuming a steady flow of work. With a new team we will plan based on an assumption of weekly throughput. For an existing team we will leverage past cycle time and throughput data and a Monte Carlo simulation to generate the forecast.
And last, we will come in with a backlog of known work, just like every other team. This will include Features and Stories, as prioritized by our Product Owner. This backlog may include Enablers in support of our team, as well as in support of other teams across the train. The team may also have identified other stories for their backlog based on work being handled by other teams, such as stories for Solution Integration or End to End Testing which may be the final steps for Acceptance of a Feature.
During PI Planning
System Teams, support teams, and Shared Services teams have a special role in PI Planning. In addition to discussing their own planned work, these teams will spend as much time in the breakout sessions from other teams.
The capacity plan for a Kanban team assumed there will be a steady flow of work for the team throughout the PI. The team should check in with other teams across the Release Train as part of PI Planning, looking for work that wasn’t previously identified, either needed from or in support of other teams, as predecessor work or successor work. Especially watch for potential peaks, and discuss with the teams any options for smoothing out these peaks.
Aligning with Scrum Teams
Throughout the PI the Scrum teams align exection with a common cadence based on consistent iterations. Every Scrum team follows the same schedule, starting and ending their iterations at the same time. This helps those teams in several ways, including setting an anchor for teams to integrate and evaluate their work, and provides a planning checkpoint to refine any cross-team dependencies.
As a Kanban team we would leverage those same integration anchors and planning checkpoints.
Sprint Planning Checkpoint
When other teams do their planning and cross-checking at the start of a sprint, so will the Kanban team, using that as an opportunity to check for more specific updates from teams, confirm those specific dependent work items, and check against our forecasted capacity.
Unlike the Scrum teams’ 2-week cadence, the Kanban team should keep their Replenishment meetings on a regular weekly cadence. The key drivers for the decision to follow Kanban rather than Scrum is the need for flexibility to plan on-the-fly and adjust priorities, and the more frequent Repenishment meetings.
Sprint Review Checkpoint
At the end of a sprint when teams across the Release Train are integrating and evaluating their work, it may be one of the Kanban teams executing that integration and evaluation, and would be including their own work into those efforts. As work was Done we checked that it met the need, and here we will re-validate and re-confirm the outcomes in context of the larger work effort of the Release Train.
Additional Reading
Kanban vs. Scrum | Atlassian Kanban vs. Scrum | SAFe Team Kanban | Kanbanize Kanban vs. Scrum | Monte Carlo Simulation | SAFe Shared Services | SAFe System Team | Kanban Meeting Cadence