Large Agile Teams

This article describes strategies for organizing agile teams of various sizes, from small agile teams to very large agile programs. In the case of large agile teams, also called programs, this article goes into further detail and describes how to support them.


Organizing Agile Teams

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.

Agile team size

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).

Small Agile Team Organization

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).

Team - Small 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.

Medium Agile Team Organization

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 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.

Medium-Sized Agile Team Organization

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).

Large Agile Team Structure

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.

Supporting Large Agile Teams

As you saw in Figure 6 above, large agile teams that are organized into a “team of teams” have several supporting structures. These structures are:

The Product Coordination Team

The purpose of the Product Coordination Team is to ensure that team management issues, such as budgeting, reporting, scheduling, and people management issues are addressed in a timely and proactive manner. This team is sometimes called a Team Lead team, a Program/Project/Portfolio Management Office/Team, or simply a Management team. Responsibilities of these team may include negotiating dependencies between sub-teams, coordinating the release schedule, and initiating or closing sub-teams (these sorts of activities are captured in the Program Management process blade). It may also include ensuring that people are successfully on boarded (added) to sub-teams, off boarded (transferred) from sub-teams, and provided opportunities to grow/learn (these sorts of activities are captured by DAD’s People Management process blade). And of course the Product Delivery team will monitor and help facilitate solutions to any problems that arise between people on different sub-teams.

Figure 7 depicts a common structure for a Product Delivery team. It shows that the Team Lead from each delivery (sub-)team is a member of the Product Delivery team. It also indicates that this team is led by someone in the role of Program Manager, although this role could also be Portfolio Manager or Product Delivery Lead/Manager depending on the scope of the team. As with all agile teams the Product Delivery team will self organize. We’ve seen several strategies implemented, the Scrum-of-Scrums (SoS) strategy described earlier being a common one. However, we’ve also seen some Product Delivery teams choose to meet on a weekly basis for an hour to discuss common issues, supported by ad-hoc meetings between Team Leads to address specific issues between their teams as needed. And of course your Product Delivery team may choose to evolve their strategy as they learn and as their situation changes.

Figure 7. Organization structure of an agile product-delivery team.

Agile Product Delivery Team

The Product Management Team

The purpose of the Product Management team, sometimes called a Product Owner team or Product Ownership team, is to manage requirements across sub-teams. This includes developing and evolving a vision for the program or portfolio, prioritizing work within the overall program, determining which sub-team will implement a given requirement, and managing dependencies between requirements being implemented by different teams. These activities are described in greater detail by the Product Management process blade (TBD). For now, please read The Product Owner Team.

Figure 8, which is similar to Figure 7, describes an organization strategy for an agile product management team. It shows that the Product Owner from each delivery team is a member of the Product Management team. This team is lead by someone in the role of Chief Product Owner, sometimes called a Product Manager or Director of Product Management. In smallish Product Management teams the Chief Product Owner is often a Product Owner on one or more delivery teams as well. The Product Management team will self organize, determining how they will work together. We’ve seen Product Management teams meet for thirty to sixty minutes each day to coordinate their work and we’ve seen other teams meet for a few hours weekly to do so. It’s also common for a Product Management team to meet on a regular basis with key stakeholders so as to identify new incoming work and to negotiate the priorities for the work in an open manner. We’ve seen this occur on a weekly, bi-weekly or monthly cadence in various organizations.

Figure 8. Organization structure of the product owner/management team within a large agile program.

Team - Product Owner Team

What Figure 8 does not show is that many Product Management teams include business analysts (what DAD would consider a Specialist role) and Domain Experts. Agile business analysts will support Product Owners that find themselves working at scale, often assisting them when stakeholders are geographically distributed, in situations where the problem domain is complex and requires deep analysis, or in regulatory situations requiring greater levels of requirements documentation. Domain experts are often called in on an as-needed basis to help Product Owners to work through complex domain issues.

The Architecture Team

The purpose of the Architecture Team is to formulate an architectural strategy at the program or enterprise levels; to communicate that strategy to their customers (both IT and business stakeholders); to evolve the strategy over time based on their learnings working with development teams and other stakeholders, and to resolve any architecture-level technical issues (such as evolving interfaces or changing underlying technical infrastructure) that arise over time. This team is also sometimes called an Architecture Owner team, Agile Architecture team, or even Enterprise Architecture team. A more detailed description of the activities this team may choose to perform as captured by DAD’s Enterprise Architecture process blade.

Figure 9, similar to Figures 7 and 8 before, show how Architecture teams can be organized. You see that the team is led by a Chief Architecture Owner, sometimes called a Chief Architect or Chief Enterprise Architect. The Architecture Owners from each delivery team should be members of the Architecture Team, so that they can share their learnings with others, get help from their colleagues as needed, and negotiate changes to architectural aspects of the solutions that they are working on as their overall strategy evolves. The Chief Architecture Owner will often be an Architecture Owner on one or more delivery teams. As with the other leadership teams, the Architecture team will self organize. We’ve seen teams that meet once a week for an hour, some teams that meet bi-weekly, and some teams that meet monthly. It is common for Architecture Owners to request an ad-hoc meeting of all or a subset of the Architecture Team to discuss an architecture issue that has become critical for them.

Figure 9. Organization structure of an agile architecture team.

Agile Architecture Team

Figure 9 represents an architecture team for a program, or large agile team. In very large organizations we’ve seen the overall architecture team organized into a hierarchy. In one large financial institution, effectively a federation of financial companies around the world, there was an architecture team at the overall corporate level, one for each major division, and where needed one for each major program.

The Independent Test/Integration Team

As we mentioned earlier, the two primary reasons why agile teams become large are that they are addressing great domain complexity, great technical complexity, or both. One implication of this is that their testing efforts will reflect this complexity, the more complex something is the harder it is to test, and to deal with that complexity the team may decide to adopt the practice of parallel independent testing. As you can see in Figure 10, the basic idea is that each development sub-team will still test to the best of their ability but that more complicated efforts, such as end-to-end integration testing, be performed by a testing sub-team. This testing sub-team will support all of the development sub teams, pulling in the working builds from each development sub team, integrating those builds into a single pre-production test sandbox, and then they try to find potential defects which then get reported back to the appropriate development sub-teams. These potential defects are treated like new requirements by the development sub teams in that they are prioritized, estimated, and addressed appropriately. Although Figure 10 shows that one build/release is being provided by each sub-team each iteration, it is common for teams to provide several builds each iteration – this cadence is something that the development sub-teams would need to negotiate with the Independent Test/Integration Team.

Figure 10. Parallel independent testing.


Figure 11 depicts a potential team structure for an Independent Test/Integration Team (ITIT). Note that this sort of team is sometimes called an Integration Team (as in SAFe), a Quality Assurance Team (a more traditional name), or simply a Test team. As you see in Figure 11 the ITIT typically has a Team Lead, one or more Independent Testers, and zero or more Integrators. The Team Lead is typically a senior tester who has both testing and leadership/management responsibilities. The Independent Testers often focus on the more skillful forms of testing, including pre-production integration testing, exploratory testing (something that the development sub teams can and should be doing as well), security testing (this can require expensive testing tools and security expertise), and usability testing to name a few. Someone in the integrator role will do the work necessary to integrate the various builds from each sub team and in effect will perform installation testing while doing so. We’ve seen small ITITs of one person who performed both testing and integration (remember, Team Lead, Independent Tester, and Integrator are roles, not positions or people). We’ve also seen larger ITITs with five or six people (remember, the vast majority of the testing is still being done within the development sub-teams).

Figure 11. Organization structure of an independent testing and integration team.

Team - Independent Test

Independent testing and integration isn’t reserved to large teams. We’ve seen small and medium-sized teams in the regulatory space that are supported by ITITs. This occurs because some regulations, particularly those in the life/health-critical space, require independent testing. This doesn’t mean that all testing must be independent, a common misconception within waterfall teams, but it does mean that some testing must be independent. The approach to independent testing that we summarize here is one way to push this sort of testing earlier in the lifecycle, thereby reducing the average cost of fixing potential defects.

Putting it all Together

Figure 12 depicts the same large-team structure of Figure 6 from the point of view of the various sub-teams. As you saw in Figures 7 through 9 people on each of the N delivery teams in the roles of team lead, product owner, and architecture owner will also be members of the Product Delivery, Product Management, and Architecture Teams respectively. Each of these teams will self organize and coordinate their activities as they feel appropriate. The delivery/development sub-teams are also supported by the Independent Test/Integration Team that is performing the more complex forms of testing that would otherwise be left to the end of the lifecycle.

Figure 12. High-level organization structure of large team.

Team - Large High-Level 

Now that we understand how to organize the coordination and leadership structure around delivery/development sub-teams it is appropriate to discuss strategies for organizing the sub-teams themselves.

How Do We Organize a Large Agile Team?

There are four basic strategies, compared in Table 1, for organizing large or geographically distributed sub-teams:

  1. Component teams. With this approach each sub-team is responsible for one or more subsystems or modules, something that can be difficult if some of your team works alone from home, to reduce the amount of information sharing and collaboration required between disparate teams. Because component teams are effectively organized around your architecture you will need to invest sufficient time up front to identify that architecture.
  2. Feature teams. A feature team is responsible for implementing a functional requirement, such as a user story or use case, from end-to-end. This is often referred to as implementing a vertical slice of the solution. Sometimes a given feature team will focus on the requirements for a single line of business (LoB), such as brokerage or life insurance within a financial institution, enabling them to gain expertise in that LoB. Other times a feature team will take on requirements specific to a given application or system within your organization.
  3. Functional teams. Some large teams will be organized by development function – there is an architecture team, a development team, a testing team, a deployment team, and so on. Each team focuses on their specialized function and hands off their work to other functional teams.
  4. Internal open source teams. Sometimes a component or subsystem will be developed via an open source method, even though all of the work is private to your organization. Developers from other teams voluntarily work on the component to evolve it over time. When Scott was at IBM he saw this strategy work in practice for several important components reused within several IBM products. For some detailed thoughts on strategy, read Reuse Through Internal Open Source.

Table 1. Comparing the team organization approaches.

Team Approach Advantages Disadvantages Considerations
  • Reduces communication between sub-teams
  • Enables teams to build technical expertise specific to their component(s)
  • Requires a loosely coupled, highly cohesive architecture
  • Functional dependency management can be complex
  • Requirements need to be aggregated by component
  • Use for components or subsystems that are highly cohesive and loosely coupled
  • Use for technical-oriented components, such as a security framework or database encapsulation services, which require technical expertise
  • Enables teams to focus on a subset of the business
  • Potential to make it easier to assign features to teams
  • Requires common development conventions
  • Requires sophisticated configuration management
  • Technical dependency management can be complex
  • Requirements dependency management can be complex
  • Use for complex LoBs or applications which require developers to have deep understanding of the problem domain
  • Enables functional specialization of individuals
  • Comfortable approach for people with deep experience with traditional approaches
  • People motivated to be specialists, not generalizing specialists
  • Significant communication overhead between teams
  • Requires more documentation and reviews thereof
  • Requires greater management oversight
  • Increases overall project and organizational risk
  • It often makes sense to have an integration team responsible for integrating the entire solution and testing it end-to-end.
  • Support a “follow-the-sun” strategy where development is performed in one location and testing in another
Internal open source
  • Supports development of shared components or subsystems
  • Spreads the cost of building these components across several development teams
  • Requires other teams to provide developers, at least on a part time basis, to work on this effort
  • Requires management and governance structures which reflect open source development
  • Apply in organizations with developers with deep experience with “public” open source efforts

Note that these strategies can be, and often are, combined.

How Does Team Size Affect the Way We Work?

Large teams will often adopt the following strategies to address the challenges that they face:

  1. Do a bit more up-front requirements exploration
  2. Do a bit more up-front architectural modelling
  3. Do a bit more initial planning
  4. Adopt more sophisticated coordination activities
  5. Adopt more sophisticated testing strategies
  6. Integrate regularly

Strategy #1. Do a bit more up-front requirements exploration.

Figure 13 depicts the process goal diagram for the Explore Scope goal. This Inception goal strategies to elicit and capture the initial requirements for our solution. We want to do just enough work to understand what our stakeholders want so that we can confidently begin Construction. Because larger teams typically take on more complex problems than smaller teams, you’ll find that you need to do a bit more, but just a bit more, up-front requirements so as to ensure that the team understands the problem that they’re tackling. This will often mean that your team needs to address several view types so as to explore the problem from multiple directions and potentially capture a bit more detail than they would in less complex situations.

Figure 13. The Explore Scope process goal (click to enlarge).

Explore Scope process goal


Goal - Inception - Explore Initial Scope

An important consideration is which team members to include in modelling sessions. Do you include all of the team members during all modelling sessions? Do you include only a subset? Do you include a subset during each modelling session but rotate people through so that everyone is involved at least part of the time? Including all team members in all modelling sessions has the advantage that everyone hears what the stakeholders want and provides them with opportunities to ask probing questions. However, this strategy doesn’t scale well to very large teams because it’s costly, not everyone is interested in attending anyway, and there are space limitations in modelling rooms. Having a subset of team members included in all sessions is less costly and likely to be faster, but requires you to communicate your initial requirements to the greater team afterwards. Rotating a subset of people through the modelling sessions gives everyone an opportunity to potentially learn new modelling skills and to hear at least a portion of the requirements details, but still requires communication of the overall requirements to everyone on the team and potentially makes it harder on stakeholders due to the risk of them having to repeat themselves for the changing makeup of the modelling team.

Strategy #2. Do a bit more up-front architectural modelling.

Figure 14 depicts the process goal diagram for the Identify Initial Architecture Strategy goal. This Inception goal describes how we will identify an architecture strategy, or potential strategies, for producing a solution for our stakeholders. As with requirements, larger teams will often invest a bit more effort in initial architectural modelling to ensure that the team understands their strategy for producing a solution. This means they are likely to address several view types and potentially capturing a bit more detail.

Figure 14. The Identify Initial Architecture Strategy process goal.

Develop Initial Architecture Strategy process goal

In the case of both requirements and architectural modelling, the larger the team the more likely you are to capture your models in a more sophisticated manner. For example, smaller teams are likely to use inclusive modelling tools such as whiteboards and paper (e.g. sticky notes and index cards) whereas larger teams may also choose to use software-based tools to capture their work.

This greater investment in up-front modelling, and in capturing that work, helps to build a stronger understanding within your team of what needs to be done and how you intend to do it. This common understanding will make coordination within the team easier later on and thereby reduce project risk.

Strategy #3: Do a bit more initial planning.

Figure 15 depicts the process goal diagram for the Develop Initial Release Plan goal. This Inception goal describes how we will approach creating an initial plan for our team. Although the details will emerge throughout Construction, we still should think about how we’re going to work together and the general timing of that work. As with modelling, the larger the team the more likely it is that they’ll want to invest time in thinking things through. At a minimum your initial release plan should identify major dependencies that you have with other teams, the cadence(s) (in particular the iteration length(s)) adopted by your sub-teams, any major sync up events (such as interim planning and modelling sessions), and even your projected end-date.

Figure 15. The Develop Initial Release Plan process goal.

Develop Initial Release Plan process goal

Strategy #4: Adopt more sophisticated coordination strategies.

Figure 16 depicts the process goal diagram for the Coordinate Activities goal. This ongoing goal describes how we will coordinate our activities within our team and with other teams within our organization. As we described early, the coordination strategies that you adopt within your team become more sophisticated as your team size grows. A small team can operate with non-solo work strategies, daily coordination meetings, and by visualizing their work via information radiators. Medium size teams will need to hold a second coordination meeting across the teams, a “scrum of scrums” (SoS), and may need to start moving towards more sophisticated integration strategies (see below). Large teams will need to go beyond an SoS to adopt more sophisticated coordination strategies such as Architecture Owner teams, Product Owner teams, and an internal Management team.

Figure 16. The Coordinate Activities process goal.

Goal - General - Coordinate activities 

Strategy #5: Adopt more sophisticated testing strategies.

Figure 17 depicts the process goal diagram for the Accelerate Value Delivery goal. This Construction goal describes how our team will ensure that our solution is ready to be deployed. This goal addresses testing, configuration management, documentation, and deployment aspects of development. As we discussed earlier, team size is often driven by complexity – the more complex the problem domain being addressed, or the more complex the technology infrastructure being used, the greater the need for additional people to address those complexities. These greater complexities also drive the need for more sophisticated approaches to agile testing and quality assurance, potentially including a parallel independent test team (which SAFe calls an integration team).

Figure 17. The Accelerate Value Delivery process goal.

Accelerate Value Delivery process goal diagram

Strategy #6: Integrate regularly.

Regardless of team size, agile team strive to integrate their work regularly. Better yet, they do so constantly via the practice of continuous integration (CI). Because integration becomes harder the larger and more complex your solution is, and because large teams tend to work on such problems, integration tends to become more difficult the larger your team is. Integrating the work of ten people is reasonably straightforward, the work of fifty a bit harder, the work of several hundred much harder. As a result you may need someone(s) in the role of Integrator, one of DAD’s secondary roles, who focuses on integrating the overall work of the team (or sub teams as the case may be. People focused on integration will often work closely with any parallel independent testing efforts you have underway and will often be one of the people doing such testing.

What Other Resources Exist?

Parting Thoughts

The goal of this article was to explore the issues surrounding delivery team size. We described our experiences with small, medium, and large-sized agile teams, showing that your approach in such situations needs to vary – one process size, or one organizational structure, does not fit all. What we did not do is cover IT teams such as Communities of Practice (Guilds), Enterprise Architecture teams, or operations teams which collaborate with solution delivery teams.

More Information

Choose Your WoW!

The strategies/practices referenced in the goal diagram above are described, including the trade-offs involved and considerations for when (not) to apply them, in the book Choose Your WoW! A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working.

If you want to succeed at enterprise agile you need choices, not prescriptions.