Strategies for Organizing Large Agile Teams

When it comes to organizing large or geographically distributed agile teams many people will tell you that there are two strategies, taking what is called a component team approach or taking a feature team approach.  Many people will tell you to take a feature team approach over a component team approach, but the fact is that both strategies has advantages and disadvantages and neither is right for all situations.  Furthermore, those are the only two strategies as you will soon see, although to be fair they are the most common two.

This article explores the four basic strategies for organizing agile teams.  We compare and contrast these four strategies in Table 1 below, in accordance to the “it depends” philosophy of the Disciplined Agile Delivery (DAD) framework.  Our goal is to make it clear that you have choices when organizing agile teams, and that you should understand the trade-offs that you are making with each choice.  You will also find that you want to combine strategies, and in fact most large agile programs that we’ve seen do in fact do this.  The four strategies are:

  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 ApproachAdvantagesDisadvantagesConsiderations
  • 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