Number of backlogs and multi-learning: 4) specialized feature team

In this article, we shall look at the structure of specialized feature team, and explore the dynamics around their backlogs, then analyze its impact on the agility and find the lever to optimize for the agility.

Feature team is responsible for delivering customer value from end to end, thus, there is only one backlog associated with value delivery, i.e. the whole team shares the work and one priority. However, for the organization, there are multiple feature teams, each having its own backlog. They are responsible for different customer domains, thus, specialized feature teams. Those work in different backlogs are independent of one another.

More backlogs for efficiency

Let's still ask the question of why having multiple backlogs for feature teams. The answer again lies at the efficiency thinking.

B1-loop: specialization for efficiency

This is the same loop as the one you have seen in the structure of functional team and component team. There is an explicit or implicit efficiency goal. This causes efficiency gap, leading to more backlogs, more specialization, higher efficiency, which reduces the gap.

However, here is a different type of specialization. Instead of specializing on function for functional team and on component for component team, feature team specializes on customer domain. This creates the different impact.

The "unintended" impact on adaptability

As feature team can deliver customer value independently, thus, having more backlogs won't have direct impact on e2e cycle time. The unintended impact is on adaptability.

In the upper part of the diagram, there are 3 causal links from #backlogs to adaptability.

1. More backlogs, lower transparency, less motivation to respond to change, lower adaptability.
2. More backlogs, stronger local identity, less motivation to respond to change, lower adaptability.
3. More backlogs, more specialization, narrower knowledge breadth, lower adaptability.

All of them indicates that having more backlogs leads to lower adaptability.

In order for higher adaptability, we need to:

1. increase transparency so that we see the need to adapt
2. reduce silos associated with local identity so that we are willing to adapt
3. increase knowledge breadth so that we have the skill to adapt

Multi-learning for fewer backlogs

Let's see how to drive toward fewer backlogs in the context of feature teams.

R1-loop: fewer backlogs drives broad learning

More backlogs, more specialization, narrower knowledge breadth. Then, the narrow knowledge breadth becomes the cause for more backlogs, and it creates a reinforcing R1-loop. It is easier to work in the direction of more backlogs, how could we turn this around?

Take the same reinforcing loop and make it like this - fewer backlogs, less specialization, broader knowledge breadth, even fewer backlogs... The challenge is that less specialization does not lead to broader knowledge by itself. We need multi-learning to increase the knowledge breadth.

Fewer backlogs drives multi-learning; multi-learning enables fewer backlogs. They are mutually reinforcing. Therefore, the number of backlogs itself is an important lever - have one backlog for multiple feature teams.

The above analysis is exactly the same as the one for functional team and component team. What are the differences here? The knowledge breadth here is about customer domain, rather than function or component. The backlog here is product backlog, rather than functional or component backlog. The multi-learning here is cross-domain learning, rather than cross-functional or cross-component learning.

What are the techniques to do cross-domain learning? LeSS provides a guide about multi-team PBR. This is the key practice for any feature team to learn broadly about as many items as desirable from the same product backlog. In fact, when you start the adoption, it is recommended to do all-team PBR by default, in order to maximize the learning. During multi-team PBR, instead of having different feature teams refine different items, we create mixed groups with people from different feature teams, and have them refine different items. They diverge and merge to get the maximum cross-domain learning among those feature teams sharing one product backlog.

In summary, the associated backlogs in feature teams are still for efficiency, but it creates unintended impact on adaptability, rather than e2e cycle time. Cross-domain learning enables fewer product backlogs, while fewer product backlogs in turn drives cross-domain learning.

Conclusion

Let's conclude this series by putting various types of backlogs, specialization and multi-learning together.

The drive behind having various backlogs is higher efficiency through specialization. They specialize on different things - function, component and customer domain. They create different problems. Functional backlog and component backlog create dependency among them for delivering customer value, thus, they have the most impact on e2e cycle time. While product backlog is independent of one another, it has the most impact on adaptability.

The key lever all lies at multi-learning, though different types of multi-learning. Cross-functional learning enables fewer functional backlogs; cross-component learning enables fewer component backlogs; and cross-domain learning enables fewer product backlogs.

This ends the series - number of backlogs and multi-learning.