Number of backlogs and multi-learning: 2) functional team and component team

In this article, we shall look at the structure of functional team and component 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 2.png

Functional team is responsible for functional work such as analysis, design, implementation, and testing. Component team is responsible for the implementation of various components, such as component A, B and C. Each team has its own work and priority, thus, its own backlog. For the value delivery, it requires the work in multiple backlogs, and they are dependent on one another.

More backlogs for efficiency

Let's step back and first ask the question of why having more backlogs. The answer lies at the efficiency thinking.

#backlogs and multi-learning - article 2.1.jpg


B1-loop: specialization for efficiency

There is an explicit or implicit efficiency goal. This causes efficiency gap, leading to more backlogs, more specialization, higher efficiency, which reduces the gap.

Relatedly, higher efficiency leads to shorter touch time (i.e. the time used to process the work in function or component), thus, shorter cycle time. However, we need to understand how much percentage touch time accounts for in the whole e2e cycle time, and see the bigger picture.

The "unintended" impact on cycle time

Let's see more factors having impact on cycle time.

#backlogs and multi-learning - article 2.2.jpg

In the upper part, more backlogs, more parts for integration, longer integration time, longer e2e cycle time.

In the lower part, more backlogs, lower level of synchronization (different parts are being worked on at different times), which leads to: 1) more rework, thus, more rework time; 2) longer waiting time. In both cases, longer e2e cycle time.

Even though having more backlogs may lead to shorter touch time, many other factors create negative effects on the whole cycle time. It is often the case that touch time is not the most significant part, while waiting and integration account for much more. Then, overall, more backlogs leads to longer e2e cycle time.

The "unintended" impact on efficiency

Let's return to the efficiency. As we analyzed earlier, it is the efficiency goal that drives toward more backlogs. Now we shall see the unintended impact on efficiency.

#backlogs and multi-learning - article 2.3.jpg

Level of collaboration is the commonly overlooked factor. The unit does not stand alone, but needs to integrate with other units. The integration requires to collaborate with others, thus, the level of collaboration affects both time and efficiency. Let's see a few dynamics that create negative effects on collaboration.

R1-loop: Over-specialization hurts collaboration

More specialization leads to narrower knowledge breadth. The knowledge breadth is important for collaboration. In fact, the overlap in knowledge among collaborators helps a lot on the mutual understanding. The narrow knowledge breadth on one hand decreases efficiency, thus, creates the R1-loop; on the other hand, it creates more negative effect on integration time, thus, even longer e2e cycle time.

R2-loop: Local identity hurts collaboration

More backlogs leads to stronger local identity, which means that our group only works on this function or component, as well as other group is not allowed to touch it. These are functional and component silos, and they hurt collaboration. This both decreases efficiency, thus creates R2-loop and worsens the integration time, thus even longer e2e cycle time.

Another dynamic comes from the rework, which creates negative effect on efficiency.

R3-loop: Rework hurts efficiency

The rework caused by the asynchrony (i.e. low level of synchronization), which is caused by having different backlogs, decreases efficiency. This creates R3-loop.

Overall, B1-loop aims to increase efficiency, while it creates unintended consequence on collaboration and rework. B1-loop and R1..R3-loop form the system archetype of "fixes that backfire". In the meantime, these effects on collaboration and rework worsen the e2e cycle time.

Multi-learning for fewer backlogs

Let's see how to drive toward fewer backlogs.

#backlogs and multi-learning - article 2.4.jpg


R4-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 R4-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 by creating a real cross-functional and cross-component feature team.

What do we multi-learn? The backlogs are based on functions and components here, thus, we do cross-functional and cross-component learning.

What are the techniques to do cross-functional and cross-component learning? The below is a list of well-known techniques, and many of them are in LeSS guides.

  • specification by example
  • collective code ownership
  • pair/mob programming
  • communities of practices (both functions and components)
  • component mentor
  • current-architecture workshop
  • multi-team design workshop

In summary, the associated backlogs in functional and component teams are for efficiency, but they create unintended impact on e2e cycle time, and even worse, the efficiency as well. Multi-learning enables fewer backlogs, while fewer backlogs in turn drives multi-learning.

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