Team Design Patterns – Feature teams supported by component teams

In the last article, I outlined the Large Feature Team pattern as a first alternative to the Ideal Team Structure (ITS) if your organization cannot make the immediate leap to the ITS when transitioning to agile solution delivery. In another article, I provided an overview of the concepts of feature teams and components teams. In this article, I will discuss the second alternative using a combination of feature teams and component teams.

Here is a picture of an example agile software delivery organization with feature teams and components teams:

From a flow perspective, Business Intent Generators (BIG’s) create a product backlog for one or more feature teams. The feature teams are built with members whom have the skills and knowledge most aligned with building solutions that meets the business intent. Additionally, the feature teams are constructed to maximize their ability to build the solutions for that business intent before needing to reach out to other teams to develop other required portions of the overall solution. When the feature teams get too big to be truly agile, you can create component teams constructed from team members with skills and knowledge specialized around specific platforms and/or components. Reminder – when beginning your agile transition, this model only makes sense when you have too much specialization of skills to allow the ITS to break out.

When the feature teams need updates to platforms and/or components that live outside of their team, they create backlog items for the component team(s). The component team Product Owner works with the feature team Product Owners to prioritize backlog items coming from across potentially many feature teams. If you need to organize with component teams, it is best if each feature team only needs to interact with one component team that has all of the skills and knowledge of platforms and/or components not present in the feature team. In this design, there are two teams (i.e., one feature team and one component team) involved in delivering solutions to meet the business intent. If your architecture is very complex and specialization is very deep in the components of that architecture, you may need to have multiple component teams servicing each grouping of feature teams if all the component skill and knowledge cannot fit into one 7 +/- 2 component team. Whether you have one or more component teams for any feature team, it is most important to mix up the component specialization skills in each of the component teams so that team members can start working on cross-training and knowledge sharing across the various components and start the journey towards building an organization of generalizing specialists. It may be tempting to organize your component teams around singular components to minimize the disruption to current organization of platform/component specialists. This is probably the worst option for component teams as it does not provide any cross-training opportunities nor any path towards building an organization of generalizing specialists for the ITS. The organizational re-design may be unsettling to team members. However, it may be an important aspect of beginning your journey to agile solution delivery with a clear signal to your organization that business will now be done differently. If the reasons for the organizational decisions and change are clear and communicated well, the shock of the new organization will soon pass and the highest majority of the team will help get the company to the new way of operating.

In the next article, I will outline the third and final alternative to the Ideal Team Structure – feature teams with mixed-composite skills.

Previous article | Next article