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:
- 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.
- 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.
- 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.
- 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.
|Internal open source|