By Lv Yi on June 8, 2019 9:44 AM

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.

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

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.

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.

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.