Virtually every Team in their first Sprint is confronted with the problem of single-specialization causing work imbalance. What happens? The Product Owner orders the Product Backlog to maximize value. But when the team members are specialized in a single dimension - such as QA, Java development, front-end development - some team members regularly will find themselves with no work related to their area of specialization. Single-specialization inevitably causes work imbalance.

Organizations typically react by applying the following quick-fixes, (1) have people be on more than one team, (2) give additional work to the team, or (3) do work for the next Sprint (e.g. design) or work related to the previous Sprint (e.g. QA). The latter two quick-fixes are easily recognized as they lead to half-done items at the end of the Sprint, often referred to as ‘carry-over’ or ‘spill-over’ work.

Key point: The phrases ‘carry-over’ and ‘spill-over’ are not Scrum. They’re signs of dysfunctional Scrum.

Each of these quick-fixes inhibit well-oiled teams and reinforce responsibility at the level of individual members. For most organizations, Scrum entails a change in teams from individual responsibility (of my area of expertise) to a team-shared responsibility (for all work required to achieve the goal of the Sprint). Scrum makes this explicit by having a role: ‘Team’ – a single role of multiple people, rather than roles of team members.

Shared responsibility through balanced specialization

How do teams resolve the problem of specialization and work imbalance? Although it is up to the team, most teams have members learn and create secondary areas of specialization. This does not mean that all team members become generalists – either single-specialization or generalist is a false dichotomy.

Team behaviors that lead to balanced specialization are:

• Whenever the team has the right expertise for current work, every task is a learning opportunity. Any team member can either pick it up and do individually or request to pair or mob.
• Whenever the team feels there is currently enough learning going on, the tasks tend to be picked up by the team members with the most expertise in them.
• Whenever the team does not have the right expertise for the current work, the team discusses how to gain that knowledge through learning and collaboration.

Implications for organizational structure

Most organizational structures, such as functional departments, functional career paths, or component teams cause single-specialization in either functional skill or technology area. When these structures are kept in place while adopting Scrum, they cause conflicting loyalties. Team members have one loyalty towards their team for their shared work and another loyalty to their organizational unit. The organizational loyalty is involved in performance reviews, promotions, and bonuses and therefore tends to ‘win.’ Shared team responsibility only happens when these traditional single-specialization focused organizational structures are eliminated.

Scrum implies a shift from individual responsibility to shared team responsibility, which in turn implies a change from single-specialization to multi-learning. This can only be achieved by eliminating organizational structures that promote single-specialization. Scrum adoptions by ignorant managers that avoid these changes are likely to lead to pretend-Scrum – the same old with new words.

(Originally published by Lv Yi on June 23, 2019)

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

A feature team is responsible for delivering customer value from end to end. There is only one backlog associated with value delivery, i.e. the whole team shares the work and has one priority. In an organization, however, there are usually multiple feature teams, each having their own backlog. They are responsible for different customer domains, and that is why they are called specialized feature teams. Their backlogs contain mostly independent work.

More backlogs for efficiency

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

B1-loop: specialization for efficiency

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

With feature teams there is a different type of specialization. Instead of specializing in a function or a component, a feature team specializes in a customer domain. This creates a different impact.

The “unintended” impact on adaptability

Since feature teams can deliver customer value independently, having more backlogs won’t have direct impact on e2e cycle time. But there is an unintended impact on adaptability - ability to change direction.

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

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

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

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 drive broad learning

More backlogs lead to more specialization and narrower knowledge. The narrow knowledge, in turn, becomes the cause for more backlogs, thus creating a reinforcing R1-loop. It is easier to work in the direction of increasing the number of backlogs, how could we turn this around?

Take the same reinforcing loop and read it as follows: fewer backlogs, less specialization, broader knowledge, 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 drive 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 and component teams. What are the differences here? Here, the knowledge breadth is about customer domains, rather than functions or components. The backlog is product backlog, rather than functional or component backlog. The multi-learning is cross-domain learning, rather than cross-functional or cross-component learning.

What are the techniques for doing 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 an adoption, it is recommended to do all-teams 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 maximum cross-domain learning among feature teams sharing one product backlog.

In summary, the backlogs associated with feature teams are still there for efficiency. But the unintended impact is 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.

Backlog	Specialization	Multi-learning
Functional backlog	Function	Cross-functional
Component backlog	Component	Cross-component
Product backlog	Customer domain	Cross-domain

 

The driver for having multiple various backlogs is the desire for higher efficiency through specialization. Teams specialize in different things: functions, components and customer domains. It creates different problems. Functional and component backlogs create dependencies for delivering customer value, thus, they have the most impact on e2e cycle time. While independent product backlogs for feature teams has the most impact on adaptability.

The key lever for all lies in 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 about the number of backlogs and multi-learning.

(Originally published by Lv Yi on June 21, 2019)

In this article, we shall look at a variant of the functional team and component team structures - a feature group. We shall revisit known dynamics of the functional and component teams, and see what’s similar and different between them and a feature group in terms of impact on organizational agility.

A feature group is also called a feature project. It is usually formed to deliver some special customer value by picking people from various functional and component teams. Each member has their own work and priority, thus their own backlog. This is similar to the functional team and component team structure where all the work needed for value delivery is in multiple interdependent backlogs. The difference is who is responsible for specific backlogs, teams or individual members of a feature group.

Feature group

Let’s start with the diagram for a functional team and component team structure, and understand how it applies in the context of a feature group.

Individual responsibility

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

B1-loop: specialization for efficiency

The functional or component specialization is good for efficiency. Except that now it is 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 a strong local identity with their speciality. It hurts collaboration and leads to 1) increased integration effort, thus lower efficiency, and 2) increased integration time, thus longer e2e cycle time.

The feature group could reduce silo thinking by developing a common identity in addition to local identity. Something like: “You belong to this ‘team’ (feature group), nevertheless, you still do the work in your speciality only.”

Cycle time

In organizations with functional and component team structure, related parts may be done in 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 and waiting is confined to one sprint. The longest e2e cycle time would be one sprint. This also lessens the problem below .

R3-loop: Rework hurts efficiency

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

Specialization

R1-loop: Over-specialization hurts collaboration

Over-specialization is still there when members have their own backlogs (B1-loop). The resulting narrow knowledge continues to hurt collaboration, and creates unintended impact on efficiency.

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

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 with ensuing multi-tasking and associated context switching cost.

R5-loop: Multi-tasking hurts efficiency

More backlogs lead to more multi-tasking, which lowers efficiency. In other words, multi-tasking creates another unintended impact on efficiency.

2) Temporary group

Group members will change according to the amount of specialized work needed. Thus the group becomes a temporary group.

R6-loop: Group instability hurts collaboration

More backlogs lead to a less stable group. The feature group consists of people who are able to work on various backlogs. More backlogs, more changes the group is likely to endure. It takes time for any group to jell and become effective. Temporary groups tend to have low collaboration levels, and it is very hard to introduce and sustain any improvements. Thus, group instability creates another unintended impact on efficiency.

In summary, the feature group has the same main dynamics and problems as the functional and component teams with additional problems related to multi-tasking and group stability. However, a feature group may have a strong 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 a feature group and a feature team. A real feature team has only one backlog, and members take shared responsibility.

R4-loop: fewer backlogs drive broad learning

A feature team may also start with multiple implicit backlogs due to skills constraints. But one explicit backlog drives multi-learning and reduces the number of implicit backlogs over time. On the other hand, a feature group accepts the status quo and keeps multiple backlogs forever.

Having one backlog removes the need for partial allocation and temporary groups. With dynamic requirements, which is very common, the effort needed in various functions and components will still change, and there will still be a mismatch between work and skills. 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 practice (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, a feature group becomes a feature team.

(Originally published by Lv Yi on June 12, 2019)

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

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

More backlogs for efficiency

Let’s step back and first ask the question: why more backlogs? The answer lies in “efficiency thinking”.

B1-loop: specialization for efficiency

Organizations have either an explicit or implicit efficiency goal. The difference between this goal and reality causes an efficiency gap. Creating more backlogs, leads to specialization and, it theory, to higher efficiency, which reduces the gap.

Higher efficiency should also lead to shorter touch time (i.e. the time used to process the work in a function or a component), thus, shorter end-to-end cycle time. However, we need to understand what percentage touch time accounts for in the whole e2e cycle time, and to see a bigger picture.

The “unintended” impact on cycle time

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

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

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

Even though having more backlogs may lead to shorter touch time, 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.

The “unintended” impact on efficiency

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

The level of collaboration is one commonly overlooked factor. A unit of work does not stand alone, but needs to be integrated with other units. Integration requires collaboration with others. Thus, the level of collaboration affects both time and efficiency. Let’s see which dynamics create negative effects on collaboration.

R1-loop: Over-specialization hurts collaboration

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

R2-loop: Local identity hurts collaboration

More backlogs leads to stronger local identity, which means that one group only works on a specific function or component, while another group is not allowed to touch it. These are functional and component silos, and they hurt collaboration. This both decreases efficiency and worsens the integration time, thus even longer e2e cycle time.

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

R3-loop: Rework hurts efficiency

When work is done asynchronously, hidden problems are commonly discovered during integration and often require redoing parts that were considered complete. So, the rework caused by the asynchrony (i.e. low level of synchronization), which is caused by having different backlogs, decreases efficiency. This creates the R3-loop.

Overall, B1-loop aims to increase efficiency, but it creates unintended consequences on collaboration and rework and worsen the e2e cycle time. B1-loop and R1..R3-loop form the system archetype called “fixes that backfire”.

Multi-learning for fewer backlogs

Let’s see how to drive toward fewer backlogs.

R4-loop: fewer backlogs drive broad learning

More backlogs lead to more specialization and narrower knowledge. Then, the narrow knowledge becomes the cause for more backlogs creating 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 read it like this: fewer backlogs, less specialization, broader knowledge, 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 mean by multi-learning? The backlogs are based on functions and components here, thus, we do cross-functional and cross-component learning.

What are the techniques enabling cross-functional and cross-component learning? 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 practice (both functions and components)
• component mentor
• current-architecture workshop
• multi-team design workshop

In summary, separate backlogs for functional and component teams are created for higher efficiency, but they create unintended negative impact on the overall e2e cycle time, and even worse, overall efficiency itself. Multi-learning enables fewer backlogs, while fewer backlogs in turn drives multi-learning and improves delivery capability.

(Originally published by Lv Yi on June 8, 2019)

This is the first article in a series about “number of backlogs and multi-learning”. It introduces three common team structures in product development organizations.

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. Agility is delivering the highest customer value in an uncertain environment. With uncertainty, the ability to deliver is not sufficient. We need the ability to inspect and adapt in order to deliver the highest customer value. We may inspect and find that the market has changed. We embrace the change and make the necessary adaptation, then we can deliver 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.

• Inspectability

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

• Adaptability

  The ability to adapt is the ability to change 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 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.

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 overall agility and find the lever to optimize for agility.

2. Feature group

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

The above picture is actually the same as the one for functional 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 may share one backlog for some functions or components, but the structure remains the same. In the third article, we shall revisit the dynamics within the functional team and component team, and see how much similarity and difference a feature group has with them, in terms of its impact on the agility and the lever.

3. Specialized feature team

A feature team is responsible for delivering customer value from end to end. 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 their own backlog. They are responsible for different customer domains, hence specialized feature teams. Work items in different backlogs are independent from one another.

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 (this one)
2. functional and component team
3. feature group
4. specialized feature team