Split work and people

How to split work (from big to small) and how to split people (into multiple teams) are two essential and very related topics in the context of scaling Agile.


In these two dimensions (work and people), there are two common splitting strategies, through component or through feature. This leads to the below diagram.

Split work and people.jpg


Let's dive deep into each quadrant.


  • Component work by Component team
This is the traditional way of working, and strongly related to waterfall development. Feature is split into components via design by architecture group, then developed and (component) tested by component teams, eventually integrated and (system) tested by system testing group. The problems with this strategy are handoff waste, prolonged cycle time, delayed feedback, lack of flexibility, etc.


  • Feature work by Component team(s)
First split from big feature to small features, then split into component tasks is the key idea behind Agile and helps tremendously on the speed and flexibility in value delivery. When related component teams are able to collaboratively deliver the same small feature at the same time, it is quite ok. However, in practice, those component work around same feature is often out of sync, which delays feedback and value delivery. Moreover, this is a systematic problem, and can not be solved by stronger coordination. The deep assumption behind component team structure is that people are most efficient in working on familiar areas, and learning other areas is costly and slow.


I put SAFe into this quadrant, not because SAFe demands component team structure, but because SAFe implementation tends to retain current organizational structure, while component team structure is prevalent in organizations.


  • Feature work by Feature team
Feature team takes feature, and splits into smaller features to deliver. This is great in achieving agility. This systematically addresses the problems with component team. Meanwhile, it has its own challenges such as coordinating in code, maintaining the component integrity, efficient learning, etc. Furthermore, it demands organization (re)design, which usually means more radical change thus is perceived as more risky.


I put LeSS into this quadrant, because LeSS explicitly requires that the majority of teams are feature teams. Organization design is vital in LeSS adoption.


  • Component work by Feature team
This is rarely seen in practice. If you already have feature team, it makes no sense to feed them with component work. Rather feature team will take feature as input and split them into component tasks as part of their development.


Conclusion:


Split work via feature dimension is critical element in Agile adoption, while split teams via feature dimension is critical element in LeSS adoption. This is the place we shall strive for.

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