When scaling Scrum the most important aspect to manage is the dependencies. Team should be working towards a combined goal which will be produced as an integrated increment at the end of the Sprint. This is not easy, as almost any broken down work will result in dependencies between the multiple teams.
It is so important to manage this that Nexus actually creates a team (called the Nexus Integration Team) who’s primary responsibility is the managing of dependencies to create this incremented increment.
When managing dependencies there is a priority of severity.
- Another team in the same Sprint
- Same team in the same Sprint
- Another team in an earlier Sprint
- Same team in an earlier Sprint
Starting from the top (anohter team in the same Sprint) and working down these are the order in which a dependency will give you a really bad day. Obviously waiting for another team to complete something in the same sprint as you has far more potential to go wrong than your own team needing to complete something in this sprint to be able to work on something in the next.
Scrum.org has a great article on this which discusses how to track and manage dependencies. My personal advice:
- List out the dependencies for every piece of work, you can’t manage what you can’t identify
- Eliminate where possible (ideally in advance), manage where not
- Use a Nexus Daily Scrum (slightly different to the more commonly known Scrum of Scrums) to highlight cross team impedements and ensure they are resolved as soon as possible
- Use a visible board to track dependencies and impediments as well as work.
Hopefully this helps. Remember, each of your scrum teams should be producting a single integrated increment at the end of each sprint and aiming towards the same Product Goal. If that’s the case then identifying and resolving problems between the team will be much easier because everyone is working towards the same vision.
What are your experiences of scaling scrum? How did you manage dependencies between teams?
dotdotdev.com 