From Pain to Flow: SAFe Dependency Boards

The ART Planning Board is a key artifact used in PI Planning and Execution. The ART Teams and Stakeholders used it to align, anticipate risks, and adapt the plan accordingly.

This “inspection and adaptation” of the plan based on insights from the ART Planning Board is “first loop learning” — making changes in the plan based on what we see.

What we rarely see, though, is deeper learning from what the ART Planning Board shows us. It’s like the good old times where you would see a project manager / PMO working their MSProject Gantt Chart, moving things around, but rarely stopping to ask deeper questions around the base structure of their plans and why they’re based on a waterfall model.

ART Planning Boards can drive deeper learning about the structure of our ART and its alignment with the kind of mission/vision we’re pursuing and the backlog of features we’re working on. If we see too much red yarn on our boards it isn’t something to be proud of. Yes, we can be proud that we identified the dependency and even more that we were able to massage our PI plan to deal with it in a reasonable way. But too much red yarn means too many dependencies. Too many dependencies mean our Value Stream Network isn’t configured well. It means we should probably look at ways to reconfigure the network (meaning restructure teams and maybe even the ART).

I get it. This sort of learning is hard to pursue in the heat of PI Planning. And all too often when PI Planning is done and we have a workable plan in hand its tempting to just move into execution. Resist the temptation. Let the dust settle, but find the time that makes sense to have a deeper retrospective that is based on the patterns you see on the Program Board. This can be a good discussion in your Scrum of Scrums or with an extended forum that includes the wider ART leadership.

There’s no need to wait for the next Inspect and Adapt. It’s fresh now and outcomes from this retrospective might anyhow require a lot of refinement and consideration before they’re actionable. Start the process early in the PI so hopefully, you’ll be in a position to reconfigure the network going into the next PI as needed.

A typical pattern is when such a retrospective raises the need to rerun a Value Stream Identification workshop.

Speaking of the VSI workshop, one key element many practitioners skip is validating their value stream design hypothesis. After identifying a Development Value Stream, run some water through the pipes — take some work in the form of Features or even higher-level Epics/Themes and explore how they will flow through this value stream/ART/Solution ART. If the work flows nicely with a minimal number of dependencies, you have found a good setup. If even in this “dry run,” you already see you have too many dependencies — time to rework the design!

And yes, what this means is that ideally, even in this early phase, before even launching the ART, you should consider doing a light version of PI Planning as a dry run with the value stream design you have in mind to see that it makes sense. You don’t want to train everybody, spend a serious amount of time preparing to launch the ART, and then find that it’s not self-sufficient or that it’s comprised of teams that aren’t self-sufficient.

It’s so easy to focus on managing. It’s much harder to take a step back and reflect. But that’s where your real impact as a leader is—these are the higher-leverage activities. How much time do you spend on managing the work vs reflecting on what the work tells you?

Connecting OKRs to SAFe portfolio governance is one of the most common integration challenges I help organizations solve. Explore SAFe and OKR advisory or let’s talk.