New and Updated Kanban Articles provide more effective guidance for using Kanban in SAFe
We are excited to announce some additional new guidance for applying Kanban in SAFe. As you know, Kanban systems are already used to manage backlog flow at every SAFe level (see Figure). Each Kanban reflects the unique activities at the level for delivering value, describing the workflow, and applying work-in-process (WIP) limits.
We are extending our guidance with a new article on Applying Kanban in SAFe. It describes how to establish a Kanban system, the various elements of the Kanban board, and how these systems are connected to help strategy changes flow quickly across value streams to the teams who do the work.
And now, with the growing trend of companies expanding SAFe into areas beyond IT, other business units—from marketing and finance to legal, security, operations, and more—are appreciating the unprecedented level of visibility provided by Kanban. Therefore, we are also pleased to announce an extensive update to the SAFe Team Kanban article, which better describes using Kanban as a primary team method. And of course, Scrum teams can also leverage this guidance to enhance the visibility and flow through their process. Taken together, we hope these articles deliver more effective guidance for using Kanban alongside Scrum in SAFe.
— The Framework Team with Richard Knaster, SAFe Fellow
Dan Miklusicak, SPC5
It might be useful to connect the dots to team topologies mentioned in the agile team article, and reinforce which ones are likely to use kanban as well as scrum of course.
Thank you for the suggestion Dan!
We have acquired some groups that follow Kanban and we are attempting to not be dogmatic about the sprint team ALM. What we are struggling with is 90% of the teams use Scrum and with our PI planning the kanban teams dependencies on Scrum teams aren’t getting called out. As a result, the Kanban team may find out too late about a dependency. What are articles that can talk me through how to resolve this?
Hi Mike! The community forums in the community login are great places to get advice from peers on more detailed ways folks around the world have solved items like you bring up here. From what I’ve experienced personally, Kanban teams still participate in planning like Scrum Teams do. This means the full set of teams are still responsible for talking through dependencies and aligning on when they need things from each other per usual. Kanban teams still create objectives and align on milestones. Throughout the PI, all teams, regardless of type, will still also utilize syncs, demos, etc across the ART to align and communicate and update dependencies.
Great update. Makes a great contribution.
One thing I have seen that makes sense (which you also touch in the ‘Program and Solution kanban’ section) is to have seperate Kanbans for Epics on the Solution and Program level with regards to capabilities and features. The main reason off course being that Epics and Features/Capabilities are following different procceses and are used for different purposes. There are cases where it makes sense to have a complete Lean Business case and follow the Lean Startup cycle on Solution and/or Program level.
That would give that there in reality are two additional possible Kanbans, a Solution Epic Kanban and a Program Epic Kanban.
Perhaps this perspective is lost in the visualization but could be something to think about in next iteration/update.
Thank you Alex for the comments and suggestions. It’s true that Epics and Features/Capabilities could have different criteria for entering or exiting a Kanban state. It’s also true that the combined work is important to view for Solution and Program level to ensure capacity allocation and prioritization are done with all due consideration. We’ll continue to look to provide helpful visuals that tell the full story and appreciate your feedback.