(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

(Originally published by Lv Yi on Sep 22, 2018)

The number of 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 realized that these two were just different applications of the same lever, which is the number of backlogs. Please note that backlogs here include all kinds: product backlog, team backlog, individual backlog, etc. Some are explicit and others maybe be 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 have many backlogs, there are two kinds:

1. Parallel/independent backlogs

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

The more parallel/independent backlogs, the less adaptiveness.

2. Sequential/dependent backlogs

This is the case when each component team specializes in one technical domain and has their own backlog. What if the feature requires a 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 the cycle time. Eventually it harms 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 a backlog for each customer domain? We want specialization in the customer domain. Why do we create a backlog for each technical domain? We want specialization in the technical domain.

The more specialization, the more efficiency and the higher quality. It must be good, right? However, it becomes a constraint over time, and harms our agility. When this 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 the consequences.

Having everyone able to do everything is a sufficient, but not a necessary condition to enable one backlog for a team. Similarly, having every team able to work on any feature is a sufficient, but not a necessary condition to enable one backlog for a product. The key is, there should be no constraints when we say that people or teams have one backlog. When we can 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 the number of backlogs and to achieve agility.

LeSS or less

How much specialization is over-specialization? 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 the number of backlogs, we increase agility. Indeed, the number of backlogs is the ultimate lever.

The Essence of Scrum

Unfortunately, many so-called Scrum adoptions keep missing the essence of Scrum. They are too preoccupied with the mechanics of Scrum; process, roles, meetings, and certifications. Or, even worse, they are obsessed with non-Scrum practices such as stories, points, velocity, task boards, or product boxes.

What is then the essence of Scrum?

To me, the essence of Scrum is a simple idea. There is a customer who has a problem that is worth solving and that can probably be solved by developing a product. To help that customer, we put together a team of people who together have or can acquire the skills needed to build that product. This team interacts directly with the real customer to better understand the problem. Together, the customer and the team, decide on the most important first steps in solving the larger problem. The team develops a small, usable product in a short, fixed time to take that first step, solving a small part of the problem. Having reached the end of that first period in time, the team reflects on how they worked and determines how to improve that. The team and customer play with what was created and together choose the best next step. Off they go. This cycle continues until there is no more problem to solve.

The Scrum mechanics have been created to make this simple idea concrete and practical. But successful Scrum adoptions concentrate on the essence more than on the mechanics.

Why is this important?

Most Scrum adoptions would improve by continuously reminding themselves of the essence of Scrum. Is adopting a certain practice going to help us achieve the purpose of Scrum? Regularly asking that question can prevent a team from chasing hypes and instead pursue satisfied customers.

Remaining focused on the essence is even more important in large, complex environments. Especially today when all hype and fancy terminology is aggregated in a large complex scaling frameworks: SAFe. The aim is to integrate everything called agile into one enterprise solution. It includes process, roles, stories, and velocities and expanded the market for resume-improving certifications. But… does it achieve the essence?

(this article is part of the upcoming “97 Things every Scrum practitioner should know” by Gunther Verheyen (editor))

When applying Scrum to a product with more than one Development Team, there is really little guidance in the Scrum Guide. The Scrum Guide seems focused on one-team Scrum for the most part. The only hint you get is in the Product Backlog section:

Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product. A Product Backlog attribute that groups items may then be employed. (Scrum Guide November 2017)

We learn that, with multiple teams, we are advised to still use a single Product Backlog. Nothing is mentioned regarding the roles of Product Owner, Development Team, or Scrum Master other than “multiple Scrum Teams” working on the same product.

But how do you decide over priorities? If we take the Scrum Guide literally, there could be more than one Product Owner in each of the Scrum Teams on that product, or it could be the same person for all the teams involved.

Generally, this is the distinction between “Multiple Scrum Teams” and “Multi-Team Scrum”.

Multiple Scrum Teams

“Multiple Scrum Teams” typically holds that each Development Team has a Product Owner, yet there is a single Product Backlog. That means that potentially different people in the role of Product Owner need to coordinate with each other regarding their individual priorities, and come up with the most valuable items to be worked on.

Sometimes this set-up seems connected to having different specializations in the Development Teams. This works well if the workload on each of the specialist topics is evenly distributed across the different teams - and will stay that way for the near future. If that is not the case (which is highly likely), then one team might end up working on lower-priority, and thus lower-valuable, work for the product, just because that type of work is their specialty.

This setup generally also complicates the transparency of insights into the whole product. Not only is the in-depth knowledge about the product split across the different Scrum Teams, but also across the different Product Owners. After development on particular features has finished, additional coordination is needed on the different partial results of the product in order to have them integrated into a whole product that can be released to the customer and user. Unfortunately a Multiple Scrum Teams setting provides little incentive for cross-team collaboration, since everything will be taken care of by the additional coordination overhead that it produces.

Multi-Team Scrum

In a “Multi-Team Scrum” setting, there is not just a single Product Backlog but also a single Product Owner who works with the multiple Development Teams. The sole Product Owner makes product-wide decisions that are fully transparent via the single Product Backlog, and the product versions created.

This setting demands a cross-functional approach from the teams. Specialization in the customer domain may still happen, but will have to dissolve once priorities and demands start to shift. For example, one team working on accounting functionality will have to shift from accounting features to another type of features if there are no longer any accounting features at the highest priority in the Product Backlog.

This setting therefore lays the demand for coordination with the teams themselves. They have to make sure to deliver an integrated product Increment at the end of every Sprint. Depending on where you start, this may result in a steep learning curve.