Mở đầu — vì sao bài này quan trọng
Nếu bạn từng ngồi trong một cuộc họp mà ai đó dõng dạc tuyên bố "Team mình phải làm Agile", rồi vài tháng sau cả nhóm kiệt sức vì họp hành liên miên, sprint nào cũng "carry over" (dồn việc chưa xong sang sprint sau), thì bạn đã chạm vào vấn đề mà bài này giải quyết: người ta hiểu sai và áp dụng sai Agile, Scrum, Kanban.
Ba từ này bị dùng lẫn lộn đến mức gần như vô nghĩa. Rất nhiều người nghĩ "Agile = Scrum", "Scrum = họp standup mỗi sáng", "Kanban = cái bảng dán giấy note trên tường". Cả ba cách hiểu đó đều sai một phần, và khi bạn bắt đầu scale (mở rộng) tổ chức — từ một team lên năm team, từ hai mươi người lên hai trăm người — thì sự nhầm lẫn đó biến thành lãng phí thật, tính bằng tiền và bằng người nghỉ việc.
Trong hành trình scaling team, việc chọn đúng phương pháp làm việc cho từng loại team là một quyết định vận hành (operations) cốt lõi. Chọn sai, bạn ép một team hỗ trợ vận hành phải chạy sprint hai tuần một cách cứng nhắc, hoặc để một team làm sản phẩm dài hạn trôi nổi không có nhịp điệu. Bài này giúp bạn phân biệt rạch ròi ba khái niệm, hiểu bản chất của chúng, và quan trọng nhất: biết khi nào dùng cái nào.
Khái niệm cốt lõi
Agile là một tư duy, không phải một quy trình
Điều đầu tiên và quan trọng nhất bạn cần khắc cốt: Agile không phải là một phương pháp bạn "làm". Agile là một hệ giá trị, một cách tư duy (mindset). Nó ra đời năm 2001 khi mười bảy chuyên gia phần mềm gặp nhau và viết ra bản Agile Manifesto (Tuyên ngôn Agile) gồm 4 giá trị cốt lõi:
- Cá nhân và tương tác quan trọng hơn quy trình và công cụ (Individuals and interactions over processes and tools).
- Phần mềm chạy được quan trọng hơn tài liệu đầy đủ (Working software over comprehensive documentation).
- Hợp tác với khách hàng quan trọng hơn đàm phán hợp đồng (Customer collaboration over contract negotiation).
- Phản ứng với thay đổi quan trọng hơn bám theo kế hoạch (Responding to change over following a plan).
Điểm mấu chốt cần nhớ: Scrum và Kanban là hai trong nhiều cách hiện thực hóa tư duy Agile. Agile là "tại sao" và "giá trị nào"; Scrum, Kanban là "làm như thế nào". Nói "team tôi làm Agile" mà không chỉ ra dùng framework gì thì cũng giống nói "tôi ăn uống lành mạnh" mà không nói ăn món gì.
Scrum: nhịp điệu theo sprint
Scrum là một framework có cấu trúc rõ ràng, dựa trên nguyên tắc lặp lại theo chu kỳ cố định gọi là sprint (thường 1–4 tuần, phổ biến nhất là 2 tuần). Đặc trưng của Scrum:
- Vai trò (roles): Product Owner (quyết định làm gì và thứ tự ưu tiên), Scrum Master (bảo vệ quy trình, gỡ rào cản), và Development Team (những người làm ra sản phẩm).
- Sự kiện (ceremonies): Sprint Planning (lập kế hoạch đầu sprint), Daily Standup (họp nhanh 15 phút mỗi ngày), Sprint Review (trình bày kết quả cuối sprint), Sprint Retrospective (nhìn lại để cải tiến).
- Cam kết cố định trong sprint: Khi sprint đã bắt đầu, phạm vi công việc (scope) được "đóng băng". Ai muốn thêm việc phải chờ sprint sau. Đây là điểm cực kỳ quan trọng — nó bảo vệ team khỏi việc bị thay đổi yêu cầu liên tục.
Kanban: dòng chảy liên tục
Kanban thì khác hẳn về triết lý. Thay vì chia công việc thành các sprint đóng gói, Kanban tập trung vào dòng chảy liên tục (continuous flow) của công việc. Ba nguyên tắc cốt lõi:
- Trực quan hóa công việc (visualize the workflow): dùng bảng với các cột như "To Do → In Progress → Review → Done".
- Giới hạn công việc đang làm dở (WIP limit — Work In Progress limit): đây là linh hồn của Kanban. Bạn đặt giới hạn, ví dụ cột "In Progress" tối đa 3 thẻ. Không ai được kéo việc mới vào khi cột đã đầy. Điều này ép team hoàn thành việc đang làm trước khi bắt việc mới, tránh tình trạng làm dở dang mười thứ mà không xong cái nào.
- Đo và tối ưu dòng chảy (manage flow): theo dõi các chỉ số như cycle time (thời gian một thẻ đi từ lúc bắt đầu đến lúc xong) và throughput (số thẻ hoàn thành mỗi tuần).
So sánh trực diện
| Tiêu chí | Scrum | Kanban |
|---|---|---|
| Đơn vị làm việc | Sprint cố định (1–4 tuần) | Dòng chảy liên tục |
| Cam kết phạm vi | Đóng băng trong sprint | Linh hoạt, thay đổi bất cứ lúc nào |
| Vai trò | PO, Scrum Master, Dev Team | Không bắt buộc |
| Chỉ số chính | Velocity (số điểm/sprint) | Cycle time, WIP, throughput |
| Phù hợp với | Việc lập kế hoạch được | Việc đến ngẫu nhiên, ưu tiên biến động |
Tình huống thực tế
Ví dụ 1 — Tiki: hai team, hai phương pháp trong cùng một công ty
Hãy hình dung bối cảnh của một sàn thương mại điện tử lớn tại Việt Nam như Tiki. Trong cùng một khối kỹ thuật, có hai team với bản chất công việc hoàn toàn khác nhau.
Team đầu tiên là team Checkout & Payment, chịu trách nhiệm xây các tính năng mới cho luồng thanh toán: thêm ví điện tử, tối ưu bước nhập địa chỉ, làm tính năng mua trước trả sau. Công việc của họ có thể lên kế hoạch trước, có roadmap rõ ràng, và cần phối hợp với marketing để ra mắt đúng dịp sale lớn như ngày đôi 11/11. Team này chạy Scrum với sprint 2 tuần. Mỗi đầu sprint họ cam kết một tập tính năng, cuối sprint demo cho stakeholder, và nhịp điệu này cho phép giám đốc sản phẩm hứa hẹn với ban lãnh đạo về ngày ra mắt.
Team thứ hai là team Site Reliability / Vận hành hạ tầng, xử lý sự cố production, cảnh báo hệ thống, yêu cầu hỗ trợ khẩn từ các team khác. Công việc của họ không thể lập kế hoạch trước — một sự cố downtime lúc 2 giờ sáng không bao giờ chờ đến sprint sau. Nếu ép team này chạy Scrum, mọi sprint đều vỡ kế hoạch vì việc khẩn cấp liên tục chen ngang. Vì vậy họ dùng Kanban với WIP limit chặt: cột "Đang xử lý" tối đa 4 thẻ, ưu tiên theo mức độ nghiêm trọng.
Bài học: Không có phương pháp nào "tốt hơn" một cách tuyệt đối. Bản chất công việc quyết định phương pháp. Trong cùng một công ty, thậm chí cùng một phòng ban, các team khác nhau nên dùng framework khác nhau. Việc ép cả tổ chức chạy một khuôn duy nhất là sai lầm phổ biến khi scale.
Ví dụ 2 — Một startup fintech 25 người "làm Scrum" nhưng thực ra làm sai
Một startup fintech giả định ở TP.HCM, khoảng 25 kỹ sư, tuyên bố "chúng tôi làm Scrum bài bản". Nhưng khi quan sát kỹ: sprint dài 2 tuần nhưng CEO thường xuyên nhảy vào giữa sprint yêu cầu thêm tính năng "gấp lắm"; standup kéo dài 45 phút thành buổi báo cáo tiến độ cho sếp; retrospective bị bỏ vì "không có thời gian".
Kết quả sau 3 tháng: velocity dao động thất thường, tinh thần team đi xuống, hai kỹ sư giỏi xin nghỉ. Vấn đề không phải Scrum sai — mà là họ lấy vỏ Scrum (có standup, có sprint) nhưng vứt bỏ phần cốt lõi bảo vệ team (đóng băng scope, retrospective để cải tiến). Đây gọi là "Zombie Scrum" — nhìn giống Scrum nhưng đã chết phần hồn.
Khi được tư vấn, họ nhận ra bản chất công việc giai đoạn này (startup đổi hướng liên tục theo phản hồi thị trường) thực ra hợp với Kanban hơn. Họ chuyển sang bảng Kanban với WIP limit, bỏ sprint cứng nhắc, giữ lại một buổi retrospective mỗi 2 tuần. Ba tháng sau, cycle time trung bình giảm từ 9 ngày xuống 4 ngày, và quan trọng hơn, CEO buộc phải tôn trọng WIP limit thay vì nhồi việc bừa bãi.
Bài học: Đừng thờ phượng nghi thức. Nếu bạn giữ hình thức mà bỏ nguyên tắc cốt lõi, phương pháp nào cũng vô dụng. Và đôi khi câu trả lời là chuyển sang phương pháp khác, không phải cố "làm đúng" cái đang sai.
Ví dụ 3 — Grab và mô hình lai Scrumban
Với các công ty công nghệ lớn ở Đông Nam Á như Grab, nhiều team áp dụng mô hình lai gọi là Scrumban — kết hợp cấu trúc theo nhịp của Scrum với dòng chảy và WIP limit của Kanban. Một team làm tính năng cho tài xế có thể giữ nhịp planning và retrospective 2 tuần một lần (kiểu Scrum) để đồng bộ với các team khác, nhưng bên trong dùng bảng Kanban với WIP limit và cho phép kéo việc liên tục thay vì đóng băng scope tuyệt đối.
Bài học: Khi tổ chức trưởng thành, ranh giới giữa Scrum và Kanban mờ đi. Điều quan trọng không phải là "trung thành" với một framework, mà là lấy đúng thành phần phù hợp với bối cảnh của bạn. Scrumban là minh chứng rằng framework là công cụ, không phải tôn giáo.
Hướng dẫn từng bước
Đây là quy trình để chọn và triển khai phương pháp cho một team cụ thể khi bạn đang scale:
- Phân loại bản chất công việc của team. Hỏi: công việc có lập kế hoạch trước được không? Nếu phần lớn việc đến theo kế hoạch, có roadmap → nghiêng về Scrum. Nếu phần lớn việc đến bất ngờ, ưu tiên biến động (hỗ trợ, vận hành, sự cố) → nghiêng về Kanban.
- Đánh giá nhu cầu về khả năng dự đoán (predictability). Nếu các bên liên quan cần biết "khi nào xong" để phối hợp (marketing, sales, đối tác) → Scrum tạo cam kết theo sprint tốt hơn. Nếu chỉ cần "làm nhanh nhất có thể" → Kanban.
- Kiểm tra độ trưởng thành của team. Team mới thành lập, chưa có kỷ luật tự giác thường hưởng lợi từ cấu trúc chặt của Scrum. Team đã trưởng thành, tự quản tốt có thể vận hành Kanban linh hoạt mà không hỗn loạn.
- Chọn framework khởi điểm và cam kết chạy tối thiểu 2–3 tháng. Đừng đổi liên tục. Cho phương pháp đủ thời gian bộc lộ ưu nhược điểm qua vài chu kỳ retrospective.
- Đo lường bằng chỉ số phù hợp. Scrum: theo dõi velocity và tỷ lệ hoàn thành cam kết sprint. Kanban: theo dõi cycle time và WIP. Dùng số liệu để điều chỉnh, không dựa vào cảm tính.
- Điều chỉnh về mô hình lai nếu cần. Sau vài chu kỳ, nếu thấy Scrum quá cứng hoặc Kanban quá lỏng, hãy cân nhắc Scrumban. Giữ nhịp planning/retro nhưng nới scope, hoặc thêm WIP limit vào sprint.
Lỗi thường gặp & mẹo
Lỗi 1: Đánh đồng Agile với Scrum. Rất nhiều người dùng "Agile" và "Scrum" thay thế cho nhau. Nhớ: Agile là tư duy, Scrum/Kanban là cách hiện thực. Bạn có thể làm Scrum mà hoàn toàn không Agile (Zombie Scrum), và ngược lại.
Lỗi 2: Thờ phượng nghi thức (cargo cult). Tổ chức standup, sprint, bảng Kanban chỉ vì "công ty ngầu nào cũng làm thế", mà không hiểu mục đích. Mẹo: với mỗi nghi thức, luôn hỏi "cái này giải quyết vấn đề gì?" Nếu không trả lời được, hãy bỏ hoặc sửa nó.
Lỗi 3: Không đặt WIP limit trong Kanban. Kanban mà không giới hạn WIP thì chỉ là cái danh sách việc cần làm đẹp mắt. WIP limit chính là cơ chế tạo ra hiệu quả. Mẹo: bắt đầu với WIP limit hơi chặt (ví dụ số người trong team) rồi nới dần.
Lỗi 4: Để scope sprint bị phá vỡ liên tục. Nếu bạn chạy Scrum mà sếp cứ chen việc giữa sprint, bạn đã mất toàn bộ giá trị của Scrum. Mẹo: nếu tổ chức không thể tôn trọng scope đóng băng, đó là dấu hiệu mạnh rằng bạn nên chuyển sang Kanban.
Lỗi 5: Ép cả tổ chức dùng một khuôn. Khi scale, cám dỗ "chuẩn hóa" khiến người ta ép mọi team dùng cùng framework. Mẹo: chuẩn hóa nguyên tắc (minh bạch, cải tiến liên tục, giao giá trị đều đặn), nhưng để mỗi team chọn phương pháp phù hợp bản chất công việc của họ.
Mẹo tổng quát: Standup không phải để báo cáo cho sếp — nó để team tự đồng bộ. Retrospective là nghi thức đáng giá nhất và cũng bị bỏ đầu tiên khi bận — đừng bao giờ bỏ nó, vì đó là cơ chế duy nhất giúp quy trình tự cải thiện.
Bài tập thực hành
- Phân loại team của bạn. Lấy team hiện tại (hoặc một team bạn biết). Ước lượng: bao nhiêu phần trăm công việc trong tháng qua là lập kế hoạch trước được, bao nhiêu phần trăm là đến bất ngờ? Dựa trên tỷ lệ đó, team nên nghiêng về Scrum hay Kanban? Viết ra lý do trong 3–4 câu.
- Chẩn đoán Zombie Scrum. Nếu team bạn đang "làm Scrum", chấm điểm 4 dấu hiệu sau, mỗi cái 0 hoặc 1 điểm: (a) scope sprint có bị phá giữa chừng không? (b) standup có dài quá 15 phút không? (c) retrospective có bị bỏ không? (d) demo cuối sprint có bị bỏ không? Nếu tổng ≥ 2, team đang có triệu chứng Zombie Scrum. Đề xuất một hành động sửa chữa cụ thể.
- Thiết kế bảng Kanban. Cho một team hỗ trợ vận hành 5 người, hãy vẽ ra các cột của bảng Kanban và đặt WIP limit cho từng cột. Giải thích tại sao bạn chọn con số đó.
- Tranh luận Scrumban. Viết một đoạn ngắn (150 từ) lập luận vì sao một team làm sản phẩm 8 người nên (hoặc không nên) chuyển từ Scrum thuần sang Scrumban.
Tóm tắt
- Agile là tư duy, không phải quy trình. Nó gồm 4 giá trị trong Agile Manifesto, ưu tiên con người, phần mềm chạy được, hợp tác và khả năng thích ứng.
- Scrum và Kanban là hai cách hiện thực hóa Agile, không phải bản thân Agile.
- Scrum = nhịp điệu theo sprint cố định, scope đóng băng, có vai trò và nghi thức rõ ràng. Hợp với công việc lập kế hoạch được và cần khả năng dự đoán.
- Kanban = dòng chảy liên tục, giới hạn WIP, linh hoạt tối đa. Hợp với công việc đến bất ngờ, ưu tiên biến động như vận hành, hỗ trợ.
- Chọn theo bản chất công việc, không theo mốt. Trong cùng tổ chức, các team khác nhau nên dùng framework khác nhau.
- Scrumban là mô hình lai phổ biến khi tổ chức trưởng thành — lấy thành phần phù hợp từ cả hai.
- Cạm bẫy lớn nhất khi scale: thờ phượng nghi thức và ép mọi team vào một khuôn. Hãy chuẩn hóa nguyên tắc, linh hoạt về phương pháp.