The last two years I have been working with a large team using SAFe to implement a very large system for one of our clients. There were nine development teams, plus support teams. I was one of the Scrum Masters on one of the teams. One of the most important things I learned from my time working on this program is how to manage dependencies between teams that are working on a release train. This becomes even more important when there are multiple release trains working on a portfolio of programs which have to be integrated into a single system.
In many ways this problem is the same kind of problem that we faced when doing waterfall projects and documenting the dependencies in a GANTT chart.
SAFe Program board showing features and dependencies
During the PI Planning effort in SAFe there is a deliberate effort to capture dependencies between teams and the features they are planning on implementing in the next program iteration. This process does a good job, during PI Planning of capturing dependencies, especially at the Feature to Feature level.
Product Owners, Business Analysts and Architects need to develop a common understanding about what will be in the next PI before PI planning starts. The effort needs to be focused on upcoming Epics and Features. The Epics and Features should be detailed enough for the development teams to break into User Stories during the Innovation and Planning (IP) Sprint.
IP Sprint Planning
During the IP Sprint the development teams need to come to a common understanding about the Epics and Features for the next PI so they can break the Features they will be working on into User Stories. The User Stories need to be detailed enough to a Title and the "As a user ..." statement with a sentence or two of description. Acceptance Criteria can wait for a later point in time.
The final set of tasks prior to PI Planning should be to enter the user stories into the system of record (Azure DevOps, Jira, etc.) and print out the user stories so they can be used during the PI Planning Meetings. Make sure to include the Title and ID on the printed user story and limit the size to a standard index card.
In addition to updating the Program Board, teams should identify specific user stories that have dependencies and talk with the team they are dependent on. Each team should exchange a sticky that identifies each teams user story and ID.
User Story Title
User Story ID #
User Story Title
User Story ID #
Each team is responsible for making sure implement the dependencies that were documented during the PI Planning Meetings in the system of record. See Implementing Dependency Management using Azure DevOps.
At the end of the first week of Sprint 1, the Release Train Engineer or Program Manager should review the results of the SAFe Program board vs. the information in the system of record. If there are discrepancies they should be resolved immediately.
Thank you and acknowledgement to
This blog came about after listen to a very old webinar called Collaboration at Scale: Managing Dependencies Across Large Teams which focused mainly on the reasons for dependencies.
Scaled Agile Inc. and their SAFe methodology which provide necessary tools and processes that many development organizations need in order to implement large programs using dozens to hundreds of teams.