Distributed Teams: Managing Dependencies

My Learnings from a Distributed Scrum Project

27 November 2013


Managing dependencies in a distributed Scrum team can be a challenging task. Many times, one team is stuck and not working on planned user stories for the sprint because of dependencies involving other teams. If you don't plan it properly, you may end up losing productive hours of resources. I worked as a ScrumMaster in a distributed Scrum team consisting of seven different teams. It was a great learning experience. Each day our impediment log was filled, with dependencies needing to be resolved across multiple teams. This not only hampered the productivity of the entire team but also created a sense of disrespect among the "sub-teams." Situations that I faced and dealt with were behavioral, psychological, and political; they involved resource attrition; and above all they included missed release dates. This was a tough situation.

Another problem I faced was getting buy-in from all the teams when a new process was introduced. We often ended up in long debates about what Agile is and what Agile is not. Finally we agreed on a few points. These helped us a lot, and the situation improved drastically over three to four sprints.

1. Creation of an "Active Backlog": Our product backlog was maintained as EPICS à User stories à tasks à subtasks. We created another backlog and named it "Active Backlog." This Active Backlog was used for sprint planning and release planning. All EPICS and user stories were a part of the product backlog, but only those user stories for which dependencies were resolved, leaving them in a state in which developers could start working on them the next day, were moved to the Active Backlog. This helped us avoid situations in which one team was stuck because of a dependency on another team.

2. "Active Backlog" planning in a pseudo-sprint: While the core team of developers planned their sprints from the Active Backlog, we had a pseudo-sprint to move user story tasks from the Product Backlog to the Active Backlog. People who were involved in this activity were the "master" ScrumMaster, ScrumMasters, technical architects, and business analysts, with the very active involvement of the product owner. (A product owner may not be able to devote full support or time in this activity, so we had ScrumMasters playing the role of proxy product owners.)

3. Buffer user stories: This was something that we implemented and practiced even when we didn't have an Active Backlog in place. We found that buffer user stories help us overcome situations in which the team is stuck on a particular user story and we know that the dependency can't be resolved within that sprint. The team would pick up one of the buffer user stories planned for the sprint.

4. Sprint duration: This was one area where we experimented a lot. Initially we had different sprint lengths for different teams. One team got a two-week sprint and another had a three-week sprint. This was a nightmare for us, as there were no defined or fixed criteria. Then we shifted to a common three-week sprint for all teams involved. This helped us predict the future more effectively and the "upper layer" felt as though things were within their control. Later on we realized that we could do still better with this; based on the input each team requires and the output they are delivering, we have defined certain rules and sorted teams into two groups. Group 1 teams have a sprint length of one week, and Group 2 teams' sprint length is two weeks. It was a challenging experiment for us. We tried it for the next six weeks, and the results were up to our expectations.

 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 5 (1 ratings)

Comments

David Lowe, CSP,CSM, 11/28/2013 7:46:51 AM
Curious to see that you had the ScrumMasters playing the part of proxy PO; wouldn't the BAs have been a better proxy?

Do I assume that group 1 teams were those that delivered functionality that group 2 teams needed?
ABHISHEK KUMAR SRIVASTAVA, CSM, 11/29/2013 12:31:59 AM
I agree with you David, BAs can play a better proxy. In this scenario, BAs were spending more times with retailers and continuously traveling to various geographical locations.
Robert Kalweit, CSM, 12/4/2013 9:04:10 AM
Nice measures! When I read this I thought of the things we did and I'm always surprised (and relieved ;) how similar potential solutions are.

We did not necessarily "separate" the "Active Backlog" from the rest. But we made sure that for backlog items with dependencies to other teams the following things had happened:

* Product Owners of teams with dependencies align their sprints (shifting priorities in stories so that both teams work on interdependent stories in the same sprint). This way the developers/designers of both teams could self-organize.

* Explain priority-shift ("for the greater good") to both teams stakeholders.

* Align rough implementation design with architects (and in doubt CTO).

These 3 activities match pretty well with your "pseudo sprint", preparing the actual work by the scrum team.

Also the buffer user stories are a good thing. If something unexpected happens (woah!) the team has stories to work on, which they already know (instead of chaos or "nothing to do"-lethargy).
Gurpreet Singh, CSP,CSM, 5/12/2014 2:17:31 PM
nice article!

You must Login or Signup to comment.