Number of backlogs and multi-learning: 2) functional team and component team

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

Functional team is responsible for functional work such as analysis, design, implementation, and testing. Component team is responsible for the implementation of various components, such as component A, B and C. Each team has its own work and priority, thus, its own backlog. For the value delivery, it requires the work in multiple backlogs, and they are dependent on one another.

More backlogs for efficiency

Let's step back and first ask the question of why having more backlogs. The answer lies at the efficiency thinking.

B1-loop: specialization for efficiency

There is an explicit or implicit efficiency goal. This causes efficiency gap, leading to more backlogs, more specialization, higher efficiency, which reduces the gap.

Relatedly, higher efficiency leads to shorter touch time (i.e. the time used to process the work in function or component), thus, shorter cycle time. However, we need to understand how much percentage touch time accounts for in the whole e2e cycle time, and see the bigger picture.

The "unintended" impact on cycle time

Let's see more factors having impact on cycle time.

In the upper part, more backlogs, more parts for integration, longer integration time, longer e2e cycle time.

In the lower part, more backlogs, lower level of synchronization (different parts are being worked on at different times), which leads to: 1) more rework, thus, more rework time; 2) longer waiting time. In both cases, longer e2e cycle time.

Even though having more backlogs may lead to shorter touch time, many other factors create negative effects on the whole cycle time. It is often the case that touch time is not the most significant part, while waiting and integration account for much more. Then, overall, more backlogs leads to longer e2e cycle time.

The "unintended" impact on efficiency

Let's return to the efficiency. As we analyzed earlier, it is the efficiency goal that drives toward more backlogs. Now we shall see the unintended impact on efficiency.

Level of collaboration is the commonly overlooked factor. The unit does not stand alone, but needs to integrate with other units. The integration requires to collaborate with others, thus, the level of collaboration affects both time and efficiency. Let's see a few dynamics that create negative effects on collaboration.

R1-loop: Over-specialization hurts collaboration

More specialization leads to narrower knowledge breadth. The knowledge breadth is important for collaboration. In fact, the overlap in knowledge among collaborators helps a lot on the mutual understanding. The narrow knowledge breadth on one hand decreases efficiency, thus, creates the R1-loop; on the other hand, it creates more negative effect on integration time, thus, even longer e2e cycle time.

R2-loop: Local identity hurts collaboration

More backlogs leads to stronger local identity, which means that our group only works on this function or component, as well as other group is not allowed to touch it. These are functional and component silos, and they hurt collaboration. This both decreases efficiency, thus creates R2-loop and worsens the integration time, thus even longer e2e cycle time.

Another dynamic comes from the rework, which creates negative effect on efficiency.

R3-loop: Rework hurts efficiency

The rework caused by the asynchrony (i.e. low level of synchronization), which is caused by having different backlogs, decreases efficiency. This creates R3-loop.

Overall, B1-loop aims to increase efficiency, while it creates unintended consequence on collaboration and rework. B1-loop and R1..R3-loop form the system archetype of "fixes that backfire". In the meantime, these effects on collaboration and rework worsen the e2e cycle time.

Multi-learning for fewer backlogs

Let's see how to drive toward fewer backlogs.

R4-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 R4-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 by creating a real cross-functional and cross-component feature team.

What do we multi-learn? The backlogs are based on functions and components here, thus, we do cross-functional and cross-component learning.

What are the techniques to do cross-functional and cross-component learning? The below is a list of well-known techniques, and many of them are in LeSS guides.

• specification by example
• collective code ownership
• pair/mob programming
• communities of practices (both functions and components)
• component mentor
• current-architecture workshop
• multi-team design workshop

In summary, the associated backlogs in functional and component teams are for efficiency, but they create unintended impact on e2e cycle time, and even worse, the efficiency as well. Multi-learning enables fewer backlogs, while fewer backlogs in turn drives multi-learning.