In an earlier blog I talked about the importance of the team factor when scaling Scrum into a multi-team project. The method of choice is to build feature teams that are responsible for end-to-end delivery of a set of features requested by the product owner. One of the advantages of this approach is the reduced coordination overhead since there are less topics and issues to discuss in cross team meetings.

Now, how does this relate to the technique called Scrum of Scrums? Scrum of Scrums is essentially another daily Scrum meeting with a representative of each team attending. In the course of this meeting, participants are going through the usual Scrum routine. Scrum of Scrums is sometimes seen as a natural extension to Scrum and quite a few organizations are trying to perform it in their projects. However, Scrum of Scrums has some major drawbacks:
  1. It is unnecessary. The approach with feature teams reduces the need for coordination because the teams can proceed with their work much more independently. In a corporate world where meetings are abundant it is always a good idea to get rid of unnecessary meetings.
  2. It does not scale since once you have more than - let’s say - seven to nine Scrum teams the meeting grows too big. As an alternative parallel Scrums of Scrums could be set up which would then lead to the requirement for a Scrum of Scrums of Scrums (every day). Not a very attractive perspective.
  3. It is a technique that does not say anything about the role of the product owner in such a setup.

So, how could an alternative approach look like?

First of all, the approach with feature teams does not really require an institutional daily meeting for coordination among the Scrum teams. Thus, well-structured projects can do without the Scrum of Scrums technique.

If there exists a justified need for coordination between the teams, this can be organized along topics and areas of expertise. Such coordination meetings can be held in regular intervals (e.g. weekly) or on-demand, but they certainly do not occur daily.

What’s essential: in multi-team setups the product owner’s role gets even more important, because this is the role providing structure and coherence to the whole endeavor. For up to 10 teams it has proven feasible to operate with one product owner and with a single product backlog. The product owner might be supported by feature team members or domain specialists but he remains in full charge for setting priorities and assigning feature stories to the teams.

In line with the increased importance of the product owner role, sprint planning is also becoming more significant. For multi team setups, sprint planning should be split into two phases. The first phase covers the allocation of sprint feature stories to individual teams. It is here, where the foundation for the minimal possible cross-team coordination need is being laid. The second phase can then be regarded as a regular sprint planning within each team.

Along the lines of sprint planning the sprint retrospective can also be split into two phases. In the first phase the teams perform their normal team retrospective. In the second phase, team delegates are going through a joint retrospective with a focus on the overall project.

As mentioned, the approach with a single product owner works for up to 10 teams. For even larger projects, a structure of well-defined product areas each with their individual “area product owner” can be put into place. In such a setup, the product owner is still a single person responsible for the overall product but in addition he is the leader of the product owner team consisting of all area product owners.

Assuming, that these larger projects are also structured into feature teams, no daily coordination is needed neither. Thus, our alternative approach to Scrum of Scrums can be scaled up seamlessly.

References:
Henrik Kniberg, Anders Ivarsson: Scaling Agile @ Spotify
Craig Larman, Bas Vodde: Scaling Lean & Agile Development