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


Have any Question or Comment?

3 comments on “Strategies for Organizing Large Agile Teams

DAD is the only place where I have found explicitly the recommendation to use functional cohesion and decoupling for Components Team in order to avoid the effect of the Conway law.

Imho by applying these rules we will have almost in the same time Feature and Component Teams and possible the benefits of the both.

Timothy Field

This is a huge area that determines the success and failure of enterprise scaling. I’m not convinced this page does it anywhere near justice.

What is missing here is practical examples of when to go for one over the other. There should be variables that show this. For example, end to end delivery in a feature team avoids unnecessary hand-offs and should be a target state. At a certain point, technologies and the number of systems will not allow this as the team would be too big. So rather than simply switching to component teams the answer should be strategies to de-couple the architecture / improve testing / branching etc. These strategic interventions should be listed here if your page is to be of real value. This avoid a sub- optimal recommendation based on a poor set up.

As a further example I am surprised that any set up would recommend a functional set up, even if follow the sun is case in point. Testing should shift left into developer automation with testers and developers working together.


Agreed, but what you’re suggesting would be a book, not an article.


Leave a Reply

Your email address will not be published. Required fields are marked *