Kanban vs Scrum: Chọn Framework Nào Cho Team Của Bạn?

State of Agile Report 2024: 87% engineering teams dùng Agile, nhưng chỉ 58% tự đánh giá "successful." Lý do phổ biến nhất không phải Agile sai — mà là chọn sai framework. Team maintenance/support dùng Scrum → frustration vì sprint cadence không phù hợp với interrupt-driven work. Team product dùng Kanban thuần → thiếu planning discipline, không ai biết delivery date. Bài viết phân tích chi tiết khi nào Kanban, khi nào Scrum, khi nào Hybrid (Scrumban) — dựa trên work type, team maturity, và business needs.

So Sánh Chi Tiết

Khi Nào Dùng Scrum?

✅ Product development team build features theo roadmap — cần predictability cho stakeholders. ✅ Team cần planning discipline: estimation, commitment, velocity tracking để forecast delivery dates. ✅ Stakeholders muốn biết "sprint nào deliver feature nào?" — Scrum trả lời được. ✅ Team mới bắt đầu Agile — Scrum có structure rõ ràng, ceremonies defined, roles có trách nhiệm cụ thể → dễ adopt hơn Kanban. ✅ Cross-functional team (frontend, backend, QA) cùng work trên features — sprint tạo sync point cho cả team.

Khi Nào Dùng Kanban?

✅ Support/ops teams xử lý tickets liên tục — incidents, bugs, customer requests đến bất kỳ lúc nào. ✅ Work items không predictable — priority thay đổi hàng ngày, incoming work volume biến động. ✅ Team muốn flexibility — không muốn bị lock trong sprint scope khi urgent request đến. ✅ Content teams, design teams, marketing — creative work flow liên tục, không fit sprint cadence. ✅ DevOps/SRE — incident response và improvement work không chờ sprint planning.

Scrumban: Hybrid Approach

Lấy cái tốt của cả hai: Sprint cadence từ Scrum (2 tuần planning + retrospective — tạo rhythm) + Kanban flow (WIP limits, continuous delivery, visual board). Điểm khác biệt: không lock sprint scope — tasks mới có thể thêm mid-sprint nếu WIP cho phép. Planning nhẹ nhàng hơn Scrum — replenish backlog khi WIP thấp thay vì planning toàn bộ sprint upfront. Estimation optional — focus vào throughput thay velocity. BanhCuonFlow recommended approach cho engineering teams cần balance giữa planning discipline và flow flexibility.

WIP Limits: Bí Mật Của Kanban

WIP (Work In Progress) limit là core concept của Kanban — giới hạn số tasks active trong mỗi column. Ví dụ: "In Progress" max 3 tasks cho team 3 devs (1 task/person). Tại sao? Little's Law: Cycle Time = WIP ÷ Throughput. Giảm WIP → giảm cycle time → deliver nhanh hơn. Khi WIP đầy → team phải hoàn thành task hiện tại trước khi bắt đầu mới. Kết quả: ít multitasking (context switching costs 20-40% productivity — APA research), focus cao hơn, chất lượng tốt hơn. BanhCuonFlow: configurable WIP limits per column, visual warning (column chuyển đỏ) khi vượt limit.

Scrum Ceremonies: Keep or Kill?

Keep: Sprint Planning — nhưng giảm xuống 1 giờ cho sprint 2 tuần, focus vào Sprint Goal. Daily Standup — 15 phút max, 3 câu chuẩn, hoặc async standup qua chat channel. Retrospective — biweekly, max 45 phút, action items tracked. Sprint Review/Demo — keep, stakeholders cần visibility vào progress.

Kill/Modify: Grooming/Refinement dài 2 giờ → làm continuous: PO refine 2-3 items/ngày, team review async. Daily standup 30 phút → giới hạn 15 phút, problems discuss offline sau standup. Estimation sessions riêng → integrate vào refinement, quick estimate khi item vào sprint.