"Maximize dependencies between teams"

This is an interesting quote by Bas Vodde - "we should maximize dependencies between teams". As it seems contradicting with our conventional thinking, we shall elaborate on it in this article.

Independent teams?

Isn't feature team supposed to deliver features independently?

maximize dependencies between teams - 1.jpg

Yes, it is. As illustrated in the above diagram, each feature team develops various items from end to end - team Red for item 3/4/5, team Green for item 1/7/9, and team Blue for item 2/6/8/10. They don't depend upon other teams to deliver those items. In other words, they have separate sprint backlogs.

However, feature teams also seek opportunities to collaborate with one another, as all of them develop the same product and they are not silos. How does it work in practice? Let's look at the below three aspects.

1. Shared backlog

maximize dependencies between teams - 2.jpg

Feature teams share one product backlog. To boost broad learning and increase adaptiveness, we encourage teams to do multi-team PBR (Product Backlog Refinement). Instead of having each team refine specific items, we have multiple teams together refine a group of items, or even all items. In the multi-team PBR, we create the mixed groups consisting of people from different teams, then, make diverge-merge cycles to refine those items. In the sprint planning part 1, feature teams self-organize to agree on which items each team will take, in order to maximize the value delivered in the coming sprint, as well as the learning for sustaining the future value delivery.

2. Shared components

maximize dependencies between teams - 3.jpg

Feature teams share product components. When each feature team develops its selected items independently without collaborating with other teams, chances are they create duplicated work, or the component structure deteriorates. Isn't it supposed to work that way, as we transition from component team to feature team? Not at all. Shared component and component team are two different concepts. LeSS advocates not only feature teams, but also shared components. Feature teams self-organize to create shared components. In the sprint planning part 2, they may discover that they all need to make changes on certain component, thus decide to have a joint design session. They may later form cross-team pairs to implement some changes together. During the sprint, feature teams continuously integrate their work to expose any conflict and collaborate to resolve them earlier.

3. Shared increments

maximize dependencies between teams - 4.jpg

Feature teams share product increments. Sprint review bazaar is a LeSS guide about how to run an effective sprint review. During the sprint review, those stations are usually organized around teams. I find it better to organize them around meaningful increments. Perhaps a set of items form a customer journey, or all contribute to a desired impact. If they are developed by multiple teams, great! Then, relevant teams need to collaborate together, which fosters the whole product view and promotes cross-team learning.

Whole product focus

maximize dependencies between teams - 5.jpg

Putting all these together - although feature teams have their separate sprint backlogs, they share product backlog, product components and product increments. For the good of whole product, the teams need to span their boundaries. This is in line with the case that individuals need to span their boundaries when they form a team. Even though individuals may have different skill levels in various areas, they cross learn and help each other to focus on the whole team. LeSS expands the whole team (one team) focus to the whole product (multiple teams) focus.

In essence, "maximize dependencies between teams" is to encourage collaboration and learning across team boundaries for the whole product focus!

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