Scaling of Scrum to Large Distributed Teams using Scrum of Scrums

When working with a large customer, it is a very common practice to have multiple teams working out of different geographical locations and different time zones.
Agile practices encourage in-person interactions for better collaboration and faster turnaround, which helps in faster time to market. So in an account with distributed and large teams, in-person collaboration proves out to be difficult.

Challenges faced in a Distributed Agile Development Model:

• Today’s world stresses more on the globalization. There could be teams located at different floors of the same building, or different buildings, or different cities or even different countries across geographies and time zones.
• A scrum team may even contain team members from different vendors and/or different organizations.Additionally, there could be timezone differences, communication barriers, co-ordination issues, etc. Since the sub-teams are working in parallel, co-ordination between different teams become important.
• In such scenarios, factors like culture, project/organization structure, project type, etc also impact the way the agile software development practices are being followed.

This is where the concept of Scrum of Scrums will help. This can solve distributed team roadblocks, future dependencies, commitments to other team members, issues with integration, and other points that impact other teams.

What is Scrum of Scrums?

Scrum of Scrums is similar to the Daily Stand Up meeting that takes place in large projects, to co-ordinate the work of the multiple sub-teams. The main purpose of this is to communicate progress and discuss on any impediments faced across the teams. The scrum master at the program level facilitates this co-ordination and ensures the overall progress of the program.

• A Scrum Master at the program level will be the one who would be chairing the Scrum of Scrums meeting.
• You may divide the large program which has multiple applications/modules, into groups of Agile Scrum sub-teams. Each sub-team is, in itself, a cross-functional team consisting of developers, testers, business analysts, and so on, representing a particular application/module.
• Typically, teams from the same timezone can be part of a single scrum team. If a customer is also part of the scrum team, then there can be separate scrum teams representing the vendor and the customer separately, depending on the team’s size, and the project/organization culture.
• In the case of onsite-offshore, whether to divide the teams into separate scrum teams would primarily depend on the individual project needs and culture.
• Any designated “representative” from these individual sub-teams will need to participate in the Scrum of scrums meeting, along with the representatives from the other sub-teams.
• The representatives can be more than one person from the sub-team which can include Scrum Master along with a Business Analyst and/or a Senior Developer/Tester. These representatives will act as the Product Owner for their respective sub-team.
• This meeting will focus more on the challenges faced in the interfaces between the other applications/modules; coming up with the Interface agreement, responsibility sharing, etc.
• The Scrum of Scrums meetings are similar to the daily Scrum meeting, but need not necessarily happen every day. In some cases, having a Scrum of Scrums meeting two or three times a week is sufficient.

Illustration of how a scrum of scrums works:Case Study:

I have an experience of working in such a distributed team for almost 4 years with a prestigious banking client. We practiced scrum of scrums methodology. It was a banking program which included both the credit cards and debit cards processing for different geographical regions of the world. This particular program aimed at simplifying, consolidating, and standardizing the information technology systems globally. We had 10 to 11 small scrum teams of different applications. Each team had about 8 to 9 team members, working out of different locations like Singapore, India, Philippines and US. And each team was of different vendors to the customer. So, there were a lot of dependencies within the teams and co-ordination proved to be a difficult task. The projects were following the agile scrum methodology, which means having a single scrum master for 80 to 90 people didn’t sound correct. Also, each sub-team had their own technology and list of user stories to be accomplished in a given sprint. So, the idea of scrum of scrums popped out and proved out to very successful.

Each team had a scrum master, business analyst and the developers/testers. As shown in the below table, each team will typically send 2 representatives to the Scrum of scrums meeting. It would be the Scrum Master and another team member, depending on the phase of the project. The Business Analyst will act as the Product Owner for their respective teams.With the above approach, the interfacing issues were resolved easily and also the co-ordination was lot easier. Each sub-team was of different vendors, so the culture and work styles were different. With scrum of scrums, the program level scrum master was easily able to keep a track on the progress and only in case of dependencies, the teams had to interact with each other. This also ensured that the teams enjoyed the freedom of their culture.