Managing Dependencies Between Teams

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.

There’s nothing more frustraiting than needing to get to work but being blocked by another team. Photo by Burst on Pexels.com

When managing dependencies there is a priority of severity.

  1. Another team in the same Sprint
  2. Same team in the same Sprint
  3. Another team in an earlier Sprint
  4. 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?

How to Manage Product Goals with Multiple Teams?

As I mentioned recently I’ve been studying scaled scrum and recently passed the scrum.org SPS exam. One of the key aspects to this is how to manage work between teams so it’s a topic I want to discuss in this post.

The Nexus Guide provides a really good introduction to scaling scrum (other frameworks are available). There are two aspectcs which I see as key. These are for every team to focus on a single Product Goal and to minimise dependencies between teams. I’m going to focus onthe former.

In scrum we build incrementally towards a Product Goal, we review our progress in the Sprint Review and share progress with stakeholders then discuss what we should do next. It’s this level of transparency which makes scrum so powerful, it minimises risk and ensures we’re building the right thing.

However, when you have multiple teams all working on a product things can get complicated, you often see different teams with different project delivery dates and things get very very messy.

How should a business share work between teams in a scrum environment? Photo by Startup Stock Photos on Pexels.com

Generally a product should have a single backlog and a single active product goal. This makes sense. After all a product should have one list of improvements and should be moving towards a single known state, however it’s surprising how many organisations have a backlog per team, rather than per product.

Next, all teams should work together to create an integrated increment of all their work each sprint. This may sound controversial or even impossible but let me explain.

If your two scrum teams are creating increments each sprint they can do this in isolation (in which case they’re creating to diverging versions of the product) or they can integrate into the same master version of the product as they go. The former is no better than the vast feature branches we all remember with nightmares. Instead the Definition of Done should including integrating their increments with all other teams before marking work as completed.

So why can’t two teams focus on two different Product Goals? The question is why should they? A Product Goal represents a future vision of the product which the team is working to create. Surely we can’t have two visions?

Instead we should have a roadmap of upcoming goals. What we expect the product to look like after phase 1, phase 2, phase 3 or whatever. Scrum teams don’t pursue two Product Goals at the same time in regular scrum so why would they have any more success with multiple teams? To ensure the best chance of delivering effectively all teams on the product should focus on turning the active Product Goal into reality before moving onto the next. They can do this by breaking down the work in to individual pieces of work with the fewest dependencies between them, delivering them and integrating before the end of each sprint.

Fewest dependencies… that seems like a future post!

Seriously though, Scrum.org has some great articles on this stuff. If you’ve not already I highly recommend reading The Nexus Guide if you are trying to use scrum to deliver a product with any more than one team.