Scaled Agile, Inc. and ProKanban.org: Friends or Enemies? How effectively does #SAFe manage flow within its framework?

Short comparison: SAFe: Multiple-Level Kanban + Inspect and Adapt and much, much more... ProKanban: Minimum Viable Kanban... let's have a deeper look what are common truths you could take away as a valuable support for your systems?

If you dont like long articles feel free to skip to the last paragraph the essence is there! :)

Adopting the starting patterns, such as changing the basic portfolio Kanban or any team Kanban over time, seems to be hard for SAFe customers; however, this is encouraged by SAFe. SAFe also endorses ProKanban, although it doesn’t delve as deeply into Kanban. The fundamental principle of flow is common to both. Understanding and committing to limiting WIP is emphasized by both.

The original problem of cadences that ProKanban stresses also exists in SAFe. PI planning and iterations can create more push than pull, and this must be managed carefully. The art of letting value flow even troughout iterations and PI intervals is hard to master. Have a look and if you have a feeling that you live in a start-stop environment think about it. Introducing Kanban teams in SAFe is a step in the right direction.

Focusing more on aging of features in progress and the idea of estimating service level expectations, while actively monitoring them using scatterplots instead of histograms, is a great enhancement to SAFe implementations. (For example, 85% of our features have 30 stories or fewer, taking 8 weeks or less) I agree that SAFe could work on the next iteration of cost of delay to be more precise about value and prioritization based on value. The idea of predictability and forecasting in a stabilized system could also be a great addition to SAFe. (https://actionableagile.com/books/aamfp/)

The criticism that the EPIC-level Kanban is too prescriptive and lacks sufficient WIP limits in practice may be true at the implementation level, but the theory is sound. No one says we have to stick to the initial portfolio Kanban setup. It’s a SAFe implementation anti-pattern that teams and ARTs start too many things. Yes, less WIP is better, but not pulling in work at all until the rest is ready would be best.

Bashing the ART predictability metric warms my heart. Measuring planned vs. delivered business value never made sense to me—it has nothing to do with predictability. I would rather measure the actual value of things delivered to the market and, in parallel, regularly check if and when we can deliver (real continuous predictability). And while we’re on the topic of delivery… velocity and story points need to go. Now! I love to use estimation excersies as such to create better understanding around a work item just make sure you get rid of these numbers immediately after the meeting just as self exploding secret agent briefing.

Typical SAFe customers should do more upstream work as I see. Just in time or shortly before PI plannnig work injection shouldnt happen in flow based system this frequently. Even SAFe talks about this as something that should be done continuously. Perhaps extending all levels of Kanban with a few upstream columns with limited WIP would help and make it look less like a push system. Look at SAFe’s flow accelerators they are great if you take them MUCH MORE SERIOUSLY!

On the metrics side, SAFe Principle 6 has great examples to start with (https://scaledagileframework.com/make-value-flow-without-interruptions/). People should be MUCH MORE familiar with it and USE IT!!! The article on coaching flow is great too (https://scaledagileframework.com/coaching-flow/) you may read it again and again and again!

In terms of measuring flow, SAFe gives us Flow Distribution, which measures the proportion of work items by type in a system. This is useful for creating more transparency. Flow Velocity measures the number of completed work items over a time period, which is very close to ProKanban’s “throughput” (although the word velocity doesn’t make this metric very likable, lol). Flow Time measures the time elapsed from start to completion for a given work item, which is essentially cycle time in ProKanban terminology. Flow Load measures the number of work items currently in progress (active or waiting), which also aligns with ProKanban—they just call it WIP. Flow Efficiency is the ratio of total time spent in value-added work activities divided by flow time. This is cool stuff, although almost impossible to measure. Flow Predictability measures how consistently teams, ARTs, and portfolios meet their commitments based on predicted business value versus actual business value. As I mentioned earlier, this metric doesn’t sit well with me and can easily trigger dangerous anti-patterns.

Once again: LIMIT WIP, think smaller, right-size features and stories, GET FEEDBACK (What’s the smallest thing we could get feedback on?), measure aging in real-time, use service level expectations, don’t let time-boxes destroy flow, regularly refine your workflow stages, and continuously deliver the current highest priority IF you have the capacity. Learn to push things back to avoid unlimited work intake (which kills your systems today). It doesn’t matter if it’s SAFe, Scrum, or Kanban—don’t use anything from a framework that isn’t working for you. However, first discuss with a real expert why it’s not working.

Other than that: go crazy! ?? You’re allowed to do whatever you want! ?? Stay flexible, deliver value! ??