Scaling and dependencies are inevitable and pose an interesting challenge for a Release Train Engineer on a train with 15 teams. During multiple PI’s teams learned to improve in this area but I still felt we could do better. In a small analyses I investigated the data and looked for best practices from Scaled Agile Framework and other scaling frameworks (Disciplined Agile Delivery, Large Scale Scrum (LeSS), NEXUS and Spotify). This article is a summary of the findings.
Definition
A dependency is defined when progress of one action relies upon the timely output of a previous action, or the presence of some specific thing. 3 types of dependencies are found in researching agile software project dependencies(1):
- Knowledge dependencies surface when specific information is required for a project to progress.
- Task dependencies surface when a task needs to be completed for a project to progress.
- Resource dependencies surface when a person, place, thing is required for a project to progress.
Identifying and defining the type of dependency can help in managing dependencies or finding mitigations (Best Practice 1).
Impact
The impact of dependencies can be significant. The insights provided by Troy Magennis on reduced freedom in ordering and lead time was an eye opener. I his presentation(2) he showed the number of valid options reduce significantly when the number of dependencies increase.
Next the chance of a dependency actually being delivered also diminishes fast with the number of dependency increasing. Other impacts can be:
- Causes friction between teams who have different priorities and rewards
- Dependencies cause overhead
- Dependencies may ultimately increase your cost
- Dependencies can mess up your velocity
- Dependencies can mess up your plan
- Dependencies can cause rework
- Dependencies can make you want to quit software development
Some basic best practices for managing dependencies
The most import rule is minimise or remove dependencies. The INVEST rule (Best Practice 2) clearly states features or user stories should be independent for this reason. Next dependencies can be removed (Best Practice 3) by simply handing over the user story requiring work from another team to that team. The next option is to reprioritise one or both of the features (Best Practice 4) or mock out (Best Practice 5) the missing functionality until it is available. The last option is to rework the requirements (Best Practice 6) to remove the dependency.
SAFe and dependencies
In Scaled Agile Framework dependencies are managed in the Program Increment Event. Teams build a dependency board to visualise dependencies. This normally a low tech solution based on brown paper, sticky notes and yarn.
Based on experience from another ART we introduced the digital dependency board (see top image). This is an excel sheet querying directly on Rally. Teams store their dependencies in Rally and reach out to teams to manage them. This was a significant improvement. The colouring of the lines show if the dependency is correct, in progress or done. This enables the Release Train Engineer to track dependencies during the PI.
Based on analysing the data on the dependencies it showed 30 % of the dependencies are identified before the PI Planing Event. Around 60 % of the dependencies were identified on last day during 1,5 hours prior to the final plan review. This means teams typically rush to each other to manage dependencies at the end of the event. Clearly room for improvement. Try to identify dependencies during feature elaboration prior to the PI Planning Event (Best Practice 7) is an improvement.
Spotify and dependencies
Spotify has an interesting approach(3). Squads sometimes need to work together to build something truly awesome. Nevertheless, the goal is to have squads be as autonomous as possible, especially minimizing dependencies that are blocking or slowing a squad down. The slowing down or blocking dependencies will analysed and often leads to reprioritization, reorganization, architectural changes or technical solutions.
The Spotify dependency analyses could be used in the Inspect & Adapt workshop to find dependencies slowing or blocking the Agile Release Train (Best Practice 8)
LeSS and NEXUS on dependencies
LeSS and NEXUS both scale the normal scrum ceremonies into multi team events with participation of a delegation of the teams. The cadens of these events is the same as the scrum events. So during every sprint there is a multi team event prior or after the team event. SAFe has created distinct multi team events on Agile Release Train level such as the PI Planning Event, Solution demo and Inspect & Adapt workshop. The cadens has lower frequency. The events are organised once during an Program Increment (10 to 12 weeks). The lower frequency could be the Achilles heal on dependency management for SAFe.
NEXUS states “Scaling and dependencies are inevitable and multi team refinement is therefore a required ceremony” (4). This corresponds with the findings on identifying dependencies in Best Practice 7. Multi team refinement during every sprint with the relevant teams can be could solution to help. LeSS uses a design workshop (Best Practice 9) with a time box of 1 hour to manage dependencies. I also like the roles; observers and travellers (Best Practice 10). Team members that join daily scrums of depending teams or help exploit and break bottlenecks and create skill.
Communicate in code and just talk (5)
LeSS groups adopt continuous integration, which means that everyone has all their code checked in to the central repository mainline (branches are an unnecessary complication that should be avoided). Everyone in the product teams synchronizes with the repository several times a day and will get all the changes that other people have made (Best Practice 11).
So, when you update, spend two minutes going over the changes that were made by others and see if they relate to what you are working on now. If so, feel free to get up and “just talk” in order to synchronize your work with the others! In discussing scaling frameworks we allmost forget the simplest best practice (Best Practice 12).
Conclusion
Based on the data and Agile Scaling Frameworks 12 best practices have been found to manage dependencies. Next a comparison between SAFe, Spotify, LeSS and NEXUS shows the lower frequency of multi team events in SAFe could be the Achilles heal on dependency management. In future post I will elaborate on ownership, visualisation and cross team and external dependencies. Feel free to comment.
Literature
(1) A Taxonomy of Dependencies in Agile Software Development, Diane E. Strode Sid L. Huff.
(2) Entangled: Solving the Hairy Problem of Team Dependencies, Troy Magennis Agile 2015.
(3) Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds, Henrik Kniberg & Anders Ivarsson.
(4) Cross-Team Refinement in Nexus whitepaper, Rob Maher, Patricia Kong.
(5) LeSS Coordination and integration, LeSS website.
