(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.
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.
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:
RSS feed