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