There are a number of ways of forming teams:
Discipline Teams are formed by making teams around technical specialists.
This approach leads to requirements teams, testing teams, development teams, management teams etc. We strongly recommend against this approach as there is significant cross-team coordination required to deliver anything. We’ve observed that most integration problems are caused by team-of-teams working, and this approach forces team of teams working. Typical problems include:
Cross-team conflicts caused by abdication of responsibility for quality
Cross-team conflicts caused by unclear Definitions of Done
Discipline teams begin to care more about discipline maturity than business value delivery
Discipline teams begin a process scope-creep to other areas (e.g. test teams trying to control defect lifecycles within development teams)
Discipline teams become increasingly abstract talking shops, they don’t actually deliver anything
Component/Service Teams are formed by making teams around architectural
This approach leads to GUI teams, middleware teams, database teams etc. We generally recommend against his approach for entire systems as user facing changes require the coordination of multiple teams. Along with many of the problems of Discipline Teams we also see Component Teams caring more about the purity and architectural separation of their component more than Business Value
Feature Teams are formed by making teams around significant areas of user facing functionality. Feature teams are cross-functional in the sense that they can work across the entire architecture, and all components or services to deliver an end to end user requirement.
This approach can be implemented in 2 ways:
Requirements based – Feature teams are created to deliver a particular end to end requirement (e.g. an Integration Scenario)
Stable team – Feature teams are created to be enduring. The teams then pick end to end requirements, such as Integration Scenarios, off a backlog one by one
Feature teams also have disadvantages in that there is often overlap between Integration level requirements within system architecture and delivery, and so a mechanism for conflict resolution needs to be put in place (e.g. a Product Forum
). This approach can also lead to no one team doing the “common good” work that’s general enough to not be considered part of an end to end requirements but still necessary to achieve good quality.
Platform vs. Application Teams
A mix of Component and Feature approaches is to build:
Platform teams that are organized around an enabling architecture, common services and APIs. A platform team is essentially a multi-component team that is focused on “common good” work at all times.
Application teams that are organized around end to end requirements, building applications or services on top of a Platform. The work of various Application teams will drive priorities on Platform teams.
Although this model provides the best of both worlds it frequently leads to conflict between application/service teams and platform teams and so we recommend using the Product Forum
practice to coordinate.
We recommend that teams include a mix of people with all of the skills needed to take a business requirement from an initial problem, through candidate approaches and eventually to a deployed live product. In tune with DevOps
philosophy Holistic Product teams support what they make, incentivizing to make high quality products and foster good relationships with their customers.
Every case is different but in the general case we’ve had significant success with a combination of Holistic Product teams for single products and Holistic Platform & Application Teams for Product Family