The Odd-e Blog

 
The Authors
 

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. 

#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.

Thumbnail image for #backlogs and multi-learning - article 2.4.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.

Thumbnail image for #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.

 

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.

#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.

 

Number of backlogs and multi-learning: 1) see the backlogs

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

 

 

The trap in learning from success

In our industry of product development, it is common that we try to learn from success. The successful people summarize a few factors from their experience, often in the name of best practices, then others would learn to apply. It is believed that A leads to success, thus the learning is focused on how to do A well. However, in reality, others often fail miserably after adopting A.

Why does A not lead to success for others, and what went wrong?

Correlation vs. Causation

Let's first understand the difference between correlation and causation. The most popular example is perhaps "does ice cream cause drowning?". They are correlated - when ice cream sales are high, so is the number of drownings. However, ice cream does not cause drowning. In fact, it is the hot summer that boosts both ice cream sales and swimming.

Sometimes we mistake correlation as causation. A may just be correlated to success, but does not cause success. Of course, we would not get the desired effect when adopting A.

How can we get the causation right? It is hard indeed. What helps is while learning from success, we examine the full chain of reasoning. We should learn about the causation, not the result.

Types of Causation

We also need to understand what type of causation it is. Is A sufficient for success, or is A necessary for success?

It is hardly the case that A would be sufficient for success. When A is sufficient, doing A is enough for success. However in reality, there are often other hidden factors, and they may even be necessary for success.

It is hardly the case either that A would be necessary for success. When A is necessary, not doing A always leads to failure. However in reality, there are often alternatives to A.

So, it is more likely that A is contributory for success - neither sufficient nor necessary. A simply provides one path. We fail miserably when treating A as the certain answer. Instead, we should learn them as the ideas for experimentation.

Systems Thinking

Seeing the causation is a good step towards real learning, but it is not enough.

Product development system is dynamically complex, which means that cause and effect are often distant in time and space. It is common that we only see the local effect and the short-term effect, while the global effect and the long-term effect are not examined. We fail miserably when taking the static view and treating A as the forever answer.

Instead, we should apply systems thinking while learning from success. Systems thinking is powerful in understanding dynamically complex system. It is not only a problem-solving tool, but also a learning tool. We ask the following questions. Does it influence other part of the system? What is the behavior over time? What is the underlying structure and mental models? We learn how those factors interact with each other, and how the effects evolve over time.

The Point is ...

The most important learning is not A itself, but the reasoning behind.

Once you understand the logic, you do your own reasoning. Only then, you shift your focus to learn how to do A well. After adopting A, you inspect and adapt along the way, as it is neither certain nor forever.

This applies to learn about LeSS as well. LeSS framework consists of a set of practices - one backlog, one product owner, feature team, requirement area, etc. However, the most important learning should come from the reasoning. If you simply copy LeSS as "certain and forever" best practices, I bet that you will fail miserably too:)

 

Explore different mental models

A mental model reflects an individual's beliefs, values, and assumptions. As those are quite often internal, we need to somehow express them in order to learn and improve. In fact, the model with Causal Loop Diagram is a representation of the mental model. We could explore different mental models by simply doing advocacy and inquiry with CLD. Balancing advocacy and inquiry is one key practice for the discipline of mental models, among the five disciplines from the classical "The fifth discipline" book.

This article shares with you an example. It came from my CLP, and we were doing system modeling for #backlogs and its impact on the adaptiveness.

Explore different mental models - setting.jpg

The above picture provides the setting. Suppose that we have 3 feature teams for one product, we could have 1 backlog and let 3 teams share one backlog (the left in the picture); or we could have 3 backlogs and let 3 teams have their own backlogs (the right in the picture). The adaptiveness means team's capability of changing to do other higher-value work. It is affected by both the motivation and the ability to adapt.

We came up with the below CLD representing one mental model.

Explore different mental models - initial cld.jpg

There were three causal paths indicating the relations between #backlogs and the adaptiveness.

  1. More backlogs, lower transparency, lower motivation to adapt, lower adaptiveness 
  2. More backlogs, smaller work scope for any team, stronger local identity, lower motivation to adapt, lower adaptiveness
  3. More backlogs, smaller work scope for any team, higher specialization, smaller knowledge breadth, lower ability to adapt, lower adaptiveness 

One student shared that in her organization, they had more backlogs (i.e. the case of 3 teams and 3 backlogs), but it seemed not leading to lower adaptiveness. What happened? We then reasoned about each path and explored other possible mental models, by doing both advocacy and inquiry.

  1. More backlogs, lower transparency, lower motivation to adapt, lower adaptiveness 

[me] did more backlogs lead to lower transparency?

[student] what is transparency here, could you elaborate more?

[me] transparency here means the chance of knowing the value of their work relative to the whole product by the team. when each team has their own backlog, teams may not know that they are doing globally lower-value work. does this happen in your organization?

[student] not really. we have pretty fast feedback for our work, if one team does lower-value work, the business impact would be lower, which would be visible for them quite soon.

[me] interesting, so, then, the motivation to adapt stays high?

[student] yes. we are always motivated to adapt for higher-value work.

  1. More backlogs, smaller work scope for any team, stronger local identity, lower motivation to adapt, lower adaptiveness

[me] how about local identity? having own backlog limits the work scope for the team, thus team develops stronger local identity, which demotivates them to work on any other work outside their scope. do you see this in your organization?

[student] not really. it is the norm in our organization that if the business impact is low, we gotta change. our team never sticks with the local identity. i guess, this is because we are always driven for business success.

  1. More backlogs, smaller work scope for any team, higher specialization, smaller knowledge breadth, lower ability to adapt, lower adaptiveness

[me] how about the ability to adapt? as each team gets specialized in their work scope, their knowledge breadth gets small thus decreases the ability to adapt. do you see this in your organization?

[student] indeed, the adaptation is always painful for the team. they are motivated to adapt, but they don't prepare for it in terms of knowledge. we have been struggling with this.

[me] yes, in LeSS, there is only one backlog and multi-team PBR is specially designed to maximize broad learning optimizing for the adaptiveness.

We updated the original CLD, reflecting the different mental models that we explored.

Explore different mental models - updated cld.jpg

For their organization, strong orientation to business feedback increases the motivation to adapt, while the limited broad learning due to specialization decreases the ability to adapt.

One challenge in working with mental model is that it is often implicit. CLD helps express it, and doing both advocacy and inquiry on the causal links is a powerful way to explore different mental models.

 

#backlogs - the ultimate lever

#backlogs is the ultimate lever for agility.

This is the insight we gained from the systems modeling exercises in my recent CLP course. I used to think of two main designs from LeSS: 1) one product backlog and 2) feature team. I found that these two were just the different applications of the same lever, which is #backlogs. Please be noted that backlogs here are all kinds, including product backlog, team backlog, individual backlog, etc. Some are explicit, and the other are implicit.

How many backlogs do we have in an organization? Does one product have one backlog? Does one team have one backlog? Or, does one person have one backlog? When all teams in the same product share one priority, there is only one backlog for the whole product. When every member in the same team has its own priority (e.g. his priority follows his speciality), there are actually many backlogs even for one team.

When we actively look for backlogs, we will find plenty.

Effects on agility

When we find many backlogs, there are two kinds.

  1. Parallel/independent backlogs 

#backlogs is the ultimate lever 1.jpg

This is the case when each feature team specializes in one customer domain and has its own backlog. What if there is more high-value demand from one of those customer domains? As other teams have their own backlogs, we won't be able to adapt based on the shifting demand and maximize the customer value.

The more parallel/independent backlogs, the less adaptiveness.

  1. Sequential/dependent backlogs

 

#backlogs is the ultimate lever 2.jpg

This is the case when each component team specializes in one technical domain and has its own backlog. What if the feature requires the change in all those technical domains? As each team has its own backlog, chances are that not all of their work will be in sync, thus the end-to-end cycle time will increase.

The more sequential/dependent backlogs, the longer cycle time. Eventually it does harm to the adaptiveness.

Agility means adaptiveness. In short, the more backlogs, the less agility.

Constraints from specialization

Why do we create many backlogs? We want specialization. Why do we create backlog for each customer domain? We want specialization on customer domain. Why do we create backlog for each technical domain? We want specialization on technical domain.

The more specialization, the more efficiency and the higher quality. It must be good, right? However, it becomes our constraints over time, and does harm to our agility. When it happens, is it our conscious decision? Most likely not, it is just based on our fast thinking. Instead, we should do more slow thinking here, so as to see its consequence.

Having everyone able to do everything is a sufficient but not necessary condition to enable one backlog in the team. Similarly, having every team able to do everything is a sufficient but not necessary condition to enable one backlog in the product. The key is, there should be no constraints when we say that those people or teams have one backlog. Once we could not adapt to maximize customer value, we are over-specialized.

How do we reduce the constraints? We learn, and we cross-learn. When we are less constrained by our specialization, we are more agile. Learning effectiveness should become our focus in order to reduce #backlogs and achieve agility.

LeSS or less

How much specialization is over-specialization? It depends. It depends on our need - how much agility do we need? It depends on our capability - how much broad learning provides the right amount of challenge for our people?

LeSS provides a reference point for our consideration, which is for roughly 50 people, we want to strive for one product backlog with multiple feature teams. Feature team means that we do not create separate backlogs for each technical domain/component; while one product backlog means that we do not create separate backlogs for each customer domain.

What if this step is too big for us? Our first step could be to combine backlogs for two technical domains/components, or for two customer domains, therefore, have one less backlog. That is the minimum step we could take.

When we reduce #backlogs, we increase agility. Indeed, #backlogs is the ultimate lever.

 

Seeing system dynamics in organizational change: 7) incremental structural change

This is the seventh article in the series of seeing system dynamics in organizational change. In the last article, we concluded that incremental structural change was more appropriate for huge organizations. In this article, we shall look at the different approaches for incremental structural change.

Two approaches

There are mainly two different approaches for incremental structural change. For the ease of explaining, I shall refer to the LeSS terms, but the thinking behind goes beyond LeSS and applies to the incremental structural change in general. 

Seeing system dynamics in organizational change - 7.1.jpg

The above diagram illustrates these two approaches for a typical telecom product. The product consists of 3 main subsystems - O&M (Operations & Maintenance), CP (Control Plane) and UP (User Plane). In each subsystem, there are several components. Before we start the change, all teams are organized around components and functions. The change vision is that all teams will be cross-functional and cross-component, i.e. all are feature teams. How are we going to make incremental structural change?

  1. Gradual expanding

This is the approach used with LeSS guide: feature team adoption map. We first expand the scope of component team and move it closer to feature team. For each subsystem, we make structural change to create "feature" teams inside subsystem. The expansion happens in parallel in all subsystems.

  1. Cutting through

This is the approach used with LeSS guide: one requirement area at a time. We cut through all subsystems and create the first requirement area, with a few real feature teams. In the meantime, the major part of the organization remains with the old structure.

There are similarities and differences between these two approaches.

What's the same

Both are incremental structural change. Thus, both are only the first step towards the change vision. As described in the last article of "the scope of structural change", we limit the change scope to decrease the complexity, but it extends the change period, which increases the complexity. Therefore, it is a balance.

There are a couple of challenges for incremental structural change.

  1. The initial success is critical, as there involves a reinforcing loop. 

Seeing system dynamics in organizational change - 7.2.jpg

R1-loop: Result speaks

Better result, more commitment, more investment, leading to even better result. Note that it works in other direction too. Worse result, less commitment, less investment, leading to even worse result.

This is probably the most fundamental dynamic for any change. We must have the initial success and let the result speak. This applies to both approaches.

2. The change may stall after the initial success, as described in the article of "from change resistance to limits to growth". In order to grow the change, we have to set the next goal immediately after the initial success, until the change vision about organizational structure is fully achieved.

What's different

In order to have the initial success, these two approaches make different trade-offs, as summarized in the below table.

Seeing system dynamics in organizational change - 7.3.jpg

Let's elaborate in more details.

  1. Organization

We would only have real feature teams with the second approach. The change there is more disruptive, as it cuts through the whole organization. However, it does not affect everybody immediately, instead, the initial change is based on volunteering.

The second approach also leads to parallel organizations, in which one requirement area works in the new mode, while the rest of the organization remains in the old mode. This increases the complexity for change management.

  1. Customer value

Individual teams in the second approach would deliver real customer value in every sprint, while inside-subsystem "feature" teams still need to coordinate and integrate their work together for customer value delivery. In essence, inside-subsystem "feature" teams are still component teams, thus, they suffer from the same problems as component team, but to a lesser extent.

  1. Learning

Learning from a component to a subsystem is more gradual in the first approach, while broad learning is usually required immediately in the second approach. The broad learning could mean a big challenge if team members have narrowly focused on small components in the past.

 

In summary, both approaches are incremental, thus share the same basic reasoning and dynamic. However, they make different trade-offs for the initial success, thus take different first step.

 

 

Seeing system dynamics in organizational change: 6) the scope of structural change

This is the sixth article in the series of seeing system dynamics in organizational change. We shall examine the topic of structural change in this and next articles. We first look at the scope of structural change - how big structural change is appropriate, and what factors and dynamics are involved in the choice.

Structure is a first-order factor

I have referred to Richard Hackman's work on how structure and coaching jointly affect team performance in various articles, e.g. Team-first or Organization-first, Huawei - LeSS without Scrum. I do not repeat his diagram here, but present it as a "limits to growth" dynamic.

Seeing system dynamics in organizational change - 6.1.jpg 

R1-loop: Coaching for performance

We improve the coaching effectiveness, which improves organizational performance. Then, we further improve coaching. We expect to create a virtuous cycle.

B1-loop: Structure limits performance

The current structure becomes a limit, as it is inconsistent with the goal. Once the organizational performance is high, the structural change is small. This keeps the structural consistency low, which eventually limits the growth of the organizational performance.

The leverage in "limits to growth" system dynamic is to break the balancing loop, preferably in early time. This means to work on the structural change from early on.

Then, how big structural change is appropriate?

The scope of structural change

Let's first understand the scope of structural change and look at it as a continuum.

Seeing system dynamics in organizational change - 6.2.jpg

  1. No structural change. In traditional project setting, the group is formed virtually and temporarily. There is essentially no structural change.
  2. Structural change for one team. This one team is formed permanently, and the reporting line is changed accordingly; while the other teams remain in the old structure. There exist parallel organizations - one part in old structure and the other part in new structure.
  3. Structural change for all teams. All teams are formed at once, and the whole organization is in new structure.

Seeing system dynamics in organizational change - 6.3.jpg

Once the organization is huge, consisting of many teams in many areas, we may take intermediate step and change the structure for multiple teams - more than one team but fewer than all teams. This could mean structural change for (3a) all teams in one area, or (3b) one team in all areas. We could still change all teams in all areas at once, as shown in (4).

In summary, we could define the scope of structural change as a variable, from (1) smallest to (4) biggest.

  1. No structural change
  2. Structural change for one team
  3. Structural change for multiple teams
  4. Structural change for all teams

Structural consistency vs. stability

Suppose that the current structure is not consistent with our change goal, we need to increase the consistency in order to succeed the change. 

Seeing system dynamics in organizational change - 6.4.jpg

B1-loop: Structural change for consistency

As structure limits organizational performance, we make more structural change, which brings the structure more consistent with the goal. As a result, the organizational performance improves.

B2-loop: Structural change breaks stability

The more structural change, the less structural stability, the more resistance to reduce the structural change.

This is particularly true when the structural change involves the dissolution of existing roles. It poses a threat to the psychological safety. This is why it is so important to ensure job safety but not role safety, as described in the article of "job safety but not role safety".

The structural consistency is the system goal here, while the structural stability is the secondary concern. We make structural change to optimize for the consistency, while address the stability concern in other ways.

Structural change scope vs. period

The scope of structural change affects change period too, i.e. how long the whole change will take. Think about a 20-team organization. If you make structural change for one team at a time, the scope of each change is small; but the change period is long. If you make structural change for all teams at once, the scope is big; but the period is short.

Seeing system dynamics in organizational change - 6.5.jpg

B3-loop: Small change scope to reduce risk

When we perceive the high change risk, our anxiety increases. This leads us to make smaller structural change. Smaller change scope is less complex, thus, its risk becomes lower.

R2-loop: The complexity from long change period

While making smaller structural change, the change period becomes longer. The long change period increases the complexity, thus, its risk becomes higher.

Why does the long change period bring in the additional complexity? A couple of main reasons:

  1. It requires strong discipline of the organization to get through the long change period, without losing the focus. There will be more crises in the longer period, which triggers our short-term thinking to shift the burden, as described in the article of "from survival need to shifting the burden".
  2. The parallel organizations are challenging to work with, as different parts of the organization are not consistent with each other, which easily causes confusion. The longer it is kept as parallel organizations, the more pains it has to go through.

Of course, the complexity from the change scope is also valid. It is indeed more risky to change a bigger part of the organization at one time. We need to balance between change scope and change period.

LeSS does not suggest to start from one-team change, but make the structural change at once for 2-"8" teams. However, LeSS Huge suggests to take incremental approach for "8"+ teams. That is the choice of LeSS regarding how big structural change you make at one time.

In the next article, we are going to dive deep in how to make incremental structural changes.

 

Seeing system dynamics in organizational change: 5) job safety but not role safety

This is the fifth article in the series of seeing system dynamics in organizational change. In the previous article, we concluded that the best time to de-scale was when the organization is still small and has few roles. In this article, we take up the challenge of reducing special roles, notably managers and specialists, when they are already in place.

No role safety

We reduce the special roles to have more responsible teams, which increase the organizational adaptiveness. However, it creates the discomfort among those special roles. All kinds of concerns are raised to resist the change. As those concerns are often valid, the special roles remain and change stalls.

Seeing system dynamics in organizational change cn - 5.1.jpg

B1-loop: Reduce special roles to increase adaptiveness

To fill in the adaptiveness gap, we apply the de-scaling force, thus, reduce the number of special roles. This increases team self-organization, then improves the adaptiveness until the adaptiveness goal is achieved.

B2-loop: Increase special roles to reduce discomfort

Reducing the number of special roles causes discomfort, thus increases resistance, which keeps up those special roles.

We should ask what our system optimizing goal is. If it is for the adaptiveness but we address the discomfort at the expense of it, we lose the plot, as described in the article of "local optimization and system optimizing goal". The discomfort is the secondary concern, and it should be addressed in other ways.

In LeSS, there is a guide called "Job safety but not role safety". Managers and specialists should not have role safety, and we should not keep those special roles simply for them to feel safe.

More than ten years ago, while I was working in Nokia Networks, the organization experienced a major redesign. As a result, the PMO was dissolved. It was clear that the project manager role would be gone. I was one of the project managers, and ready to leave the organization. However, even though there was no role safety, there was job safety. The organization tried the best in helping the people adapt. Luckily - one of my life-changing moments in retrospect - I changed my role and stayed in the new organization.

Inevitably, some people would choose to exit, while we should focus on the people who choose to stay and take up the change, and help them get through difficulty.

Survival anxiety and learning anxiety

Edgar Schein in his classical book "The corporate culture survival guide" introduced two concepts - survival anxiety and learning anxiety. They are two different types of discomforts.

Survival anxiety is the discomfort that "something bad may happen to you if you don't respond in some way". It creates motivation to change and acts as driving force for the change.

Learning anxiety is the discomfort that "the new behavior that may be required of you may be difficult to learn, and the new beliefs or values that are implied may be difficult to accept". It creates resistance to change and acts as restraining force against the change. 

Seeing system dynamics in organizational change cn - 5.2.jpg

R1-loop: Survival anxiety creates motivation to change

Reducing the number of special roles increases survival anxiety, which provides the motivation to learn, thus, increases the learning. Then, the number of special roles could be reduced further.

B3-loop: Learning anxiety creates resistance to change

However, reducing the number of special roles increases learning anxiety too, which raises the fear, thus, increases the resistance. Then, the resistance keeps up those special roles.

B4-loop: Survival anxiety creates resistance to change

Even though survival anxiety increases the motivation for change, it raises the fear, thus, increases the resistance too. Then, the resistance keeps up those special roles.

The above dynamic is also reflected by two principles about survival anxiety and learning anxiety.

  • Principle one: survival anxiety must be greater than learning anxiety
  • Principle two: learning anxiety must be reduced rather than increasing survival anxiety

The real leverage is to reduce the learning anxiety by providing psychological safety, of which the two most important aspects are:

  • job safety, so that the people have time and space to learn and adapt;
  • learning support, so that the people learn and adapt effectively.

Respect for people

In summary, while we have to remove some special roles, we shall do it in a respectful way.

1. Job safety but not role safety. It is more respectful to clearly and firmly communicate the change than to blur the message.

2. Acknowledge that some people will not take up the change but exit. Be respectful for their decision.

3. Provide strong support for the people who decide to stay and take up the change, and help them learn and adapt in all ways.