What does your Team Optimize For?
What does your Team Optimize For?
The canvas below shows four characteristics of development teams. On the y-axis, you can plot the level of cross domain work your team picks up. It goes from working on a Single Domain (top) to working on the Whole Product Domain ( bottom ). On the x-axis, you can plot the level of the cross-component work your team picks up. It goes from working in a single component (left) to working across the Full Component Stack (right).
Feature Factory Team
When a team can work on all components but only one feature, then the team is optimized for delivery speed at the single feature level but cannot adapt to work on other features. The team has no external dependencies for their specific feature; hence, there are no queues or delays. Such a team optimizes for fast feature delivery in a single domain. When the most important product work is outside their domain, they cannot adapt to that.
In contrast, when a team covers all features but only one component, they can work on all feature-parts; hence, it can adapt to all work that comes in for that component, but most of the time cannot deliver end-to-end customer value. Such a team is optimized for adaptability at the local component level but cannot work on other components to produce a complete feature. When the most important product work is outside their component, they cannot adapt to that.
Code Factory Teams
When a team covers a single component for a single domain, that team combines the specialization problems of Feature Factory Teams and Component Teams. The cannot adapt to work on other features or component, and cannot deliver end-to-end customer value
Neither of these team configurations is particularly useful for achieving adaptability at the overall product level. On the one hand, if all teams are feature specialized, then it is hard for them to work in other feature areas. When the most valuable work is outside their expertise, they are unlikely to pick up that work, but will instead pick up lower-value work. They are maximized for speed for their work but are minimized in terms of adaptability to the work that needs to be done at the product group level.
On the other hand, if all teams are component specialized, then it is hard for them to work on other components to deliver value. When work spans multiple components, they are unlikely to deliver it completely. Such a team can work on all feature-parts—it is maximized for adaptability for working on all features, albeit only parts—but introduce hand-offs, queues, and delays to complete an end- to-end feature.
When a team works across components and domains, it can pick up any work that comes in and deliver it into the hands of the customer. In this case, the group is maximumly adaptable to the incoming work.
One problem with large products is that it can be hard for a cross-functional team to cover all features and components in a product. There may be just too many technologies and too much domain knowledge required. You can minimize the cognitive load be specializing around Value Area’s (see Value Area’s Scrum Pattern), simplification of architecture and learning. You likely will never get perfect feature teams, but with every step your team takes, the more adaptable the group becomes. You can see it as a perfection vision.
Using the Canvas To Balance Your Team Configurations
You can use this canvas to plot a team’s current position and then evaluate how it can improve. It gets more fun when you plot many teams relative to each other on the canvas and use that information in an overall retrospective to find the balance that works for you.
Questions you can consider are:
- Where does your team stand on this canvas?
- What team configuration does the larger group need most to reach its goals?
- Is your team’s position on the canvas in line with your group's goals?
- If not, according to what trajectory would the teams need to move?
Have fun, and feel free to let me know if it was useful.