Learning from the SAFe Program Dependency Board
The SAFe Program Board or Program Dependency 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 Program Dependency Board is “first loop learning” — making changes in the plan based on what we see.
Deeper Learning from the Program Dependency Board
What we rarely see, though, is deeper learning from what the Program Dependency 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.
Program Dependency 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).
When to do this deeper learning
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.
Validating the Value Stream Design Hypothesis — A Key but often Skipped step
Speaking of the VSI workshop — one key element in it that many practitioners skip is the validation of your 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 found a good setup. If even in this “dry run” you already see you have too many dependencies — time to rework the design!
PI Planning Dry Run
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 on preparing to launch the ART, and then find its not a self-sufficient ART or that it’s comprised of teams that aren’t self-sufficient.
Summary
I’ve talked about some recommended practices here, some are implicitly mentioned in SAFe, some complement the formal guidance. The key point I wanted to make is how important is it to aim for the right value stream network and to continuously inspect and adapt so that value can easily flow with minimal dependencies and slowdowns. And if your value stream network is configured well, everything else becomes much easier.
Originally published at https://www.agilesparks.com on September 17, 2020.