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

Read more

จักระกับระบบประสาท

จักระกับระบบประสาท

ครูณาส่งหนังสือที่ครูแปล ชื่อ Becoming super natural มาให้ ผมได้ข้อมูลที่ตื่นตาตื่นใจหลายอย่าง หลายอย่างผมก็ยังต้องใช้เวลาค่อย ๆ ทำความเข้าใจไป แต่วันนี้อยากเอาเรื่อง จักระ ทั้ง 8 จุดมาแบ่งปัน จากในหนังสือ ผมได้ลองนั

By Chokchai
Scrum master focus

Scrum master focus

ครั้งแรกที่ผมได้เรียนว่า สกรัมมาสเตอร์ควรแบ่งโฟกัสการโค้ชของตัวเองเป็น 4 เรื่องคือ 1. องค์กร 2. engineering practice 3. product owner 4. ทีม ผมอดคิดไม่ได้ว่าคนบ้าอะไรจะไปเก่งทั้ง 4 อย่างซึ่งมันใช้ความรู้และทักษะที่แตกต่างกันเหลือเกิ

By Chokchai
Community of Practice (CoP) คืออะไร?

Community of Practice (CoP) คืออะไร?

กาลครั้งหนึ่ง… ชมรม Community of Practice (CoP) เป็นคอนเซปต์ที่ถูกกล่าวถึงใน Large Scale Scrum เทียบง่าย ๆ ก็เหมือนชมรมตอนเราเรียน ม. ปลาย นั่นแหละ ใครสนใจเรื่องอะไร ก็ไปเข้าชมรมนั้น แล้วก็ไปทำกิจกรรมร่วมกันในเรื่องที่เราสนใจ เพื่อฝึกฝนและแลกเปลี่ยนความรู้ บางทีอาจจะมี

By Chokchai