Managing in-sprint dependencies across multiple scrum teams on a scaled agile project

We recently started a sprint with user stories that were dependent on work being done by other scrum teams on a scaled agile project.

The Problem

The Tech Lead and Product Owner came to me with the initial assessment of the situation. The following nine items of work all needed to be coordinated, otherwise we'd face environment problems that would block progress on other tickets. 

Specifically, Team Avocado and Team Bobcat needed to complete items in their sprint, before Teams Candyfloss, Dalmatian, and Elephant could complete items in their sprints. If teams Candyfloss, Dalmatian and Elephant didn't complete their work, then we'd be left with a situation where environments across the project would be broken and potentially inoperable. 

Furthermore, an initial assessment by our Tech Lead determined that the items sitting with Avocado were "breaking changes" (represented by sticks of dynamite in the illustration above).  As soon as any one of these pieces of work was developed and released to the Avocado test environments, it would break any other environments on the project that were pointing at it. 

For example, Team Dalmatian’s feature branch environments, as well as downstream environments (int, test, uat), were all “looking” at the Avocado test environment. If they didn’t find data in specific format, they would break. And this is precisely what would happen as soon as the breaking changes were introduced to the Team Avocado test environment: environments wouldn't find the data they were looking for and cause the system to break. 

This would make it difficult for Teams Candyfloss, Dalmatian and Elephant to complete testing of any new features - it would be so difficult to figure out whether a bug was caused by the missing data, or because of a genuine error with the new feature that had been developed.

To complicate matters, Team Bobcat had one item in their sprint, which we also identified this as a breaking change. Furthermore, teams Candyfloss, Dalmatian and Elephant all had items in their sprints that were not breaking changes, but couldn't be tested until the Avocado and Bobcat items had been completed.

Our Product Owner reported that all teams were lined up to do the piece of work in the same sprint, a small miracle in itself given recent resource issues.

So we decided to go with it. But we'd need to manage the in-sprint dependencies, or risk breaking environments and tripping each other up. We all needed to be on the same page. 

Approach

I began by compiling a list of all the pieces of work, and talking this through with our Product Owner and Tech Lead.

We then had a first pass at understanding the which items were dependent on which, and the sequencing of when they could be released to Test and subsequently through the UAT (our production-like environment). 

ID	Team	Item	Dependency	Comments
A1	Avocado	***	***	***

We initially decided that for teams Candyfloss, Dalmatian and Elephant to have a chance at completing their work in the sprint, we needed Teams Avocado and Bobcat to have all their work ready to push to test by the middle of the sprint.  

 

After getting our thoughts down on paper, it was time to talk through the plan with the other teams involved. We requested that each team send along their Product Owner and a nominated lead developer from their team to attend a kick-off meeting.

 

In the meeting, we gave a brief overview of the pieces of dependent work and our understanding that environments would break as soon as Team Avocado pushed their changes to test – hence the need for the active management

 

We then went through each item one by one to sense check our understanding of the dependencies. 

At this point, Team Avocado pointed out that it would not be possible to get their three items ready to push to test by the middle of the sprint. 

The lead developer from Dalmatian then came in with a helpful suggestion. If everyone pointed their environments at the Avocado Dev environment, they would be able to test the items before Team Avocado pushed their items to their Test Environment. For example, Team Dalmatian  would be able to test items D1, D2, D3 before Team Avocado pushed A1, A2, and A3 to the Avocado test environment. This would allow the teams to identify any bugs earlier in the sprint, rather than having to wait for Avocado to be in position to move all three of their items into their test environment. 

 

The lead developer from Bobcat casually remarked on several occasions that he didn't think the item in his sprint was a breaking change. But he was unable to convince our Tech Lead or Lead Dev from Dalmation on this point.

We also clarified with Candyfloss that their item would actually be completed as part of Elephant’s work.

 

We then went talked through the release plan - essentially the sequence of events that was needed to complete the sprint without things going wrong. This involved every team letting all the other teams know before they were going to do something, and giving the other teams time to respond. Everyone on the same page right? What could go wrong?

The Outcome

 

The next day Bobcat released their change immediately to test without any comms, and totally against what we’d agreed in the plan.

 

I contacted our Tech Lead to let him know. He couldn’t ascertain immediately whether the change had been made. However, it didn’t look like it’d broken environments. It turned out that the lead dev from Bobcat was right, it wasn't a breaking change after all. Still, it could have caused havoc and went completely against the plan everyone had agreed to. 

 

A few days into the sprint, and we get an email from the Product Owner of Avocado, saying that one of the items was ready to be pushed to test, and that they were planning to push the item to test later that day. Again, not part of the plan, but at least this time it had been communicated with time for us to respond. 

 

I replied, saying that it sounded like fantastic progress, but we needed all pieces to be ready to be pushed to save the disruption of broken environments.

 

Mid-sprint it transpires Dalmatian never got the subscription for the Avocado dev environment. A few emails later, and we have it and can start testing.

All for the good. But at this point, our lead developer says actually – it’s only one of the items in the Avocado backlog that’s a breaking change after all. Avocado don’t need to wait to push all three items to test at once. In fact, it would be better if they didn’t wait – as it would help our teams complete their items in time for the end of the sprint.

I consult the Tech Lead to clarify things. It does, indeed, seem that we’re now pretty confident that we only really have a dependency on one ticket. 

I go back to Avocado, and let them know and apologise for the confusion. They seem gracious about it.

In end, the piece of work was steered through without us tripping each other up too much, and with minimal disruption to downstream environments and with the teams involved kept in the loop.

A lot of cross team coordination effort later, and a job well done - but there must be a better / simpler way to do it?