#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

Scrum master ทำแค่เนี๊ยะ

Scrum master ทำแค่เนี๊ยะ

เวลามีคนถามว่า Scrum master ทำอะไร แล้วผมตอบว่าทำให้ Scrum เวิร์คสำหรับทั้งองค์กร ซึ่ง โฟกัสหลัก ๆ 4 อย่างก็จะอยู่ที่ Product owner, ทีม, engineering practices และ องค์กร บางครั้งที่ผมจะได้ยินเสียงตอบกลับมาเบา ๆ ว่า “แค่เนี๊ยะ?” ในฐานะ

By Chokchai
how to สร้าง Knowledge Management

how to สร้าง Knowledge Management

ตอนเรียน Large Scale Scrum กับ Jurgen de Smet สิ่งหนึ่งที่ผมได้เรียนรู้ คือ ปัจจัยสำคัญหนึ่งที่ทำให้องค์กรหนึ่ง ๆ จะเร็วขึ้นได้ คือ จะต้องเรียนรู้ไปพร้อม ๆ กันได้ ซึ่งถ้าอยากทำแบบนั้นได้ก็จะต้อง share ownership

By Chokchai
โลกการเขียนโค้ด ตอน ซามูไรกับสปาตั้น

โลกการเขียนโค้ด ตอน ซามูไรกับสปาตั้น

ซามูไรที่ได้รับความไว้วางใจให้แก้ core logic จะมีสัญชาตญาณซามูไร คือแก้ตรงนี้ จับยามสามตาแล้วรู้เลยว่าจะไประเบิดตรงโน้น แล้ววิ่งไปสกัดบั๊กไว้ก่อนความเสียหายจะเกิด (ถ้าเป็นในหนัง ตอนนี้เป็นบทที่บั๊กร้องว่า “มืงรู้ได้ไง?!” :D) หลังจากที

By Chokchai
ประสบการณ์ TDD

ประสบการณ์ TDD

มันมีบางชั่วขณะ ที่ผมอินกับ Test-Driven Development (TDD) มาก จนอยากจะแนะนำทักษะนี้ให้คนเขียนโค้ดทั่วโลกที่สนใจเลย ผมคิดว่า ทักษะนี้มีผลเยอะมาก ๆ กับความรู้ความชำนาญในการเขียนโค้ดของผมทุกวันนี้ แต่ที่ผมไม่เคยอธิบายเป็นคำพูดออกมาได้คือ ทำไมนะ? เมื่อเช้าตอนกำลังอ่านเกี

By Chokchai