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:

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