Imagine that you have successfully performed your first Scrum projects with a single team of 5-7 members. The team has gone through the initial learning phase where it figured out what works and what doesn’t and now it feels very comfortable to approach new projects in this setup. However, a new challenge is on the horizon. Your boss has approached you with plans for a larger project requiring much personnel capacity than your original little Scrum team.

Now, how can a Scrum approach be scaled up without losing the benefits of agile development? In other words: how can a multi-team Scrum approach stay lean and low on coordination and queuing overhead?

When performing a Scrum project with more than one team, it is essential to get the team setup and structure right. Otherwise, you will experience a lot of overhead from coordinating between the teams regardless how clever the processes are defined. At the end of the day, agility will suffer from too many meetings. Intermediate results will be delivered too late or too early to other teams. Excessive queuing of such results between teams can be seen as a sort of waste and this is against one of the principles of lean and agile management.

Fundamentally, you have two options for structuring Scrum teams:
  1. Architecture or Technology Driven:
    Build teams that are working on the same architectural element e.g. on one tier. Similarly, teams could also be structured according to the technology being used, e.g. a team that works on integration with an ESB and another team developing everything that involves SQL databases.
  2. Feature or Business Function Driven:
    Build teams that work on a complete feature that delivers specific functionality to the client or the business. In this setup, the team has end-to-end responsibility for a feature and thus often covers multiple architectural tiers and technologies.
Option 1 fosters specialism and of course works better if the team members are already skilled in the required technical field. It also distributes business know-how over multiple teams. On the other hand, approach 2 is much more holistic because it requires the availability of a whole variety of technical skills. Know-how for specific business functionality is usually concentrated locally in one team.

There are pro arguments for both options, but overall from our and others experience the approach with feature teams is much more promising in most situations because of the following main characteristics:
  • It reduces waiting queues because each team can work on its end-to-end features quite independently. In the same way, it makes responsibilities much clearer. Blaming other teams for not being able to deliver is not really an option.
  • Coordination overhead is reduced in comparison to the situations where each tier is developed by a different team. In technical areas, cross-team coordination is still required but can be optimized by delegating it to different team members per topic area.
  • Versatility of staff is fostered, which benefits both the individual and the employer.
  • It is oriented towards learning and thus matches with the principles of lean management.
  • The team is at the center of it all, it is cross-functional and executes all the tasks needed to deliver a feature to the business.
According to Bruce Tuckman, teams are going through distinct phases once they got put together: (1) forming, (2) storming, (3) norming, and (4) performing. This is even truer for Scrum teams since they decide themselves on many specifics of their internal collaboration. It takes them time to get up to speed because they need to get to know each other and to tailor their ways of working according to the team’s composition. Typical Scrum projects may last somewhere between 6 and 18 months. Now, if you imagine that at least a few sprints are being used for getting the team up to speed then it would be a waste to dissolve the team after a single project and reconstitute new teams with the available staff. Thus, the team should be kept together over the span of multiple projects.

Working with feature teams very much supports team longevity since after finishing one project, the whole team can just be assigned to another project. Thanks to this coarse grained level of capacity allocation, the whole staffing process is scaling well and teams are enabled to focus on tasks which belong together.

Thus, even when scaling Scrum, the team stays at the center of it all. Teams should be structured as feature teams that stay together for multiple projects. This way, the team can become the real star.

Of course there is quite a list of additional issues when scaling Scrum to multiple teams. One of them is the definition of the overall organization, the roles, and the periodic meetings. This is a topic for another Acrea blog entry. So stay tuned!

References:
Craig Larman, Bas Vodde: Scaling Lean & Agile Development
Bruce Tuckman: Stages of Group Development