Scrum Team Structures: Chapter 12

Scrum teams are essential assets of a Scrum organization. How Scrum teams are structured and relate to one another can significantly affect an organization’s success with Scrum. In this chapter I discuss different ways to structure Scrum teams. I begin by discussing the distinction between a feature team and a component team. I then focus on the issue of coordinating multiple, collaborating Scrum teams.

Scrum Team Structures Overview

If you have just one small project, you don't need to worry much about Scrum team structures. Just create one cross-functional team, using the characteristics I described in the previous chapter, “Scrum Teams,” and make sure to properly fill the ScrumMaster and product owner roles.

Scrum team structures become much more important when you need to coordinate the work of multiple Scrum teams whose combined effort is required to deliver increasingly greater business value. You want to structure your teams so that they are high performing and well coordinated. The first question you might ask is whether you should create feature teams or component teams.

Feature Teams versus Component Teams

A feature team is a cross-functional and cross-component team that can pull end-customer features from the product backlog and complete them. A component team, on the other hand, focuses on the development of a component or subsystem that can be used to create only one part of an end-customer feature. Component teams are sometimes also called asset teams or subsystem teams.

For a more complete understanding of feature teams versus component teams, read my blog post, Distinguishing Between Feature and Component Teams.

Scrum favors feature teams. Unfortunately, many organizations prefer component teams, often because they believe that a team of trusted experts will make safer and more effective changes to the parts of the code that they own. These organizations recognize that cross-functional teams are a better choice for minimizing dependencies and handoffs, but they are more concerned about the risk of chaotic development and maintenance of reusable components with large amounts of technical debt.

One solution is to create well-formed feature teams that, over time, share code ownership and collectively become trusted custodians of the code. This transitory approach to a multi-feature-team model with full shared code ownership is shown in the image below.

“Model for transitioning from mostly component teams to mostly feature teams”

In the picture, a single feature team exists that can pull an end-customer-valuable feature off of the product backlog and do the work necessary to complete it. Notice too, that existing component teams also still exist. What makes this work well is that a member of each component team is assigned to the feature team. This dual-function person shares the knowledge of the component team with the feature team, slowly building shared code ownership. The dual-function person also collects changes that the feature teams need to make within component areas and discusses these changes with their colleagues on the component teams.

There are some nuances to doing this at scale, which is where multi-team coordination and release trains come in. I also recommend reading my blog post, Restructuring Teams to do Agile at Scale: The Fallacy of Magical Thinking.

Multiple-Team Coordination / Scaling Scrum

When scaling Scrum, you don't want to have increasingly larger development teams. You want to have multiple right-sized Scrum teams. The trick is how to coordinate among those teams. Two agile scaling techniques I find particularly useful are the scrum of scrums and the release train.

Scrum of Scrums

A scrum of scrums is essentially a daily scrum involving representative members of multiple Scrum teams. The difference is that the scrum of scrums is not held every day but instead one or more times per week, as needed. The representative from each Scrum team is chosen based on which member can best speak to the inter-team dependency issues. Some teams send both a development team member and its Scrum Master to the scrum of scrums. That's fine as long as the list of attendees at the scrum of scrums doesn't grow too large. It might even make sense to appoint a Scrum Master for the scrum of scrums.

Participants at the scrum of scrums answer similar questions to the ones answered at the daily scrum:

• What has my team done since we last met that could affect other teams?
• What will my team do before we meet again that could affect other teams?
• What problems are my team having that it could use help from other teams to resolve?

The scrum of scrums need not be timeboxed to no more than 15 minutes. Problem solving is permitted during the scrum of scrums, so the meeting can go longer.

In theory, the scrum of scrums can be scaled to multiple levels, with multiple scrums of scrum of scrums (more easily called program-level scrums) and the like. When scaling beyond a scrum of scrums, some organizations find the release train approach helpful.

Agile Release Train

An agile release train is an approach to aligning the vision, planning, and interdependencies of many teams by providing cross-team synchronization based on a common cadence. A release train focuses on fast, flexible flow at the level of a larger product.

The idea is that the features need to “leave the station” on a published schedule. All of the teams participating in the development of the product need to get their “cargo” onto the train at the appointed time. The release train always departs on time and waits for no one. Likewise, if a team misses the train, it need not fret because there will always be another train departing at a known time in the future.

The release train image above shows nine teams clustered into three feature areas. After an initial whole-train release planning meeting, each team within a feature area performs its own sprint, drawing work from its associated feature-area backlog. Using a technique like scrum of scrums, all other teams within a feature area coordinate and integrate their work each sprint.

As often as is practical, there should be system-wide integration and testing across the feature areas. The durations of all sprints for teams participating in the release train are identical, and all sprints are aligned. The result is that sprints of every team start and end on the same dates. After a fixed number of sprints, a potentially shippable increment—PSI— is available. At each PSI, the organization can choose to deploy a PSI to its customers or to instead confirm that the work performed within the individual feature areas has been integrated and tested across the feature areas, and to solicit an internal review.

Agile scaling practices are discussed further in Chapter 16, Agile Portfolio Planning and Chapter 18, Agile Release Planning.

Scrum Team Structures Summary

This chapter was concerned with Scrum team structures. The next chapter will discuss the role of managers in Scrum.

You might find it helpful to look at the slide ins Scrum feature teams versus component teams presentation from Ken Rubin. 

And if you want more in-person help with your Scrum team strutures, consider agile coaching or whole-team Scrum training from Ken Rubin.