Bảng công việc của team nhìn khá yên lúc 9:20 sáng, nhưng công việc thì không yên chút nào. Ba support bug đến trước cả ly cà phê đầu tiên, một product story đang chờ design làm rõ, hai pull request mắc ở review, và có người vừa hỏi nhỏ: team mình còn đang làm Scrum không, hay đã thành Kanban từ lúc nào mà chưa ai nói ra?
Câu hỏi đó xuất hiện khá thường xuyên, vì Scrum và Kanban rất dễ đem ra so trên bề mặt. Scrum có sprint, planning, review, retro và sprint goal. Kanban có board chạy liên tục, WIP limit và flow. Một bên trông có cấu trúc hơn. Một bên trông linh hoạt hơn. Nhưng câu hỏi hữu ích không phải là framework nào nghe gọn hơn. Câu hỏi hữu ích là team đang thật sự sống với loại công việc nào.
Scrum hợp nhất khi công việc có thể được gom vào một nhịp planning ngắn. Team có thể nhìn backlog, chọn một nhóm việc có ý nghĩa, cam kết tương đối trong một hoặc hai tuần, và bảo vệ đủ focus để finish. Nhịp đó hữu ích khi product direction cần được bàn đều đặn, stakeholder cần một điểm review dễ đoán, và team cần dừng lại sau mỗi sprint để hỏi cách làm việc của mình nên thay đổi điều gì.
Kanban hợp nhất khi công việc đi vào liên tục và việc chen ngang không phải ngoại lệ. Support, operations, platform maintenance, xử lý sau incident, request nội bộ nhỏ, hoặc những team nhận việc từ nhiều hướng thường sống gần với flow hơn là sprint commitment. Trong thế giới đó, vấn đề chính không phải là chọn một sprint backlog thật đẹp. Vấn đề là giới hạn số việc đang làm, làm blocker hiện rõ, và giúp công việc đi từ request đến done mà không âm thầm chất đống ở giữa.
Khác biệt bắt đầu từ intake. Trong Scrum, intake thường được gom, refine, rồi chọn vào sprint. Việc mới vẫn có thể xuất hiện, nhưng quá nhiều thay đổi giữa sprint sẽ làm yếu ý nghĩa của sprint. Trong Kanban, intake có thể liên tục hơn, nhưng vẫn cần kỷ luật. Một Kanban board không có intake policy sẽ thành một danh sách việc công khai, nơi item khẩn cấp cứ nhảy lên đầu hàng. Linh hoạt không có nghĩa là không có luật. Nó là một bộ luật khác.
WIP là nơi Kanban thường dạy Scrum team một bài rất thực tế. Nhiều team tưởng mình có vấn đề delivery, trong khi vấn đề thật là quá nhiều việc được bắt đầu cùng lúc. Năm developer, mỗi người mở ba ticket, có thể làm board nhìn rất bận nhưng không có gì thật sự tới done. Kanban làm nỗi đau đó hiện rõ bằng cách yêu cầu team giới hạn các cột như In Progress, Review và QA. Scrum cũng có thể dùng thói quen đó bên trong sprint. Sprint backlog không phải giấy phép để bắt đầu mọi thứ từ thứ Hai.
Predictability cũng mang nghĩa khác nhau trong hai cách làm. Scrum tạo predictability bằng cadence: mỗi sprint team plan, build, review và học. Nó giúp stakeholder biết khi nào sẽ có cuộc trò chuyện, và giúp team forecast từ kết quả các sprint trước. Kanban tạo predictability bằng flow metrics: việc thường mất bao lâu, nó chờ ở đâu, item nào đang già đi, và throughput có ổn định không. Scrum hỏi: sprint này mình có thể finish gì? Kanban hỏi: công việc đang đi qua hệ thống của mình như thế nào theo thời gian?
Không câu hỏi nào trưởng thành hơn câu hỏi nào. Chúng trả lời những nỗi lo khác nhau. Một product team đang xây feature mới có thể cần sự tập trung chung của sprint goal. Một team nhiều support có thể cần sự thật thà của cycle time và aging ticket. Một services team có cam kết với client có thể cần Scrum để planning, và cần Kanban bên trong sprint để kiểm soát review và QA queue. Một startup nhỏ có thể bắt đầu bằng Kanban vì ưu tiên đổi mỗi ngày, rồi thêm nhịp planning giống sprint khi hướng product bớt biến động.
Sai lầm dễ gặp là chọn bằng bản sắc. Có team muốn Scrum vì nó có vẻ chính quy. Có team muốn Kanban vì nó có vẻ nhẹ hơn. Cả hai cảm giác đó đều có thể che mất vấn đề thật. Scrum không sửa được priority mơ hồ nếu Product Owner không có mặt. Kanban không sửa được hỗn loạn nếu stakeholder nào cũng có thể nhét việc vào bất cứ lúc nào. Framework có thể làm áp lực trong hệ thống hiện rõ, nhưng nó không thay thế quyết định về ownership, priority và những điều team được phép từ chối.
Một bài kiểm tra thực tế là nhìn lại tháng vừa rồi mà không cần bảo vệ process. Phần lớn công việc đến trước sprint, hay trong lúc sprint đang chạy? Team fail vì planning kém, hay vì quá nhiều thứ đi vào hệ thống cùng lúc? Stakeholder cần một nhịp review cố định, hay chủ yếu cần các request nhỏ chạy nhanh hơn? Team đang đau vì commitment yếu, hay vì quá nhiều WIP? Câu trả lời thường chỉ hướng rõ hơn cuộc tranh luận về tên gọi.
Nhiều team khỏe cuối cùng dùng một bản pha trộn. Họ plan sprint goal cho product work, đặt WIP limit trên board, giữ một phần capacity cho interrupt, chạy retro đều, và nhìn cycle time để review với QA không biến thành phòng chờ ẩn. Người ta gọi đó là Scrumban, nhưng cái tên ít quan trọng hơn sự thật thà. Team đang nói rằng: mình cần một ít cadence, một ít flow control, và đủ feedback để tiếp tục cải thiện.
Vì vậy, lựa chọn hợp hơn không phải framework nào đẹp hơn trong slide. Nó là framework khớp với cách công việc đi vào, mức uncertainty team đang mang, và kiểu predictability business cần. Nếu team có thể bảo vệ một planning horizon ngắn, Scrum có thể cho một nhịp hữu ích. Nếu công việc đi vào liên tục và nỗi đau chính là chờ đợi, quá tải, blocker và flow bị nghẽn, Kanban có thể hợp hơn. Nếu cả hai cùng đúng, mượn cẩn thận từ cả hai không phải thất bại. Có thể đó chỉ là team đang học cách mô tả công việc thật của mình rõ hơn.
Lần tới khi một board trông rối, tôi sẽ không bắt đầu bằng câu hỏi team đang làm Scrum hay Kanban đúng chưa. Tôi sẽ hỏi công việc đang chờ ở đâu, ai kiểm soát intake, đang có bao nhiêu việc in progress, và team đang cố đưa ra lời hứa nào. Những câu hỏi đó thường dẫn tới một câu trả lời bình tĩnh hơn cái nhãn. Nếu team bạn từng sống qua cả hai nhịp, câu chuyện hữu ích nhất đôi khi không phải bên nào thắng, mà là điều gì đã đổi khi process cuối cùng khớp với công việc.