A Kanban team within an ART needs to adapt to some of the requirements prescribed by SAFe to ensure alignment to the ART while still maintaining the benefits of the Kanban flow. The following guidelines address some of those conditions to maintain alignment and allow Kanban teams to contribute effectively within an ART.

While there are no prescribed team roles in textbook Kanban, SAFe calls for the nomination of someone on the Kanban team to fill the roles of a Scrum Master and Product Owner as you would see on a typical Scrum team. The following are the ways you would apply these roles on a Kanban or Scrumban team:

• Product Owner (aka Service Request Manager or Service Manager)
  • Single point of contact for the work of the Kanban team in the Team Backlog (incoming, in progress, etc.)
  • Representation on the Product Management team (PMs, POs for the Train) who define the work of the ART and Teams
  • Attend the PO Sync and represent at the System Demo
  • Accepts User Stories as complete
  • Assigns the User Story to the iteration it is completed in (used for Velocity)
• Scrum Master (aka Service Delivery Manager, Delivery Manager, or Flow Master/Manager)
  • Experience has shown that there is usually an advantage to having someone who worries about how well the team works even for Kanban teams, aka: the coach of the Team
  • Attend SoS and be on point to provide metrics, work impediments, etc.
  • Focus on team performance and improvements
  • Report on team Velocity

SAFe is based on a series of events (meetings) held on a cadence, to synchronize activities across multiple teams. This means that at the ART (team-of-teams) level, Kanban teams that are integrated into an ART need to support these events “as is.”

• PI Planning: to build an aligned plan
  • A SAFe Kanban team is expected to commit to Objectives just like a Scrum team
  • Kanban Teams estimate user stories for capacity and load calculations
  • Kanban Teams plan what they can into iterations (especially for fixed date dependencies with other teams, and any other known work) and usually leave a lot of capacity for the unknown
  • ART Sync (SoS, PO Sync): to ensure we are progressing this PI and getting ready for the next
  • System Demo: to have an objective view of the system we (the ART) are delivering
  • Inspect & Adapt: to help improve the ART (not just team) performance

There is benefit for Kanban teams to establish cadences (e.g., ensures time is taken to do the work, makes unpredictable events more predictable, etc.), but unlike Scrum, Kanban teams do not have to use the same cadence for all events. By understanding the purpose of an event, we can determine approaches we could bring into our Kanban implementation.

• Daily Standup - Kanban Teams meet daily, but rather than just answer questions aimed at understanding whether we will meet the Iteration goal, these meetings are usually needed to prioritize work and plan the teams’ work for the day.
  • Use a Kanban Board as a tool to help visualize the work during this event.
• Planning – Kanban Teams focus more on prioritizing the next pieces of work than planning an iteration of work. This is done in the Daily Standup, where teams will decide which stories they will be working on that day and ensuring they are story pointed. If needed, teams may schedule a separate prioritization or refinement meeting which should then be on a cadence (e.g. every week).
• Refinement - For Kanban teams this is usually incorporated in the daily prioritization/planning discussions.
• Review/Demo - The purpose of the review / demo is to get feedback on the work completed. Kanban teams often demo individual stories as they are completed to get feedback. Many Kanban teams also report lack of participation from customers to these demonstrations, and so see a benefit in setting up a regularly scheduled Review event every couple of weeks where multiple stories are demonstrated.
• Retrospective - The purpose of a retrospective is to take time to improve how we work. Many Kanban teams set up a cadence of retrospectives to ensure it gets done.
  • At a minimum recommendation is to set up a retrospective at least once every two weeks, so once an iteration.
  • Consider a shorter cadence to improve faster (e.g. weekly, daily)
  • Consider retros as flow based in lieu of a standalone event (see What Can We Do To Improve Our Retrospectives? e.g. POPCORN flow)
  • Be sure to move improvement items into the team’s backlog

A Kanban board is an agile project management tool designed to help visualize work, limit work-in-progress, and maximize efficiency (or flow). When implementing a Kanban board for your team, it's important to include the following:

• Workflow States
  • Map the teams’ workflow to define the states (columns) of the Kanban board
    • The more workflow states (columns) that are defined (beyond To do, In progress, and Done), the easier it is to identify bottlenecks and optimize the flow.
    • Having more than say 10 workflow steps will result in higher administrative burden, and create a board where it is hard to see the big picture
    • Refrain from basing workflow states on people/individual skill. This allows team members to swarm to a different state as needed.
    • Enable the “pull” method by using “in progress” and “done” states (e.g. Development Done, Testing Done, or Ready for Test). Stories can be pulled from the “done” states as the WIP limits allow.
  • Define clear exit agreements for each State (e.g. code checked in, documentation updated, unit tests run, iteration updated at acceptance). These can be added directly to the Rally “Team Board”.
• Classes of Service (aka Service Level Agreements)
  • Classes of Service are used to prioritize work based on Cost of Delay – or in other words, prioritize based on urgency and economic impact. Examples include:
    • Expedite – highest priority or cost of delay, not to be interrupted
    • Fixed Date – high cost of delay (e.g. deliverable/dependency to another team)
    • Standard – low to medium cost of delay, typical for most work
    • Investment – intangible; lowest cost of delay (e.g. maintenance task with low prioritization)
• Work in Progress (WIP) Limits
  • WIP limits restrict the maximum number of work items in the workflow's different stages
  • WIP limits are set based on capacity and adjusted as needed to optimize the flow of value delivered
    • A good rule of thumb to start with is to set WIP for a state to the number of people who are skilled in that Status minus one.
  • WIP limits allow an opportunity to identify bottlenecks in workflows, which can be easily identified on a Cumulative Flow Diagram.

In Kanban, Cycle Time is a key metric for measuring team performance, process efficiency and identifying bottlenecks.

• Cycle time is calculating the actual work-in-progress or the time between the work on a user story beginning to the time it is accepted. Keeping track of your cycle times enables you to measure your team performance.
• Low cycle times mean that your team is efficient. Keeping cycle times down keeps lead time down. The key to keeping cycle time down is managing WIP limits – maybe you’ve heard the phrase… “Stop Starting, Start Finishing”
• High cycle times indicate stalls, bottlenecks, and backlogs.

A Cumulative Flow Diagram (CFD) visualizes your teams’ workflow (cycle time, WIP, bottlenecks) by charting the total number of work items in each workflow state per day. It’s a fundamental Kanban tool used to understand where teams may need to focus to make their process more predictable and efficient. Ideally you want to see evenly rising bands on the chart as opposed to sudden spikes or flat lines, so watch out for the following:

• An expanding “work in progress” state may be an indication of a bottleneck or potential problem.
• A narrowing state may indicate that you have too much capacity in that state.
• Stepped flat lines suggest work is being batched rather than continuously flowing.

Traditional Kanban teams use cycle time and through-put to understand how much work they can take on (capacity) and forecast when items will be completed. Scrum Teams in SAFe use story points and velocity to accomplish the same thing. The ART Product Management Team needs to be able to understand capacity of the ART and forecast completion. We therefore need a common unit of measure for all teams on the ART – story points!

• In SAFe, Kanban teams estimate their work in story points, and as stories are completed it’s important to that the PO updates the Iteration it was completed in when they accept the stories. This then allows teams to report back their “velocity” by calculating how many story points they completed in the previous two weeks.
• Kanban teams estimate all incoming items (including defects, KTLO, etc.) in story points prior to working on the item using:
  • Relative size estimation based on modified Fibonacci numbers – 1, 2, 3, 5, 8, 13, 20, 40, 100
  • Normalized per SAFe guidance so that stories with estimates of 8 and below can typically be completed in a two-week period (iteration).