September 2018 Archives

#backlogs - the ultimate lever

#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 found that these two were just the different applications of the same lever, which is #backlogs. Please be noted that backlogs here are all kinds, including product backlog, team backlog, individual backlog, etc. Some are explicit, and the other are 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 find many backlogs, there are two kinds.

  1. Parallel/independent backlogs 

#backlogs is the ultimate lever 1.jpg

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

The more parallel/independent backlogs, the less adaptiveness.

  1. Sequential/dependent backlogs

 

#backlogs is the ultimate lever 2.jpg

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

The more specialization, the more efficiency and the higher quality. It must be good, right? However, it becomes our constraints over time, and does harm to our agility. When it 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 its consequence.

Having everyone able to do everything is a sufficient but not necessary condition to enable one backlog in the team. Similarly, having every team able to do everything is a sufficient but not necessary condition to enable one backlog in the product. The key is, there should be no constraints when we say that those people or teams have one backlog. Once we could 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 #backlogs and achieve agility.

LeSS or less

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

About this Archive

This page is an archive of entries from September 2018 listed from newest to oldest.

August 2018 is the previous archive.

Find recent content on the main index or look in the archives to find all content.