June 2019 Archives

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. 

#backlogs and multi-learning - article 4.png

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.

#backlogs and multi-learning - article 4.1.jpg

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.

#backlogs and multi-learning - article 4.2.jpg

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.

#backlogs and multi-learning - article 4.3.jpg

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.

#backlogs and multi-learning - article 4.4.jpg

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.

Number of backlogs and multi-learning: 3) feature group

In this article, we shall look at a variant of the functional team and component team structure - feature group. We shall revisit the dynamics with functional team and component team, and see how much similarity and difference feature group has with them, in terms of its impact on the agility and the lever. 

#backlogs and multi-learning - article 3.png

Feature group is also called feature project. It is formed to deliver customer value, consisting of people from various functional and component teams. Each member has its own work and priority, thus its own backlog. Same as the functional team and component team structure, for the value delivery, it requires the work in multiple backlogs, and they are dependent on one another. The difference between them is on whether those backlogs are responsible by functional team and component team, or by functional members and component members in the group.

Feature group

Let's start from the same diagram for the functional team and component team structure, and understand how it applies in the context of feature group.

#backlogs and multi-learning - article 3.1.jpg

Individual responsibility

Members in the feature group take individual responsibility for either function or component, thus, have multiple backlogs. Why?

B1-loop: specialization for efficiency

The functional or component specialization is good for efficiency. It is now on members, rather than teams, but the same efficiency thinking applies.

This weakens the group's common goal, and likely leads to the following dynamic.

R2-loop: Local identity hurts collaboration

Members still keep strong local identity for their functions or components. This hurts collaboration, which leads to 1) increase integration effort, thus lower efficiency; 2) increase integration time, thus longer e2e cycle time.

The feature group could lessen the silo thinking, as the group may develop a common identity in addition to local identity, something like this - "you belong to this 'team' (feature group), nevertheless, you still do the work in your speciality only."

Cycle time

In the structure of functional team and component team, the related parts may be done at different sprints, thus, the e2e cycle time could be several sprints long. However, the feature group should have the common goal of delivering customer value within the same sprint. In that case, the level of synchronization improves, then, waiting is confined to a sprint. The longest e2e cycle time would be a sprint. This also lessens the below problem.

R3-loop: Rework hurts efficiency

The rework caused by asynchrony still exists, but with the improved level of synchronization, the resulting rework gets decreased.

Specialization

R1-loop: Over-specialization hurts collaboration

Over-specialization does not get fixed when members have their own backlogs (B1-loop). The resulting narrow knowledge breadth continues to hurt collaboration, and creates unintended impact on efficiency.


Besides, with dynamic requirements, the needed effort in various functions and components will change, which creates two more dynamics, shown as the additional R5 and R6 loops in the below updated diagram.

#backlogs and multi-learning - article 3.2.jpg

As members have their own backlogs (B1-loop), the change on effort leads to:

1) Partial allocation

Some members will work in multiple feature groups, then multi-tasking ensues.

R5-loop: Multi-tasking hurts efficiency

More backlogs leads to more multi-tasking, then lower efficiency. The multi-tasking creates another unintended impact on efficiency.

2) Temporary group

Group members will change accordingly, thus the group becomes temporary.

R6-loop: Group instability hurts collaboration

More backlogs leads to less stable group. The feature group consists of people who are able to work on various backlogs. The more backlogs, the more change the group composition endures. It takes time for the group to jell and become effective. Temporary group hurts collaboration, and is hard to sustain the improvement. The group instability creates another unintended impact on efficiency.

In summary, the main dynamics and problems with functional team and component team remain with feature group. However, feature group may have a common goal of delivering customer value within the same sprint, and develop a common identity as a group. Therefore, it is usually better than no group at all, in terms of our goal for agility.

Feature team

To improve further on agility, having fewer backlogs in the feature group is a key lever. In fact, this is the main difference between feature group and feature team. The real feature team has only one backlog, and members take shared responsibility.

R4-loop: fewer backlogs drives broad learning

Feature team may also start with multiple implicit backlogs due to the skill constraints, but by having one explicit backlog, it drives multi-learning and reduces the number of implicit backlogs over time. On the contrary, feature group accepts the status quo and keeps multiple backlogs forever.

Having one backlog removes the need for partial allocation and temporary group. With the dynamic requirements, the needed effort in various functions and components will still change, and there will be mismatch between the work and the skill. When that happens, we take advantage of it and trigger cross-functional and cross-component learning.

The same list of techniques for cross-functional and cross-component learning still applies.

  • 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

Multi-learning further enables fewer backlogs, until eventually achieving one backlog. By then, feature group becomes feature 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.

#backlogs and multi-learning - article 2.png

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.

#backlogs and multi-learning - article 2.1.jpg

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.

#backlogs and multi-learning - article 2.2.jpg

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.

#backlogs and multi-learning - article 2.3.jpg

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.

#backlogs and multi-learning - article 2.4.jpg

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.

This is the first article in a series about "number of backlogs and multi-learning".

Goal for Agility

Let's first set the stage for our analysis by clarifying the system optimizing goal. The goal is to optimize for agility.

The agility is to deliver highest customer value in uncertain environment. With uncertainty, the ability to deliver is not sufficient, we need the ability to inspect and adapt, in order to deliver highest customer value.

We may inspect and find that market changes, then, we embrace the change and make the necessary adaptation, then deliver the value. We may deliver our initial idea, then, we inspect the feedback, then adapt by acting on the feedback.

Here is the essential cycle to illustrate.

#backlogs and multi-learning - inspect-adapt-deliver.png

  • Inspectability

The ability to inspect is the ability to learn. Learn the market and customers, learn the feedback, and analyze to gain the insights.

  • Adaptability

The ability to adapt is the ability to change the direction. Embrace the change and decide the next appropriate step - either refine it or make a pivot.

  • Deliverability

The ability to deliver is associated with e2e/end-to-end cycle time. Deliver customer value now; or deliver to learn now so as to deliver more value later.

To optimize for agility, we optimize for either of them or all of them.

Backlogs with various teams

There are various team structures in product development organizations. Let's see different backlogs associated with them.

  1. Functional team and component team

Functional team is responsible for functional work such as analysis, design, implementation, 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. 

#backlogs and multi-learning - functional team and component team.png

In the above picture, each box is either a functional team or a component team, and each team has its own backlog (i.e. 6 backlogs in total). In the second article, we shall analyze its impact on the agility and find the lever to optimize for the agility.

  1. Feature group

Feature group is also called feature project. This is directly connected to the structure of functional team and component team, thus, more as a variant. Project group is formed to deliver customer value, consisting of people from various functional and component teams. Each member has its own work and priority, thus its own backlog. Same as the first structure, for the value delivery, it requires the work in multiple backlogs, and they are dependent on one another.

#backlogs and multi-learning - feature group.png

The above picture is actually the same as the one for functional team and component team, except each box now is either a functional member or a component member, and each member has its own backlog (i.e. 6 backlogs in total). It is likely that multiple members share one backlog for certain function or component, but the structure remains the same. In the third article, we shall revisit the dynamics with functional team and component team, and see how much similarity and difference feature group has with them, in terms of its impact on the agility and the lever.

  1. Specialized feature team

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.

#backlogs and multi-learning - specialized feature team.png

In the above picture, each box is a feature team, and each team has its own backlog (i.e. 3 backlogs in total). In the fourth article, we shall analyze its impact on the agility and find the lever to optimize for the agility.

Here are all four articles in this series.

  1. see the backlogs
  2. functional and component team
  3. feature group
  4. specialized feature team

 

About this Archive

This page is an archive of entries from June 2019 listed from newest to oldest.

March 2019 is the previous archive.

Find recent content on the main index or look in the archives to find all content.