Mở đầu — vì sao bài này quan trọng
Nếu bạn hỏi mười nhà tuyển dụng ở Việt Nam đang tìm Project Manager hoặc Scrum Master rằng ứng viên cần biết framework Agile nào nhất, có lẽ chín người sẽ trả lời: Scrum. Trong kỳ thi PMP, Scrum cũng chiếm phần lớn số câu hỏi thuộc nhóm "Adaptive/Agile" — mà theo cấu trúc đề hiện tại, khoảng một nửa số câu mang màu sắc Agile hoặc Hybrid. Nói cách khác, nếu bạn mơ hồ về Scrum, bạn đang tự nguyện bỏ trắng một mảng rất lớn của bài thi.
Nhưng Scrum không chỉ là chuyện thi cử. Đây là framework mà bạn sẽ gặp trực tiếp khi làm việc: từ các công ty phần mềm như FPT Software, VNG, Tiki cho đến những đội sản phẩm nhỏ ở startup. Nhiều người "làm Scrum" nhưng thực chất chỉ đang làm "họp đứng mỗi sáng và có cái bảng dán giấy". Bài này giúp bạn hiểu Scrum ở tầng nguyên lý — vì sao nó được thiết kế như vậy, mỗi vai trò và sự kiện tồn tại để giải quyết vấn đề gì — thay vì học thuộc lòng máy móc.
Điều quan trọng cần khắc cốt ghi tâm ngay từ đầu: Scrum là một framework, không phải một phương pháp luận đầy đủ. Nó cố tình để trống rất nhiều chỗ để bạn tự lấp bằng thực hành phù hợp với bối cảnh. Đây chính là lý do trong PMP, câu trả lời đúng thường là "để nhóm tự quyết định" chứ không phải "PM ra lệnh".
Khái niệm cốt lõi
Scrum được định nghĩa chính thức trong tài liệu The Scrum Guide (bản cập nhật 2020, do Ken Schwaber và Jeff Sutherland biên soạn). Toàn bộ framework dựng trên trụ cột là chủ nghĩa kinh nghiệm (empiricism): chúng ta ra quyết định dựa trên những gì đã quan sát được, không dựa trên kế hoạch giả định từ đầu. Ba trụ cột của empiricism là Transparency (Minh bạch), Inspection (Kiểm tra) và Adaptation (Thích nghi).
Ngoài ra Scrum có 5 giá trị: Commitment (Cam kết), Focus (Tập trung), Openness (Cởi mở), Respect (Tôn trọng) và Courage (Dũng cảm). Kỳ thi PMP rất thích hỏi về những giá trị này dưới dạng tình huống hành vi.
Ba vai trò (Accountabilities)
Bản Scrum Guide 2020 gọi đây là "accountabilities" (trách nhiệm giải trình) chứ không còn dùng từ "roles". Toàn bộ nhóm gọi là Scrum Team, thường 10 người trở xuống, không có nhóm con hay cấp bậc.
Product Owner (PO) — người chịu trách nhiệm tối đa hóa giá trị của sản phẩm. PO sở hữu Product Backlog: quyết định các hạng mục là gì, sắp xếp thứ tự ưu tiên, đảm bảo backlog minh bạch và ai cũng hiểu. Điểm mấu chốt PMP hay bẫy: PO là một người duy nhất, không phải một hội đồng. PO có thể ủy quyền công việc nhưng vẫn là người chịu trách nhiệm cuối cùng. PO là tiếng nói của khách hàng và của giá trị kinh doanh.
Scrum Master (SM) — không phải "sếp" của nhóm, mà là một servant leader (lãnh đạo phục vụ). SM chịu trách nhiệm để Scrum được hiểu và áp dụng đúng. Ba hướng phục vụ: phục vụ nhóm Developers (coaching về tự tổ chức, gỡ impediment — trở ngại), phục vụ PO (giúp quản lý backlog hiệu quả), và phục vụ tổ chức (dẫn dắt thay đổi, huấn luyện áp dụng Scrum). SM không giao việc, không ước lượng thay nhóm, không ép tiến độ.
Developers — những người thực sự tạo ra Increment mỗi Sprint. "Developer" ở đây nghĩa rộng: có thể là lập trình viên, tester, designer, business analyst — bất kỳ ai đóng góp trực tiếp vào sản phẩm. Nhóm này tự tổ chức (self-managing): tự quyết ai làm gì, làm như thế nào, và tự ước lượng khối lượng công việc. Không ai từ bên ngoài được ra lệnh cho họ cách biến backlog thành Increment.
Các Artifact (tạo phẩm)
Scrum có đúng 3 artifact, mỗi cái gắn với một commitment để tăng tính minh bạch:
- Product Backlog — danh sách sắp thứ tự tất cả những gì cần có cho sản phẩm. Commitment gắn với nó là Product Goal (mục tiêu sản phẩm dài hạn).
- Sprint Backlog — gồm Sprint Goal + các hạng mục chọn cho Sprint + kế hoạch thực hiện. Commitment là Sprint Goal.
- Increment — bước tiến cụ thể hướng tới Product Goal, đã hoàn thiện và có thể sử dụng được. Commitment là Definition of Done (DoD) — tiêu chuẩn chất lượng để một hạng mục được coi là "xong". Nếu chưa đạt DoD thì không được đưa vào Increment.
Các sự kiện (Events)
Trái tim của Scrum là Sprint — một chu kỳ ngắn cố định, thường 1–4 tuần (phổ biến nhất là 2 tuần). Sprint mới bắt đầu ngay sau khi Sprint trước kết thúc, không có khoảng nghỉ. Bên trong Sprint có 4 sự kiện:
- Sprint Planning — mở đầu Sprint, cả nhóm cùng trả lời: Sprint này vì sao có giá trị (Sprint Goal), có thể làm được gì, và làm thế nào.
- Daily Scrum — 15 phút mỗi ngày, do Developers thực hiện, để kiểm tra tiến độ hướng tới Sprint Goal và điều chỉnh kế hoạch ngày. Đây không phải buổi báo cáo cho sếp.
- Sprint Review — cuối Sprint, nhóm trình bày Increment cho stakeholder, thu thập phản hồi, điều chỉnh Product Backlog. Đây là buổi làm việc, không phải buổi "demo trang trọng".
- Sprint Retrospective — sự kiện cuối cùng, nhóm nhìn lại cách làm việc (con người, quan hệ, quy trình, công cụ) để cải tiến. Đây chính là động cơ cải tiến liên tục của Scrum.
Tình huống thực tế
Ví dụ 1 — Đội sản phẩm tại một fintech ở TP.HCM lẫn lộn vai trò
Một công ty fintech giả định tên MoMoPay có đội 8 người phát triển ví điện tử. Trên danh nghĩa họ "làm Scrum" nhưng Trưởng phòng Kỹ thuật kiêm luôn cả ba vai: vừa quyết backlog, vừa chủ trì Daily, vừa giao việc cho từng lập trình viên trong buổi họp sáng. Kết quả: Developers thụ động, chỉ chờ được giao việc; velocity (tốc độ hoàn thành) dao động thất thường; và mỗi khi có bug, không ai thấy mình chịu trách nhiệm.
Khi thuê một Scrum Master thật sự, việc đầu tiên anh làm là tách bạch trách nhiệm: Trưởng phòng lùi về đúng vai PO, tập trung ưu tiên backlog theo giá trị kinh doanh; Daily Scrum trả lại cho Developers tự điều phối; SM tập trung gỡ trở ngại (ví dụ: xin quyền truy cập môi trường test mất 3 ngày mỗi lần). Sau 4 Sprint, velocity ổn định hơn hẳn và nhóm bắt đầu tự đề xuất giải pháp.
Bài học: Gom nhiều vai vào một người là lỗi phổ biến nhất ở Việt Nam. Scrum cố tình tách vai để tạo đối trọng lành mạnh — PO đẩy về giá trị, Developers giữ tính khả thi, SM giữ đúng cách làm.
Ví dụ 2 — Sprint Review biến thành buổi "nghiệm thu" cứng nhắc
Một đội của FPT Software làm outsourcing cho khách hàng Nhật tổ chức Sprint Review như một buổi lễ: chuẩn bị slide cả tuần, chỉ trình bày phần "đẹp", giấu những chỗ chưa xong. Khách hàng ngồi nghe, gật đầu, rồi ba tháng sau mới phát hiện sản phẩm lệch hướng và yêu cầu làm lại một mảng lớn — thiệt hại ước tính hàng trăm giờ công.
Vấn đề nằm ở chỗ họ hiểu sai bản chất Sprint Review. Review đúng nghĩa là buổi làm việc cộng tác: đưa Increment thật (đã đạt Definition of Done) ra để stakeholder dùng thử và phản hồi thẳng thắn, kể cả phản hồi tiêu cực. Khi đội chuyển sang trình bày cả phần chưa đạt và chủ động hỏi "chỗ này có đúng ý anh không?", họ phát hiện lệch hướng sớm hơn nhiều Sprint, tiết kiệm được khối lượng làm lại đáng kể.
Bài học: Minh bạch (Transparency) không phải khẩu hiệu. Che giấu để "trông đẹp" phá vỡ chính cơ chế inspection–adaptation làm nên giá trị của Scrum.
Ví dụ 3 — Retrospective hình thức tại một startup e-commerce
Một startup thương mại điện tử ở Hà Nội có tổ chức Retrospective nhưng lần nào cũng kết thúc bằng câu chung chung "lần sau cố gắng hơn", không có hành động cụ thể. Ba Sprint liên tiếp cùng một vấn đề — code review bị dồn đến cuối Sprint gây nghẽn — vẫn tái diễn.
SM thay đổi cách làm: mỗi Retrospective phải chốt tối đa 1–2 hành động cải tiến cụ thể, có người phụ trách, và đưa thẳng vào Sprint Backlog kế tiếp như một hạng mục thật sự. Vấn đề code review được giải quyết bằng quy tắc "review trong vòng 4 giờ sau khi tạo pull request", và SM theo dõi ở Retro sau. Sau hai Sprint, tình trạng nghẽn cuối Sprint gần như biến mất.
Bài học: Retrospective mà không sinh ra hành động cụ thể, đo lường được, thì chỉ là buổi than phiền tập thể. Cải tiến liên tục phải cụ thể hóa thành công việc.
Hướng dẫn từng bước
Nếu bạn phải khởi động Scrum cho một đội mới (và cũng là khung tư duy để trả lời câu hỏi tình huống PMP), hãy làm theo trình tự:
- Xác định 3 accountability rõ ràng. Một PO duy nhất, một SM, và nhóm Developers. Viết ra ai chịu trách nhiệm gì, đặc biệt nhấn mạnh PO không kiêm SM.
- Cùng nhau lập Product Backlog và Product Goal. PO sắp thứ tự theo giá trị. Đảm bảo mỗi hạng mục đủ rõ để nhóm hiểu.
- Thống nhất Definition of Done. Cả nhóm cùng viết tiêu chuẩn "xong" — ví dụ: đã code, đã test, đã review, đã tích hợp, đã cập nhật tài liệu. DoD là hàng rào chất lượng chung.
- Chọn độ dài Sprint và giữ cố định. Với đội mới, 2 tuần là lựa chọn an toàn để có nhịp phản hồi đủ nhanh.
- Chạy Sprint Planning. Trả lời ba câu: Vì sao (Sprint Goal), Cái gì (chọn hạng mục), Thế nào (kế hoạch). Kết quả là Sprint Backlog.
- Duy trì Daily Scrum 15 phút mỗi ngày do Developers chủ trì, hướng vào Sprint Goal.
- Kết thúc bằng Sprint Review (kiểm tra sản phẩm với stakeholder) rồi Retrospective (cải tiến cách làm). Đưa hành động cải tiến vào Sprint sau.
- Lặp lại, đo velocity qua nhiều Sprint để dự báo, không kỳ vọng chuẩn ngay từ Sprint đầu.
Lỗi thường gặp & mẹo
- Coi Scrum Master là quản lý dự án hay "trưởng nhóm". SM là servant leader, không giao việc, không đánh giá KPI cá nhân. Trong PMP, đáp án "SM ra lệnh cho nhóm" gần như luôn sai.
- Product Owner là một hội đồng. Sai. PO phải là một người có quyền quyết cuối cùng, nếu không backlog sẽ bị giằng co.
- Thay đổi độ dài Sprint hoặc phạm vi giữa chừng để kịp deadline. Scrum không cho gia hạn Sprint. Nếu không kịp, hạng mục quay lại backlog cho Sprint sau; chỉ PO mới được hủy Sprint (khi Sprint Goal lỗi thời).
- Daily Scrum thành buổi báo cáo cho sếp. Đây là buổi của Developers để tự điều chỉnh kế hoạch, không phải để "trình diện".
- Bỏ qua Retrospective khi bận. Đây chính là sự kiện dễ bị cắt nhất nhưng lại là động cơ cải tiến. Bỏ nó là bỏ luôn khả năng tự tốt lên.
- Nhầm Definition of Done với Acceptance Criteria. DoD áp cho toàn bộ Increment (chất lượng chung); acceptance criteria riêng cho từng hạng mục (chi tiết ở bài User Stories).
- Mẹo thi PMP: khi gặp câu hỏi "PM/SM nên làm gì?", ưu tiên các đáp án thể hiện tạo điều kiện, huấn luyện, để nhóm tự quyết, gỡ trở ngại — tránh các đáp án mang tính ra lệnh, kiểm soát vi mô.
Bài tập thực hành
- Phân vai: Lấy một đội bạn từng làm (hoặc giả định). Liệt kê ai đang đảm nhận PO, SM, Developers. Có ai đang kiêm hai vai gây xung đột không? Đề xuất cách tách.
- Viết Definition of Done: Soạn một DoD gồm 5–7 tiêu chí cho một tính năng phần mềm cụ thể (ví dụ: chức năng đăng nhập). Phân biệt rõ với acceptance criteria của riêng tính năng đó.
- Sửa sự kiện lỗi: Cho tình huống — "Daily Scrum kéo dài 45 phút vì mọi người báo cáo chi tiết cho quản lý". Chỉ ra ba điều sai và cách khắc phục.
- Câu hỏi kiểu PMP: "Giữa Sprint, khách hàng yêu cầu thêm một tính năng gấp. Developers đã kín việc. SM nên làm gì?" Hãy chọn hướng xử lý đúng tinh thần Scrum và giải thích (gợi ý: liên quan tới PO, backlog, và tính bất khả xâm phạm của Sprint Goal).
Tóm tắt
Scrum là một framework nhẹ dựa trên chủ nghĩa kinh nghiệm: minh bạch, kiểm tra, thích nghi. Nó có 3 accountability (Product Owner sở hữu giá trị và backlog; Scrum Master phục vụ và gỡ trở ngại; Developers tự tổ chức để tạo Increment), 3 artifact (Product Backlog, Sprint Backlog, Increment — mỗi cái gắn một commitment: Product Goal, Sprint Goal, Definition of Done), và 5 sự kiện trong khung bao là Sprint (Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective).
Điều làm nên sức mạnh của Scrum không nằm ở các buổi họp, mà ở nguyên lý phía sau: tách vai để tạo đối trọng lành mạnh, minh bạch tuyệt đối để phát hiện lệch hướng sớm, và cải tiến liên tục qua Retrospective. Trong PMP, hãy nhớ tinh thần servant leadership và trao quyền cho nhóm — đó thường là kim chỉ nam dẫn tới đáp án đúng. Còn trong thực tế, hãy tránh cái bẫy "làm Scrum hình thức" mà ba ví dụ trên đã minh họa.