Distributed Teams: Managing Dependencies
My Learnings from a Distributed Scrum Project
27 November 2013
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.
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.
Current rating: 5 (1 ratings)