Revisit feature team - cont'd

Two years ago, I wrote a blog article called "Revisit feature team". I felt not quite complete, thus, the thought went on, until I discovered what was missing recently.

Collective ownership

Let me recap the scenario here. There is one so-called feature team, in which small groups work on different features. The team is stable, while those small groups are dynamic, as shown in the below picture.

Blog - revisit feature team 1.jpg

Within those small groups, they take collective ownership for delivering the feature. However, as the big team, they do not take collective ownership for all features. Therefore, it is not a real team. To make it a real team, it must take the whole-team approach, meaning that the whole team takes shared responsibility to deliver all features, as shown in the below picture.

Blog - revisit feature team 2.jpg


What does the whole-team approach mean in practice? How is it different from the above scenario?

Resilience and Overhead

Let's understand more about the whole-team approach from Scrum.

Blog - revisit feature team 3.jpg

Think about a team with 5 features to deliver in one sprint. A good team does not work on all features in parallel, but they may still work on a couple of features in parallel, as shown in the above picture. Are A1/A2/A3 and A4/A5/A6 also small dynamic groups in the team? Yes and no.

Yes in the sense that A1/A2/A3 working on feature 1 collaborate more closely and learn more details on that feature. They are more strongly connected on those days, during which they are working on the same feature.

No in the sense that the whole team learns about all features in the backlog refinement and planning, and every member inspects the progress in the daily scrum and is ready to jump in.

On one hand, we want to create resilience, so as to take advantage of the whole team's skill and capacity to deliver high-priority features. On the other hand, we want to have reasonable amount of overhead, as everybody in the team would spend effort in learning a bit more than what he/she absolutely and immediately needs.

Blog - revisit feature team 4.jpg


B1-loop: Increase the team size for more resilience

The bigger team, the more people who could swarm, the more resilient we are as a team.

B2-loop: Decrease the team size for less overhead

The bigger team, the more people who prepare themselves to swarm, the more overhead there is, till the point where we could not afford any more.

It is the team size that balances these two factors. In my experience, the sweet spot for team size is usually 5-7 people. A team of 3 people does not create sufficient resilience, while a team of 10 people brings too much overhead.

Two alternatives

What are alternatives than what is in the original scenario - one big feature team, in which there are small dynamic groups on various features?

1. Split the big feature team into 2 small feature teams, as shown in the below picture.

Blog - revisit feature team 5.jpg


This alternative was suggested in my previous blog article. This is straightforward.

2. Keep one big feature team, in which there are small dynamic groups on various feature sets, as shown in the below picture.

Blog - revisit feature team 6.jpg


This differs from what is in the original scenario, in that the dynamic group is on feature set, rather than on one feature. This creates more balance between resilience and overhead. The collective ownership happens in those medium-sized feature groups, while the stability is kept in the big feature team.

It is indeed more complicated than the first alternative, then does it bring in any advantage? It avoids to force splitting the related work into two teams. It is more cohesive for one group to take all related work. This is essentially the same argument as whether it is good for timebox to force splitting the related work into two sprints.

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