Chọn phương pháp: Scrum, Kanban, Waterfall, hay Hybrid?

Phần lớn cuộc tranh luận về phương pháp chỉ là tiếng ồn. Một team chọn lấy một thương hiệu, bảo vệ nó suốt nhiều năm, và gần như không bao giờ kiểm tra xem nó có thật sự hợp với công việc đang làm không. Chương này giới thiệu một cây quyết định dựa trên bản chất công việc chứ không dựa trên thương hiệu nào in trên slide tư vấn. Đến cuối chương, bạn sẽ chọn được phương pháp trong 5 phút và giải thích được vì sao.

Khi nào việc chọn phương pháp thật sự quan trọng?

Có ba thời điểm chính.

Khi hình thành một team mới. Một team mới khởi động cần ngay lập tức có nhịp làm việc và bộ artifact đi kèm; chọn sai sẽ tốn cả một quý đầy ma sát trước khi có ai đó dám gọi tên vấn đề.

Khi tổng kết retrospective hàng quý. Đến giữa quý, bạn nhận ra phương pháp đang chống lại công việc - sprint cứ liên tục bị các sự cố cắt ngang, hoặc WIP của Kanban cứ leo thang vì có người đòi sprint demo. Lúc đúng để đổi là biên giới của quý kế tiếp, chứ không phải thứ Hai tuần sau.

Khi cần phối hợp đa team. Khi 3 team cùng làm chung một dự án, các phương pháp phải khớp đủ để planning chung được. Velocity của team này không tương thích với cycle time của team kia.

Nếu team đang ổn định, phương pháp đang chạy tốt, và bản chất công việc không thay đổi, thì đừng đổi phương pháp.

Cái giá khi dùng sai phương pháp là gì?

Có ba kiểu lỗi thường gặp.

Liên tục huỷ ceremony. Standup bị bỏ, retro bị hoãn, planning làm vội. Team đã bỏ phiếu bằng chân để nói rằng phương pháp không hợp; chỉ là chưa ai dám thừa nhận thành lời.

Game phương pháp một cách ngầm. Team mang danh nghĩa chạy Scrum nhưng thực tế thì các card được chuyển cột hàng ngày mà không có biên sprint nào. Họ đang làm Kanban, chỉ khoác thêm một lớp họp.

Đổ lỗi cho phương pháp. "Lỡ ngày là vì Scrum hỏng" / "Không dự đoán được ngày ship vì Kanban quá lỏng". Phương pháp trở thành vật tế thần; còn vấn đề thật sự bên dưới (scope creep, thiếu capacity) thì bị bỏ qua.

Cây quyết định chọn phương pháp như thế nào?

flowchart TB
    Start[Dự án mới bắt đầu] --> Q1{Scope cố định toàn bộ<br/>bởi ràng buộc ngoài?}
    Q1 -->|Có| Waterfall[Waterfall<br/>compliance, phần cứng, fixed-bid]
    Q1 -->|Không| Q2{Việc đến<br/>liên tục?}
    Q2 -->|Có| Kanban[Kanban<br/>support, ops, platform]
    Q2 -->|Không| Q3{Stakeholder cần<br/>tầm nhìn 2 tuần?}
    Q3 -->|Có| Scrum[Scrum<br/>giao tính năng]
    Q3 -->|Không| Q4{Team ổn định,<br/>chu kỳ 6+ tuần OK?}
    Q4 -->|Có| ShapeUp[Shape Up<br/>việc dẫn dắt sản phẩm]
    Q4 -->|Không| Scrum

Ba câu hỏi, bốn câu trả lời. Các câu hỏi đều là về công việc, chứ không phải về team. Một team đã quen với Scrum mà giờ đang làm việc support thì vẫn nên cân nhắc Kanban - hình dạng công việc luôn quan trọng hơn ưa thích cá nhân.

Cheat sheet phù hợp với từng phương pháp là gì?

# Cheat Sheet Chọn Phương Pháp

## Scrum
- Tốt nhất cho: giao tính năng, team ổn định, đến dự đoán được
- Nhịp: sprint 2 tuần
- Artifact chính: sprint goal + backlog
- Bẫy: kịch ceremony ở quy mô nhỏ
- Tham khảo: [chương 06](/tech-pm/scrum-essentials)

## Kanban
- Tốt nhất cho: continuous flow, việc loại trộn, bị ngắt
- Nhịp: liên tục, review metric tuần
- Artifact chính: bảng có WIP limit
- Bẫy: stakeholder mất nhịp
- Tham khảo: [chương 07](/tech-pm/kanban-flow)

## Waterfall
- Tốt nhất cho: scope cố định, có quy định, ràng buộc phần cứng
- Nhịp: cổng phase (discovery -> design -> build -> test -> launch)
- Artifact chính: spec chi tiết, đã ký
- Bẫy: discovery bỏ sót bất ngờ trật phase sau
- Tham khảo: case study compliance trong văn liệu ngành

## Shape Up
- Tốt nhất cho: công ty sản phẩm với team ổn định tự chủ
- Nhịp: chu kỳ 6 tuần + cool-down 2 tuần
- Artifact chính: pitch + bet
- Bẫy: khó giải thích cho stakeholder không phải sản phẩm
- Tham khảo: sách "Shape Up" của Basecamp, miễn phí online

## Hybrid (Scrum + Kanban)
- Tốt nhất cho: team làm tính năng + ops/support
- Nhịp: Scrum cho tính năng, Kanban cho ops, cùng team
- Artifact chính: phân chia capacity (vd 70% sprint, 30% Kanban)
- Bẫy: capacity rò giữa hai cái; ops ăn sprint
- Tham khảo: chương này

Cheat sheet này có thể nhét gọn vào doc onboarding của bất cứ team nào. Engineer mới đọc qua, hiểu phương pháp nào áp cho loại việc nào, và sẽ ngừng hỏi câu "sao không làm X".

Chọn phương pháp ở quy mô đa team trông thế nào?

flowchart TB
    Org[Mức tổ chức: roadmap quý] --> TeamA[Team A: Scrum<br/>giao tính năng]
    Org --> TeamB[Team B: Kanban<br/>support platform]
    Org --> TeamC[Team C: Waterfall<br/>dự án compliance]
    TeamA --> Sync[Sync xuyên team 2 tuần<br/>40 phút]
    TeamB --> Sync
    TeamC --> Sync

Các team khác nhau có thể dùng phương pháp khác nhau; tầng tổ chức nên đứng trung lập về phương pháp, chỉ tập trung vào outcome và các dependency. Cuộc sync 2 tuần một lần dùng một artifact chung (status report) bất kể từng team hoàn thành việc của mình theo cách nào.

Sai lầm ở quy mô lớn là ép một phương pháp duy nhất cho cả tổ chức. SAFe thường lỗi theo đúng cách này: một team mà công việc của họ thực sự là continuous-flow lại bị nhét vào các nghi lễ PI-planning, sinh ra một thứ kế hoạch mang tính viễn tưởng nhiều hơn là thực tế.

Việc chọn phương pháp có thể tạo ra những lỗi nào?

• Đổi phương pháp mỗi quý. "Scrum không chạy, thử Kanban." Hai tháng sau lại "Kanban không chạy, thử Shape Up." Cách phòng: đổi nhiều nhất một lần mỗi năm; nguyên nhân thật sự của rối loạn hiếm khi nằm ở phương pháp.
• Hybrid trôi dần. Team bắt đầu với tỉ lệ 70/30 sprint/Kanban; áp lực ops đẩy ngầm thành 30/70. Cách phòng: theo dõi và báo cáo tỉ lệ capacity trong retrospective; nếu ops giờ chiếm phần lớn việc, hãy đổi hẳn sang Kanban.
• Đổi tên nhưng không đổi cách làm. Team đổi chức danh "Scrum Master" thành "Delivery Manager" nhưng vẫn chạy cùng ceremony cũ. Cách phòng: phương pháp là cách làm chứ không phải chức danh.
• Xáo trộn ở các điểm handoff. Đầu ra của sprint Team A là backlog của Team B. Nếu A chạy Scrum còn B chạy Kanban mà không có nhịp chung, các dependency sẽ kẹt. Cách phòng: thoả thuận một nhịp handoff rõ ràng dù phương pháp nội bộ có khác nhau.

Khi nào việc chọn phương pháp là phân tâm?

Khi team nhỏ, ổn định, và đang ship đều. Nếu 3 engineer vẫn giao được giá trị mỗi tuần với bất cứ thứ gì họ gọi là quy trình của mình, đừng áp đặt một thương hiệu nào lên đó. Kỷ luật quan trọng nằm ở các artifact (ước lượng, status, decision log) chứ không phải ở cái nhãn phương pháp.

Phương pháp chỉ thật sự đáng xem xét lại khi hình dạng công việc đã thay đổi rõ rệt - team vượt 8 người, một dự án lớn bắt đầu, hoặc mandate của team chuyển hướng.

Đi tiếp từ đây như thế nào?

Bạn đã hoàn tất phần methodology. Chương tiếp theo: discovery và kickoff - phần lifecycle bắt đầu. Phương pháp cho bạn biết làm sao chạy một sprint; còn các chương lifecycle nói về cái gì xảy ra trong từng phase của dự án, bất kể phương pháp.