Feature Team Adoption Map

A feature team adoption map is a useful tool when adopting feature teams.

Scope and Specialization Chart

What is a component? What is a feature? What is functional specialization? So far, we’ve looked at them as binary but the answer exists along a continuum. One group has individual class ownership whereas in another group the team owns a whole subsystem. Both of them are component teams. A similar scale exists related to functional specialization, as some product groups have five levels of testing, which gives “include test in the team” a very ambiguous meaning! Drawing these scales in a graph gives some insights in feature-team adoption and the kind of organizational change you can expect

The graph shows four areas:

• Component teams—Any team that (1) focuses on parts of the product rather than end-customer centric features, or (2) focuses on finishing a task rather than delivering a product increment is a component team. Note!… The smaller the ownership scope and stricter the specialization, the bigger the component-team problems.
• Feature teams—Any team that has a whole-product focus and is involved from clarifying customer-centric features to testing them is a feature team. Feature teams also exist along a scale. They can be limited to implementing predetermined features or be involved with identifying and solving the customers’ real problem.
• Functional overspecialized team—Any team that performs a limited task on a larger scope is probably functionally overspecialized. This leads to lots of waste due to hand-offs. To be avoided.
• Extended component teams—Any team that has a limited component ownership yet is responsible for checking that their part works within the larger product is an extended component team. The team has an internal conflict as they have both a limited “component scope” and a “whole product scope.” This conflict leads to either (1) duplication of work as multiple teams create the same tests, or (2) additional coordination effort as the teams have to coordinate their “product focused” testing. The same conflict of scope is true for requirements clarification. These teams are perhaps an improvement over basic component teams but fall far short of delivering the benefits of feature teams.

Feature team adoption map

A “perfect feature team” is a team that works across the whole system and co-creates the product together with actual users. This is a good very-difficult-to-achieve perfection goal.

With that perfection goal, we can use the earlier chart as a feature-team adoption map. Here is an example:

This feature-team adoption map is from a product adopting LeSS Huge. When they started their adoption they had traditional component teams. They chose the adoption strategy of expanding the teams functional scope and created extended component teams. Their goal for the next few years is to move to full product-wide feature teams. However there are some shared components created by a peer product group and that makes it hard to include these as it would require a significantly larger organizational change. So, these are excluded from their current goal.