Figure 1 shows some results from the 2016 Agility at Scale survey, summarizing agile team sizes. Roughly half of respondents indicated that the work on small teams of 10 people or less, although as you can see there were many responses of people indicating that they work on medium-sized teams and even some people indicating that they work on large agile teams. Having said that, there is no exact definition of what it means for a team to be small, medium, and large. For the sake of our discussion, small teams are between two and fifteen people, medium-sized teams twelve to fifty people, and large teams thirty-five people or above. Yes, these size definitions purposefully overlap because there is no consensus on this issue.
Figure 1. Agile team sizes.
As you would expect, the following team organization diagrams on this page depict the DAD roles (both primary and secondary). In this section we start with small agile team organization structures and work our way up to large team organization structures.
Small Agile Teams
We consider an agile team between two and fifteen people to be small. Figure 2 depicts a possible team structure for a small agile team. The Team Lead (an evolution of Scrum’s Scrum Master role) and the Architecture Owner are often, but not always, the same person on small teams. This can be challenging because good Team Leads need solid people and leadership skills whereas good Architecture Owners need solid technical skills and knowledge of the existing infrastructure and it can be hard to find all of these in a single person.
Figure 2. Organization structure of a small agile team (theoretical).
We often talk about the organization structure we see in Figure 2 because it’s convenient to present such a simple team structure. Figure 3, on the other hand, presents a more common and realistic structure. No team is an island, not even an agile team. Figure 3 shows that agile teams are often helped by what we call a “supporting cast”. For example, consider a team that is just about to set up an Oracle database. If the team doesn’t have Oracle expertise then this could be a slow and error prone effort. But, if they have access to an experienced Oracle DBA (a Technical Expert) they could hopefully get that person’s help for a few hours to help them to setup and configure Oracle effectively. They could even learn a few tips and tricks along the way. Similarly, a Product Owner might need to bring in a domain expert at times to explain complex requirements to a team. When teams face regulatory compliance issues (roughly one third of agile teams do), domain complexity, or technical complexity they may seek the help of one or more Independent Testers to help validate their work.
Figure 3. Organization structure of a small agile team (actual).
Medium Sized Teams
Although there is a lot of very good advice around keeping teams of less than ten people in size, we’ve actually experienced agile teams of 25-30 people that are a single team (not organized into a “team of teams”). These teams were organized in a similar manner to small agile teams, albeit with a few differences. First, the Team Lead and Architecture Owner are usually different people. Second, the teams often include one or more Specialists, such as a business analyst to support the product owner or one or more people focused specifically on testing.
Figure 4. Organization structure of a medium-sized agile team.
Figure 5 depicts a single disciplined agile team, working in a regulated environment, which at its peak was 26 people working in a single room. This team was a bit crowded because they had outgrown their room and more space wasn’t available to them. A common problem with teams of this size is that their daily standup meetings go too long. When 25 people answer the three questions prescribed by Scrum – What did you do yesterday? What will you do today? Are you experiencing any blockers? – then you shouldn’t be surprised that this can take upwards to an hour. This team held their daily coordination meeting standing up around their task board, a whiteboard with sticky notes on it, and only discussed potential blockers. The meeting rarely lasted more than ten minutes.
Figure 5. A medium-sized agile team.
Medium-Sized Team-of-Teams
Sometimes medium-sized teams, from twelve to fifty people, are often organized into a “team of teams” as you see in Figure 5. There are different strategies for organizing sub-teams, the most common being feature teams or component teams. Some component teams will include one or more specialists, for example at team building the security framework/component is likely to include a security specialist.
Figure 5. Organization structure of a medium-sized agile team organized as a team of teams.
Each subteam typically coordinates their own efforts via a daily coordination meeting, often called a daily standup or a daily Scrum meeting. The subteams will coordinate with each other by sending one person to a second daily stand up called a “Scrum of Scrums” (SoS). The purpose of the SoS is for the representatives of each sub-team to coordinate how any issues that have arisen (perhaps one sub-team has a dependency on another, perhaps one sub-team needs help from another, and so on) within the overall team. We’ve found that SoS starts to fall apart after four of five sub-teams, so a more sophisticated large-team coordination strategy is needed.
Large Teams/Programs
Large teams, perhaps 35 or more people, are often organized into the kind of structure as you see in Figure 6. This is an extension of Figure 5 to explicitly include a leadership team and in many cases someone(s) in the role of Integrator. This leadership team, with the potential support of an independent testing and integration team, provides the coordination structure required to support a large program. This structure is described in detail in the next section.
Figure 6. Organization structure of a large agile team/program (click to expand).
An interesting addition to the team structure of Figure 6 over that of Figure 5 is the Program Manager/Coordinator, a Specialist role. The Program Manager is responsible for overall coordination and management of the team. When you have teams of 50, 100, 200 people or more these efforts alone prove to be a formidable effort. They are also responsible for facilitating any issues between the various leadership sub-teams. For “smallish” programs, say 50 to 100, the Program Manager may also be a Team Lead on one of the sub-teams.