Number of backlogs and multi-learning: 4) specialized feature team

In this article, we shall look at the structure of specialized feature team, and explore the dynamics around their backlogs, then analyze its impact on the agility and find the lever to optimize for the agility.

#backlogs and multi-learning - article 4.png

Feature team is responsible for delivering customer value from end to end, thus, 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 its own backlog. They are responsible for different customer domains, thus, specialized feature teams. Those work in different backlogs are independent of one another.

More backlogs for efficiency

Let's still ask the question of why having multiple backlogs for feature teams. The answer again lies at the efficiency thinking.

#backlogs and multi-learning - article 4.1.jpg

B1-loop: specialization for efficiency

This is the same loop as the one you have seen in the structure of functional team and component team. There is an explicit or implicit efficiency goal. This causes efficiency gap, leading to more backlogs, more specialization, higher efficiency, which reduces the gap.

However, here is a different type of specialization. Instead of specializing on function for functional team and on component for component team, feature team specializes on customer domain. This creates the different impact.

The "unintended" impact on adaptability

As feature team can deliver customer value independently, thus, having more backlogs won't have direct impact on e2e cycle time. The unintended impact is on adaptability.

#backlogs and multi-learning - article 4.2.jpg

In the upper part of the diagram, there are 3 causal links from #backlogs to adaptability.

  1. More backlogs, lower transparency, less motivation to respond to change, lower adaptability.
  2. More backlogs, stronger local identity, less motivation to respond to change, lower adaptability.
  3. More backlogs, more specialization, narrower knowledge breadth, lower adaptability.

All of them indicates that having more backlogs leads to lower adaptability.

In order for higher adaptability, we need to:

  1. increase transparency so that we see the need to adapt
  2. reduce silos associated with local identity so that we are willing to adapt
  3. increase knowledge breadth so that we have the skill to adapt

Multi-learning for fewer backlogs

Let's see how to drive toward fewer backlogs in the context of feature teams.

#backlogs and multi-learning - article 4.3.jpg

R1-loop: fewer backlogs drives broad learning

More backlogs, more specialization, narrower knowledge breadth. Then, the narrow knowledge breadth becomes the cause for more backlogs, and it creates a reinforcing R1-loop. It is easier to work in the direction of more backlogs, how could we turn this around?

Take the same reinforcing loop and make it like this - fewer backlogs, less specialization, broader knowledge breadth, even fewer backlogs... The challenge is that less specialization does not lead to broader knowledge by itself. We need multi-learning to increase the knowledge breadth.

Fewer backlogs drives multi-learning; multi-learning enables fewer backlogs. They are mutually reinforcing. Therefore, the number of backlogs itself is an important lever - have one backlog for multiple feature teams.

The above analysis is exactly the same as the one for functional team and component team. What are the differences here? The knowledge breadth here is about customer domain, rather than function or component. The backlog here is product backlog, rather than functional or component backlog. The multi-learning here is cross-domain learning, rather than cross-functional or cross-component learning.

What are the techniques to do cross-domain learning? LeSS provides a guide about multi-team PBR. This is the key practice for any feature team to learn broadly about as many items as desirable from the same product backlog. In fact, when you start the adoption, it is recommended to do all-team PBR by default, in order to maximize the learning. During multi-team PBR, instead of having different feature teams refine different items, we create mixed groups with people from different feature teams, and have them refine different items. They diverge and merge to get the maximum cross-domain learning among those feature teams sharing one product backlog.

In summary, the associated backlogs in feature teams are still for efficiency, but it creates unintended impact on adaptability, rather than e2e cycle time. Cross-domain learning enables fewer product backlogs, while fewer product backlogs in turn drives cross-domain learning.


Let's conclude this series by putting various types of backlogs, specialization and multi-learning together.

#backlogs and multi-learning - article 4.4.jpg

The drive behind having various backlogs is higher efficiency through specialization. They specialize on different things - function, component and customer domain. They create different problems. Functional backlog and component backlog create dependency among them for delivering customer value, thus, they have the most impact on e2e cycle time. While product backlog is independent of one another, it has the most impact on adaptability.

The key lever all lies at multi-learning, though different types of multi-learning. Cross-functional learning enables fewer functional backlogs; cross-component learning enables fewer component backlogs; and cross-domain learning enables fewer product backlogs.

This ends the series - number of backlogs and multi-learning.

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