Project Management 101 EP.10 — 50+ คน: SAFe / LeSS / Conway's Law

📚 EP นี้เป็นตอนที่ 10 ของ mini-series Project Management 101 — สารบัญรวม อยู่ที่นี่

50 คนขึ้นไป — Scrum หนึ่งทีมไม่พอ ต้องประสาน หลายทีมพร้อมกัน

ตอนนี้พูดเรื่อง:

กฎพื้นฐาน ที่ทำไม scale ทีมยาก — Brooks’ Law + Conway’s Law
Scaled Frameworks ที่บริษัทใหญ่ใช้ — SAFe, LeSS, Spotify, Nexus

ก่อนอื่น: Brooks’ Law — ทำไมเพิ่มคนไม่ช่วย#

Fred Brooks เคยจัดการ IBM OS/360 ตอน 1960s (EP.01 เล่าประวัติ)

หนังสือ The Mythical Man-Month (1975) มี quote ที่อมตะ:

“Adding manpower to a late software project makes it later.”

ทำไม? 3 เหตุผล:

1. Communication overhead = n × (n-1) / 2#

คนในทีม	Channels การสื่อสาร
2	1
5	10
10	45
20	190
50	1,225
100	4,950

เพิ่มคน 1 คน = เพิ่ม channel หลายเส้น

2. Onboarding time#

คนใหม่ต้อง:

เรียนรู้ codebase
เรียนรู้ business domain
เรียนรู้ team norm

ระหว่างนั้น คนเก่าต้องสอน = productivity ของคนเก่าลด

ทีม 10 คน + คนใหม่ 1 = ปกติเพิ่ม productivity ไม่ใช่ 10% — บางทีลบ 10% ใน 2-3 เดือนแรก

3. Sequential constraint#

บางงาน ขนานกันไม่ได้ — ต้องทำเรียง

“The bearing of a child takes nine months, no matter how many women are assigned.”

(การคลอดลูกใช้ 9 เดือน ไม่ว่าจะใส่ผู้หญิงกี่คน — บางงาน parallel ไม่ได้)

Implication#

เมื่อ project ช้าอยู่แล้ว:

เพิ่มคน → onboarding ดูด productivity คนเก่า
Communication overhead เพิ่ม
ส่วน critical path ที่ sequential — เพิ่มคนไม่ช่วย

สรุป: เพิ่มคนกับ project ที่ late = late ขึ้น

ทางออก: Re-scope, cut feature, หรือ accept delay — ไม่ใช่ throw bodies

Conway’s Law — โครงสร้างทีมกำหนดโครงสร้างระบบ#

Origin: Melvin Conway, 1967

กฎ:

“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”

ภาษาคน: ถ้าบริษัทมี 4 ทีม build compiler → จะได้ 4-pass compiler (จะเหมาะหรือไม่)

ตัวอย่าง real life#

Microsoft Windows ยุค 90s:

มี 8+ ทีมแยกกัน build OS
ผลลัพธ์: 8 subsystems ที่ integrate ยาก
Windows Me = nightmare ของ integration

Amazon ตอนเปลี่ยนเป็น microservices (2002):

Bezos สั่ง: “All teams will henceforth expose their data and functionality through service interfaces”
Re-org เป็น two-pizza teams (6-10 คนต่อทีม)
ผลลัพธ์: AWS, microservices architecture, scale ได้

Inverse Conway Maneuver#

ถ้า Conway’s Law บอกว่า org structure → system structure…

กลับด้าน: ถ้าอยาก system architecture แบบไหน — re-org team ตาม

ตัวอย่าง:

อยาก microservices → break เป็น small autonomous teams
อยาก mono-architecture → centralize team
อยาก decoupled API → ทีมต้อง decoupled communication

หลายบริษัทใช้ Inverse Conway Maneuver ตอน digital transformation

ทำไม Scrum หนึ่งทีมไม่พอ#

ทีม Scrum 9 คน → ปกติ build feature ที่ shippable ทุก 2 อาทิตย์

แต่ enterprise ต้องการ:

10+ ทีมทำงานพร้อมกัน
Cross-team dependencies เยอะ
Architecture ระดับสูงต้อง coordinate
Roadmap หลายไตรมาส
Compliance / regulator
Budget annual cycle

→ ต้องการ scaled framework

SAFe — Scaled Agile Framework#

Origin: Dean Leffingwell, 2011

ที่ใช้กัน: บริษัทใหญ่ enterprise ส่วนใหญ่ — Cisco, AT&T, Lockheed Martin, Standard Chartered

โครงสร้าง SAFe (Essential SAFe)#

1
Portfolio Level — strategy + budget
2
       │
3
       ▼
4
Program / ART (Agile Release Train) — 50-125 คน
5
       │
6
       ├── Team 1 (Scrum) — 9 คน
7
       ├── Team 2 (Scrum) — 9 คน
8
       ├── Team 3 (Scrum) — 9 คน
9
       └── ... 5-12 ทีม

Concept หลัก: Agile Release Train (ART)#

ART = กลุ่มของ 5-12 ทีม Scrum ที่ทำงานสอดคล้องกัน — ส่งมอบ value ทุก 8-12 อาทิตย์ (Program Increment / PI)

PI Planning — event ที่ใหญ่ที่สุด#

ทุก 8-12 อาทิตย์ — ทุกคนใน ART (50-125 คน) มาประชุมพร้อมกัน 2 วัน:

Plan ของ PI ถัดไป
Identify dependency ข้ามทีม
Risk discussion
Confidence vote

ฟังดู massive — คือ massive จริง บริษัทใช้เงินส่ง 100 คนมาประชุมทุก 2 เดือน

Roles ใน SAFe#

Release Train Engineer (RTE) — Scrum Master ของ ART
Product Manager — เจ้าของ vision (ไม่ใช่ PO ของทีมเดียว)
System Architect — technical direction ระดับ ART
Business Owner — accountable ต่อ business outcome ของ ART

SAFe ข้อดี#

✅ Scale ได้จริง — proven in 1000+ enterprise
✅ Bridge between Agile + traditional governance
✅ Career path ชัด (มี certification ladder)
✅ Compliance friendly

SAFe ข้อด้อย#

❌ Heavy — มี role + ceremonies เยอะ
❌ Critics เรียก “Scaled Waterfall” — เพราะ PI Planning ทุก 12 อาทิตย์ = pseudo-waterfall
❌ Bureaucracy เกิดง่ายถ้าไม่ระวัง
❌ Certification ราคาแพง — 5-figure USD

LeSS — Large-Scale Scrum#

Origin: Craig Larman + Bas Vodde, 2014

Philosophy: Descale before scaling — Scrum ที่ใหญ่ขึ้น โดยเพิ่มอะไรน้อยที่สุด

โครงสร้าง LeSS#

1
1 Product → 1 Product Owner → 1 Product Backlog
2
       │
3
       ├── Team 1 (Scrum)
4
       ├── Team 2 (Scrum)
5
       └── ... 2-8 ทีม

ทุกทีม:

ใช้ backlog เดียวกัน
Sprint sync กัน
Sprint Review รวมกัน

LeSS Huge#

สำหรับ 8+ ทีม:

เพิ่ม “Area Product Owner” สำหรับแต่ละ area
Backlog ใหญ่ split เป็น area แต่เป็นของ PO เดียวยังคง

LeSS ข้อดี#

✅ Minimal overhead — เพิ่มแค่ที่จำเป็น
✅ Scrum-purist friendly
✅ ราคาถูก (ไม่มี certification mafia)

LeSS ข้อด้อย#

❌ ยากที่ enterprise ใหญ่ๆ จะ adopt — ต้อง re-org
❌ Communication overhead ระหว่างทีมยังเยอะ
❌ ไม่มี vendor backing — community-driven

Spotify Model#

Origin: Henrik Kniberg’s 2012 whitepaper / video

โครงสร้าง#

1
Squad (6-12 คน) — autonomous team, like Scrum
2
   │
3
   ├── grouped into Tribe (40-150 คน) — product family
4
   │
5
   ├── Chapter — same specialty across squads
6
   │     (e.g., all backend engineers across squads)
7
   │
8
   └── Guild — cross-tribe community of interest
9
         (voluntary, e.g., "AI Guild")

หมายเหตุที่สำคัญ#

Spotify เองไม่ใช้แบบนี้แล้ว! มันเป็น snapshot ปี 2012 — ไม่ใช่ framework

หลายบริษัทเอาไปใช้: ING (Netherlands), ANZ Bank, Capital One — ผลลัพธ์ผสม

Lesson: อย่า copy แบบ blind — ดู context ของบริษัทเอง

Nexus#

Origin: Ken Schwaber (ผู้ร่วมสร้าง Scrum), 2015

Concept: Scrum ที่ scale 3-9 ทีม โดยเพิ่ม Integration Team กลาง

1
Nexus (3-9 ทีม)
2
   │
3
   ├── Nexus Integration Team (NIT)
4
   │     - Resolve integration issue
5
   │     - Cross-team dependency
6
   │
7
   ├── Team 1
8
   ├── Team 2
9
   └── ... up to 9

ข้อดี#

✅ Scrum-purist friendly เหมือน LeSS
✅ Lightweight — เพิ่มแค่ NIT
✅ Free guide จาก Scrum.org

ข้อด้อย#

❌ ไม่ค่อยมีใครใช้ — มี community เล็กกว่า SAFe / LeSS

Disciplined Agile (DA)#

Origin: Scott Ambler, ~2015 (acquired by PMI 2019)

Philosophy: Toolkit ของ practices — ไม่บังคับใช้ตามเฉพาะ — ผสมเอาที่เหมาะ

DA แตกต่างเพราะ:

ไม่ prescriptive (ไม่บอกว่าต้องทำตาม X, Y, Z)
Process Goal-driven — มี goal กว่า 200 อันให้เลือก
Hybrid by design

ใช้เมื่อ#

บริษัทที่อยู่ระหว่าง Scrum + traditional
ต้อง compliance หนัก

เปรียบเทียบ Scaled Frameworks#

	SAFe	LeSS	Spotify	Nexus	DA
Adoption	สูงสุด	ปานกลาง	สูง (แต่ดัด)	ต่ำ	ต่ำ-ปานกลาง
Prescriptive	สูง	ต่ำ	ต่ำ	กลาง	ต่ำสุด
Cost	สูง (cert)	ต่ำ	ฟรี	ต่ำ	ปานกลาง
Best for	Enterprise (1000+)	Mid-large	Tech native	Mid (3-9 teams)	Hybrid org
เริ่มยาก/ง่าย	ปานกลาง (เยอะ role)	ยาก (ต้อง descale)	ง่าย (copy template)	ง่าย	ปานกลาง

ทำไม “Scaled” framework ถึงมี backlash#

Critics บอก (บางส่วน):

SAFe = “Agile theater” — มี ceremony เยอะแต่ value น้อย
Spotify Model = ไม่เคย work ที่ Spotify — ทำไมที่อื่น work?
Bigger framework = bigger bureaucracy

Counter argument:

Enterprise scale มี constraint จริง — Scrum-pure ใช้ไม่ได้
ต้องมี structure บางอย่าง

ผลลัพธ์: บริษัทใหญ่ส่วนมาก — adopt SAFe ส่วนหนึ่ง + ปรับให้เหมาะกับบริษัทเอง

Inverse Conway: ตัวอย่างจริง#

Amazon (2002 onwards):

Bezos memo: ทุกทีมต้อง expose service via API
ทีมเล็กเป็น two-pizza
ผล: AWS เกิดขึ้น (ก็คือ infrastructure ของ Amazon ที่ “ขายเป็น service”)

Netflix:

Re-org เป็น “service-oriented” team
Each team owns service end-to-end
ผล: microservices architecture ที่ resilient + scalable

Banking digital transformation:

ออก team ใหม่ ๆ ใน “tribes” (mortgage tribe, payment tribe)
แต่ละ tribe = end-to-end ownership
ผล: API-driven banking (open banking)

When NOT to scale#

ก่อนเลือก scaled framework — ถามก่อน:

1. ทีมเดียว 9 คน ส่ง product ครบไหม?

ถ้าได้ — อย่าเพิ่มทีม
“Single team” ดีที่สุด ถ้า product ขนาดพอ

2. Decompose product เป็น independent products ได้ไหม?

ถ้าได้ — แตกเป็น 2 products → 2 PO → 2 single-team
ดีกว่า 2 ทีม coordinate

3. ทีมข้าม dependency ได้บ่อยแค่ไหน?

ถ้าน้อย — Nexus/LeSS-like พอ
ถ้าเยอะ — SAFe หรือ re-architect product

Quote ที่เก็บได้:

“Scale is the cost of complexity. Reduce complexity first.”

สรุป EP นี้#

กฎพื้นฐาน:

Brooks’ Law: เพิ่มคนกับ project ที่ late = late ขึ้น
Conway’s Law: org structure → system structure
Inverse Conway: ออกแบบ org ตาม system ที่อยากได้

Scaled Frameworks:

SAFe — heavy, popular, enterprise — ART + PI Planning
LeSS — minimal, Scrum-pure — descale before scale
Spotify Model — squads + tribes (Spotify ไม่ใช้แล้ว)
Nexus — Scrum 3-9 ทีม + Integration Team
Disciplined Agile — toolkit, not prescriptive

Lesson:

Scale = cost — descale before scale
Single team ดีที่สุด ถ้าได้
Scaled framework ทุกตัวมี trade-off

EP ต่อไปจะเปรียบเทียบ Waterfall vs Agile vs Hybrid — เลือกอะไรในบริบทไหน