Mở đầu — vì sao bài này quan trọng
Nếu bạn đã đi qua 31 bài trước, có thể bạn đang nghĩ Scrum là "chuẩn vàng" của Agile và mọi đội nhóm đều phải dùng Scrum. Đó là một ngộ nhận rất phổ biến — và nó khiến không ít Product Owner áp dụng sai công cụ vào sai bối cảnh, rồi tự trách mình "làm Scrum không chuẩn".
Sự thật là: Agile, Scrum và Kanban là ba thứ ở ba tầng khác nhau. Agile là một tư duy (mindset). Scrum là một framework cụ thể hiện thực hóa tư duy đó. Kanban là một phương pháp linh hoạt khác — cũng nằm dưới ô Agile nhưng vận hành theo nguyên tắc hoàn toàn khác Scrum. Hiểu rõ ranh giới giữa ba khái niệm này là điều phân biệt một PO "học vẹt Scrum" với một PO thực sự hiểu mình đang làm gì.
Với vai trò Product Owner, bạn không chỉ "chạy Scrum". Bạn là người phải quyết định: đội của tôi nên dùng Scrum, Kanban, hay lai ghép (Scrumban)? Khi nào nên chuyển đổi? Khi sếp hỏi "tại sao team support lại không có Sprint?", bạn cần trả lời được một cách thuyết phục. Bài này trang bị cho bạn chính cái khả năng phân biệt và lựa chọn đó.
Khái niệm cốt lõi
Agile là chiếc ô (umbrella), không phải một quy trình
Agile ra đời chính thức năm 2001 khi 17 chuyên gia phần mềm họp tại Utah và viết ra Agile Manifesto (Tuyên ngôn Agile). Đây không phải một bộ quy trình, mà là một tập hợp giá trị và nguyên tắc. Agile Manifesto gồm 4 giá trị cốt lõi:
> - Cá nhân và sự tương tác hơn là quy trình và công cụ. > - Phần mềm chạy được hơn là tài liệu đầy đủ. > - Hợp tác với khách hàng hơn là đàm phán hợp đồng. > - Phản hồi với thay đổi hơn là bám theo kế hoạch.
Lưu ý câu "hơn là" — Manifesto không nói vế phải vô giá trị. Tài liệu vẫn cần, hợp đồng vẫn cần. Nhưng khi phải đánh đổi, Agile ưu tiên vế trái. Kèm theo 4 giá trị là 12 nguyên tắc, trong đó có những điều rất quen thuộc với PO: giao giá trị sớm và liên tục, chào đón thay đổi yêu cầu kể cả ở giai đoạn muộn, giao phần mềm chạy được theo chu kỳ ngắn, và đội tự tổ chức.
Điểm mấu chốt: Agile không nói cho bạn biết phải làm gì cụ thể. Nó không có vai trò, không có sự kiện, không có artifact. Nó chỉ là tư duy. Để biến tư duy thành hành động, bạn cần một framework hoặc phương pháp cụ thể nằm dưới chiếc ô đó — và đó chính là chỗ Scrum và Kanban xuất hiện.
Dưới ô Agile có rất nhiều framework: Scrum, Kanban, Extreme Programming (XP), Crystal, Feature-Driven Development, và các framework mở rộng như SAFe, LeSS. Scrum và Kanban chỉ là hai cái phổ biến nhất.
Scrum — framework có cấu trúc, theo nhịp Sprint
Scrum (bạn đã học kỹ từ Bài 11) là một framework có khung thời gian cố định gọi là Sprint, thường 1–4 tuần. Đặc trưng của Scrum:
- Vai trò cố định: Product Owner, Scrum Master, Developers.
- Sự kiện cố định: Sprint Planning, Daily Scrum, Sprint Review, Retrospective.
- Artifact cố định: Product Backlog, Sprint Backlog, Increment.
- Nhịp cố định (cadence): công việc được "đóng gói" vào từng Sprint. Trong Sprint, phạm vi (scope) về nguyên tắc không thay đổi.
- Đo bằng Velocity: lượng việc hoàn thành mỗi Sprint, dùng để dự báo.
Kanban — phương pháp luồng liên tục, linh hoạt
Kanban xuất phát từ hệ thống sản xuất tinh gọn (Lean) của Toyota, sau đó được David Anderson đưa vào phát triển phần mềm. Khác Scrum hoàn toàn ở triết lý:
- Không có Sprint, không có khung thời gian cố định: công việc chảy liên tục (continuous flow) từ trái sang phải trên bảng.
- Không bắt buộc vai trò mới: bạn dùng đúng cơ cấu hiện có, không cần Scrum Master hay Sprint.
- Giới hạn WIP (Work In Progress): đây là trái tim của Kanban. Mỗi cột trên bảng có giới hạn số việc được làm đồng thời. Ví dụ cột "Đang code" tối đa 3 việc — không ai được kéo việc thứ 4 vào cho tới khi một việc rời cột.
- Đo bằng các chỉ số luồng: Lead Time (thời gian từ lúc yêu cầu vào tới lúc xong), Cycle Time, Throughput (số việc xong mỗi tuần).
- Thay đổi bất cứ lúc nào: vì không có cam kết Sprint, độ ưu tiên có thể được sắp xếp lại liên tục.
Bảng so sánh nhanh ba khái niệm
| Tiêu chí | Agile | Scrum | Kanban |
|---|---|---|---|
| Bản chất | Tư duy / triết lý | Framework có cấu trúc | Phương pháp luồng liên tục |
| Nhịp | Không quy định | Sprint cố định 1–4 tuần | Liên tục, không Sprint |
| Vai trò | Không có | PO, SM, Developers | Không bắt buộc thêm |
| Thay đổi scope | Khuyến khích | Hạn chế trong Sprint | Bất cứ lúc nào |
| Chỉ số chính | Không có | Velocity | Lead Time, WIP, Throughput |
| Khi nào dùng | Mọi nơi (mindset) | Phát triển tính năng có kế hoạch | Vận hành, hỗ trợ, luồng việc khó đoán |
Scrumban — khi bạn lai ghép cả hai
Trong thực tế nhiều đội Việt Nam dùng Scrumban: giữ Sprint và các sự kiện của Scrum nhưng áp dụng giới hạn WIP và bảng luồng của Kanban để xử lý việc đến đột xuất. Đây không phải "làm Scrum không chuẩn" — đây là lựa chọn có chủ đích, hoàn toàn hợp lệ trong tinh thần Agile.
Tình huống thực tế
Ví dụ 1 — Tiki: đội phát triển tính năng dùng Scrum, đội vận hành dùng Kanban
Hãy hình dung một công ty thương mại điện tử lớn như Tiki. Họ có hàng chục đội. Đội "Checkout & Payment" chịu trách nhiệm phát triển tính năng thanh toán mới: thêm ví điện tử, trả góp, tối ưu trang giỏ hàng. Công việc này có thể lập kế hoạch — PO biết quý này muốn ra mắt 3 tính năng, mỗi tính năng chia thành nhiều story. Đội này chạy Scrum Sprint 2 tuần, có Sprint Goal rõ ràng, đo Velocity khoảng 40 điểm/Sprint để dự báo ngày ra mắt.
Cùng lúc đó, đội "Site Reliability / On-call" xử lý sự cố hệ thống và yêu cầu khẩn từ bộ phận chăm sóc khách hàng. Công việc của họ không thể đoán trước — hôm nay có thể yên ắng, ngày mai một lỗi thanh toán nổ ra cần xử lý ngay trong 2 giờ. Nếu ép đội này vào Sprint 2 tuần, mọi cam kết Sprint sẽ liên tục bị phá vỡ vì việc khẩn chen ngang. Vì vậy họ dùng Kanban: bảng có các cột Backlog → Đang xử lý → Review → Done, giới hạn WIP mỗi người tối đa 2 việc, đo Lead Time để cam kết "xử lý sự cố nghiêm trọng trong vòng 4 giờ".
Bài học rút ra: Trong cùng một công ty, hai đội cùng theo tư duy Agile nhưng chọn hai cách triển khai khác nhau, vì bản chất công việc khác nhau. PO giỏi không hỏi "team nào cũng phải Scrum chứ?" mà hỏi "công việc của team này có lập kế hoạch được theo nhịp không?".
Ví dụ 2 — Startup fintech 8 người chuyển từ Scrum sang Kanban
Một startup fintech ở TP.HCM, đội kỹ thuật 8 người, ban đầu áp dụng Scrum theo sách vở: Sprint 2 tuần, đầy đủ 4 sự kiện. Nhưng sau 3 tháng, PO nhận ra một vấn đề: trung bình mỗi Sprint có 5–6 yêu cầu khẩn từ khách hàng doanh nghiệp lớn (đối tác ngân hàng) chen vào, khiến Sprint Goal gần như không bao giờ đạt. Mỗi Retrospective, team lại than "lại vỡ cam kết". Velocity dao động loạn xạ từ 15 đến 45 điểm, không dự báo được gì.
PO quyết định thử nghiệm chuyển sang Kanban trong 6 tuần. Họ bỏ Sprint, dựng bảng Kanban với giới hạn WIP là 4 việc cho cả đội, và giữ lại buổi họp ngắn hằng ngày cùng buổi review cuối tuần với khách hàng. Kết quả sau 6 tuần: Lead Time trung bình giảm từ 9 ngày xuống 4 ngày, vì team không còn "ôm" một đống việc dở dang cùng lúc. Cảm giác "thất bại mỗi Sprint" biến mất vì không còn cam kết Sprint để phá. Khách hàng hài lòng hơn vì yêu cầu được xử lý nhanh và minh bạch.
Bài học rút ra: Khi luồng việc bị gián đoạn liên tục bởi yêu cầu khẩn, ép cam kết Sprint chỉ tạo ra cảm giác thất bại giả tạo. Kanban với giới hạn WIP có thể phù hợp hơn. Quan trọng: PO đã đo bằng số liệu (Lead Time, Velocity) trước và sau khi đổi, chứ không quyết định theo cảm tính.
Ví dụ 3 — Agency phần mềm và cú lừa "chúng tôi làm Agile"
Một agency outsourcing ở Đà Nẵng quảng cáo với khách hàng nước ngoài rằng "chúng tôi làm Agile". Khi đào sâu, hóa ra quy trình của họ là: nhận toàn bộ yêu cầu đầu dự án, lập kế hoạch chi tiết 6 tháng, không cho khách thay đổi yêu cầu, giao sản phẩm một lần duy nhất ở cuối. Họ chỉ "có daily standup" nên gọi đó là Agile.
Đây là cái bẫy "cargo cult Agile" — sao chép hình thức (có standup, có bảng task) nhưng vi phạm chính giá trị cốt lõi của Manifesto (chào đón thay đổi, giao hàng liên tục, hợp tác với khách hàng). Một khách hàng tinh ý phát hiện ra, vì mỗi lần họ muốn điều chỉnh yêu cầu thì bị từ chối với lý do "ngoài scope hợp đồng".
Bài học rút ra: Agile là tư duy, không phải bộ nghi thức. Có standup không có nghĩa là Agile; không có standup cũng chưa chắc không Agile. Là PO, bạn phải kiểm tra giá trị chứ không phải hình thức: đội có thực sự chào đón thay đổi không? Có giao giá trị sớm và liên tục không? Có hợp tác thật với người dùng không?
Hướng dẫn từng bước
Đây là quy trình giúp bạn — với vai trò PO — chọn đúng cách tiếp cận cho đội mình:
- Xác nhận tư duy Agile trước đã. Trước khi bàn Scrum hay Kanban, hỏi: đội và tổ chức có thực sự sống theo giá trị Agile không (chào đón thay đổi, giao hàng liên tục)? Nếu không, đổi framework cũng vô ích.
- Phân tích bản chất công việc. Tự hỏi: công việc của đội có thể lập kế hoạch trước theo từng đợt không? Hay nó đến ngẫu nhiên, khó đoán, ưu tiên đổi liên tục? Việc phát triển tính năng → nghiêng về Scrum. Việc vận hành, hỗ trợ, sửa lỗi → nghiêng về Kanban.
- Đo mức độ gián đoạn. Đếm trong vài tuần qua có bao nhiêu yêu cầu khẩn chen ngang. Nếu trên 20–30% công việc là khẩn cấp, Sprint sẽ liên tục bị phá — cân nhắc Kanban hoặc Scrumban.
- Chọn cách tiếp cận và cấu hình. Nếu chọn Scrum: chốt độ dài Sprint, vai trò, sự kiện. Nếu chọn Kanban: dựng các cột phản ánh đúng luồng làm việc thật và đặt giới hạn WIP cho từng cột.
- Định nghĩa chỉ số đo lường tương ứng. Scrum → theo dõi Velocity và mức đạt Sprint Goal. Kanban → theo dõi Lead Time, Cycle Time, Throughput, và việc tuân thủ giới hạn WIP.
- Chạy thử và rà soát. Cho chạy ít nhất 4–6 tuần. Dùng số liệu (không phải cảm tính) để đánh giá. Sẵn sàng điều chỉnh hoặc lai ghép thành Scrumban nếu cần.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi Scrum và Agile là một. Nói "chúng ta làm Agile" trong khi ý là "chúng ta làm Scrum". Hệ quả là nghĩ rằng bỏ Scrum tức là bỏ Agile. Mẹo: nhớ Agile là chiếc ô, Scrum chỉ là một trong nhiều framework dưới ô đó.
Lỗi 2 — Ép Kanban vào team phát triển tính năng dài hạn để "né cam kết". Một số đội dùng Kanban như cái cớ để không bao giờ cam kết deadline. Mẹo: Kanban không có nghĩa là không có kế hoạch — bạn vẫn dùng Lead Time và Throughput để dự báo. Nếu công việc có thể lập kế hoạch tốt, Scrum thường cho nhịp giao hàng và khả năng dự báo rõ ràng hơn.
Lỗi 3 — Bỏ qua giới hạn WIP khi dùng Kanban. Dựng bảng Kanban nhưng không đặt giới hạn WIP thì chỉ là một cái bảng to-do đẹp đẽ, không phải Kanban thật. Giới hạn WIP mới là thứ tạo ra hiệu quả. Mẹo: bắt đầu với WIP hơi chặt, rồi nới dần nếu thấy đội bị nghẽn.
Lỗi 4 — Cargo cult Agile. Sao chép nghi thức (standup, board) mà bỏ qua giá trị. Mẹo: định kỳ đối chiếu cách làm việc với 4 giá trị Manifesto, không chỉ kiểm tra "có đủ sự kiện chưa".
Lỗi 5 — Đổi framework theo cảm tính. Đổi vì "nghe nói Kanban hay" mà không đo lường. Mẹo: luôn đo trước và sau khi thay đổi.
Bài tập thực hành
- Tự đánh giá đội của bạn (hoặc một đội bạn biết). Viết ra: công việc của đội thuộc loại "lập kế hoạch được" hay "đến ngẫu nhiên"? Ước tính tỷ lệ phần trăm việc khẩn cấp chen ngang mỗi tuần. Từ đó kết luận: đội nên dùng Scrum, Kanban hay Scrumban? Giải thích lý do bằng đúng các tiêu chí trong bài.
- Ánh xạ 4 giá trị Manifesto. Với mỗi giá trị trong 4 giá trị của Agile Manifesto, viết một ví dụ cụ thể về việc bạn (PO) có thể làm hằng ngày để hiện thực hóa giá trị đó. Ví dụ giá trị "phản hồi với thay đổi" → "không khóa cứng backlog 3 tháng, refinement lại mỗi Sprint".
- Thiết kế một bảng Kanban. Giả sử bạn phụ trách đội hỗ trợ khách hàng kỹ thuật. Vẽ bảng Kanban gồm các cột phù hợp với luồng làm việc thật của họ, và đề xuất giới hạn WIP cho từng cột. Giải thích vì sao bạn chọn các con số đó.
- Phát hiện cargo cult. Đọc lại Ví dụ 3 (agency Đà Nẵng). Liệt kê 3 dấu hiệu cho thấy một đội "giả Agile". Sau đó nghĩ ra 1 câu hỏi sắc bén bạn sẽ hỏi để kiểm chứng một đội có thực sự Agile hay chỉ làm hình thức.
Tóm tắt
- Agile là tư duy (mindset) ra đời từ Agile Manifesto 2001 với 4 giá trị và 12 nguyên tắc. Nó là chiếc ô bao trùm, không phải một quy trình cụ thể.
- Scrum là một framework dưới ô Agile: có cấu trúc, vai trò cố định, nhịp Sprint cố định, scope hạn chế trong Sprint, đo bằng Velocity. Phù hợp với phát triển tính năng có kế hoạch.
- Kanban là một phương pháp khác dưới ô Agile: luồng liên tục, không Sprint, không vai trò bắt buộc, dùng giới hạn WIP, đo bằng Lead Time và Throughput. Phù hợp với công việc khó đoán, ưu tiên đổi liên tục.
- Scrumban là lựa chọn lai ghép hợp lệ khi bạn cần cả hai.
- Là PO, nhiệm vụ của bạn không phải "tuân thủ Scrum" mà là chọn đúng công cụ cho đúng bối cảnh, dựa trên bản chất công việc và đo lường bằng số liệu — không phải cảm tính hay sao chép hình thức.