Search
Close this search box.
Search
Close this search box.
Search
Close this search box.

SAFe Program Dependency Board Retrospective

Facebook
Twitter
LinkedIn
Pinterest
WhatsApp
Program Board Discussion

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 when you would see a project manager / PMO working their MSProject Gantt Chart, moving things around, but rarely stopping to ask deeper questions about 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.

 

Subscribe for Email Updates:

Categories:

Tags:

Agile Israel
Professional Scrum Master
Software Development
Rapid RTC
Nexus and SAFe
Acceptance Test-Driven Development
Agile Program
Lean-Agile Budgeting
Built-In Quality
Frameworks
ScrumMaster Tales
Agile Release Planning
Agile India
ART Success
Code
Kanban
Continuous Improvement
Scrum Master
Presentation
Continuous Deployment
DevOps
Manage Budget Creation
Risk Management in Kanban
Tips
Releases Using Lean
Agile
Kanban 101
Enterprise DevOps
Change Management
Kaizen
A Kanban System for Software Engineering
speed at scale
Jira
Self-organization
RSA
Advanced Roadmaps
Risk-aware Product Development
AI Artificial Intelligence
Lean Budgeting
The Agile Coach
Iterative Incremental Development
Tools
Legacy Enterprise
Jira admin
Engineering Practices
Systems Thinking
Value Streams
Coaching Agile Teams
Agile Techniques
Lean Risk Management
Scaled Agile Framework
Agile Development
Video
Nexus vs SAFe
An Appreciative Retrospective
Agile Project Management
Reading List
Agile Community
Agile and DevOps Journey
TDD
Atlassian
Lean Startup
Agile Exercises
Agile Outsourcing
Managing Risk on Agile Projects
AgileSparks
Agile Mindset
System Archetypes
Product Management
SAFe DevOps
Continuous Planning
Scrum With Kanban
Process Improvement
Development Value Streams
WIP
Achieve Business Agility
Agile Release Management
Entrepreneurial Operating System®
Agile Assembly Architecture
Release Train Engineer
Scrum Values
Agility
Lean and Agile Principles and Practices
POPM
Story Slicing
ATDD
Scrum Guide
Sprint Retrospectives
Webinar
Agile Risk Management
Certification
SAFe Release Planning
ATDD vs. BDD
Lean-Agile Software Development
Nexus and Kanban
Pomodoro Technique
Kanban Basics
Introduction to ATDD
Certified SAFe
ROI
Sprint Iteration
Legacy Code
Elastic Leadership
Principles of Lean-Agile Leadership
PI Objectives
NIT
SPC
Product Ownership
BDD
Kanban Game
System Integration Environments
The Kanban Method
predictability
Kaizen Workshop
Agile Testing Practices
Agile Delivery
RTE
Applying Agile Methodology
Quality Assurance
LeSS
Agile Product Ownership
GanttBan
LPM
Amdocs
ALM Tools
Lean Agile Leadership
Atlaassian
Lean and Agile Techniques
lean agile change management
Limiting Work in Progress
Program Increment
agileisrael
Agile Contracts Best Practices
Professional Scrum with Kanban
Agile Marketing
Agile Product Development
Daily Scrum
Scrum and XP
SAFe
Covid19
Scrum Master Role
System Team
Perfection Game
EOS®
Games and Exercises
Hybrid Work
Software Development Estimation
Agile in the Enterprise
What Is Kanban
Scrum Primer
Lean Agile Management
Lean Software Development
Professional Scrum Product Owner
Agile Games
Nexus
Scrum.org
AI
Implementation of Lean and Agile
Lean Agile Organization
Continuous Integration
Agile Israel Events
Lean Agile
PI Planning
Accelerate Value Delivery At Scale
Test Driven Development
Nexus Integration Team
Operational Value Stream
Agile Games and Exercises
Jira Cloud
Implementing SAFe
Continuous Delivery
Spotify
SA
Managing Projects
Effective Agile Retrospectives
Artificial Intelligence
Business Agility
Risk Management on Agile Projects
Portfolio for Jira
IT Operations
Large Scale Scrum
Planning
speed @ scale
Kanban Kickstart Example
QA
Slides
RTE Role
Introduction to Test Driven Development
ARTs
LAB
Sprint Planning
Scrum
Lean Agile Basics
Agile for Embedded Systems
Agile Project
Jira Plans
AgileSparks
Logo
Enable registration in settings - general

Contact Us

Request for additional information and prices

AgileSparks Newsletter

Subscribe to our newsletter, and stay updated on the latest Agile news and events

This website uses Cookies to provide a better experience
Shopping cart