Mở đầu — vì sao bài này quan trọng
Nếu Practice Set 1 đã giúp bạn làm quen với "ngôn ngữ" của đề thi PSM II, thì Practice Set 2 nâng độ khó lên một bậc: các tình huống trong bộ đề này không còn dừng ở "Scrum Master nên làm gì" theo kiểu lý thuyết, mà buộc bạn phải phân biệt giữa nhiều phương án đều "nghe có vẻ đúng". Đây chính là cái bẫy lớn nhất của PSM II. Người ra đề của Scrum.org cố tình thiết kế các đáp án sai theo kiểu "đúng một nửa" — đúng về ý định nhưng sai về cách tiếp cận, hoặc đúng về cách tiếp cận nhưng sai về vai trò.
Trong thực tế làm nghề ở Việt Nam, tôi gặp rất nhiều Scrum Master đã pass PSM I dễ dàng nhưng trượt PSM II tới hai, ba lần. Lý do gần như luôn giống nhau: họ trả lời theo bản năng "người-giải-quyết-vấn-đề" thay vì theo tư duy "người-tạo-điều-kiện" (facilitator) và "người-khai-vấn" (coach). PSM II kiểm tra xem bạn có thực sự sống với tinh thần servant leadership hay không, chứ không kiểm tra bạn thuộc bao nhiêu định nghĩa.
Bài học này sẽ đưa bạn qua một loạt scenario điển hình của Practice Set 2, mổ xẻ từng phương án, chỉ ra vì sao một đáp án đúng và các đáp án kia sai. Mục tiêu không chỉ là để bạn chọn đúng trong phòng thi, mà để bạn hình thành phản xạ ra quyết định đúng khi đứng trước team thật. Đây là sự khác biệt cốt lõi giữa người học để thi và người học để hành nghề.
Khái niệm cốt lõi
Ba "trục" tư duy để giải mọi scenario PSM II
Trước khi đi vào từng câu, bạn cần nắm ba trục tư duy mà tôi luôn dùng để "lọc" đáp án. Khi đọc một scenario, hãy chiếu nó qua ba trục này:
Trục 1 — Ai sở hữu vấn đề (ownership)? Scrum Master không sở hữu chất lượng sản phẩm (đó là của Developers), không sở hữu giá trị sản phẩm (đó là của Product Owner), không sở hữu cách team tự tổ chức. Khi một đáp án khiến Scrum Master "giành" quyền sở hữu của người khác — ví dụ tự quyết định action item, tự phân công công việc — đáp án đó gần như chắc chắn sai.
Trục 2 — Hành động này củng cố hay làm xói mòn tính tự quản (self-management)? Đáp án đúng của PSM II hầu như luôn là đáp án giúp team tự nhận ra vấn đề và tự chọn cách giải quyết, thay vì để Scrum Master làm thay. Một đáp án "hiệu quả nhanh" nhưng làm team phụ thuộc vào Scrum Master là đáp án sai.
Trục 3 — Đây là vấn đề bề mặt (symptom) hay gốc rễ (root cause)? PSM II rất thích các tình huống mà triệu chứng lặp đi lặp lại. Câu trả lời "xử lý triệu chứng" luôn là bẫy; câu trả lời "giúp team khám phá nguyên nhân gốc" mới là đáp án đúng.
Bốn nhóm đáp án nhiễu (distractor) hay gặp
Qua kinh nghiệm luyện thi cho nhiều học viên, tôi nhận thấy đáp án sai trong PSM II thường rơi vào bốn nhóm sau:
- Nhóm "né tránh": bỏ qua sự kiện, bỏ qua vấn đề, ví dụ "Bỏ Retrospective đi". Đây luôn sai vì nó loại bỏ cơ hội thanh tra và thích nghi (inspect & adapt).
- Nhóm "ra lệnh": Scrum Master tự quyết, tự ép. Sai vì phá self-management.
- Nhóm "leo thang sớm": vội vàng báo cáo lên management hoặc HR khi vấn đề còn có thể giải quyết trong team. Sai vì bỏ qua bước facilitation.
- Nhóm "đúng nhưng không phải việc của SM ngay lúc này": ví dụ tự viết lại Definition of Done. Nghe hợp lý nhưng vi phạm trục ownership.
Tình huống thực tế
Scenario 1 — Retrospective vô hiệu lực: action item lặp lại nhưng không bao giờ làm
Bối cảnh. Đây là scenario mở đầu của Practice Set 2, và cũng là tình huống tôi gặp nhiều nhất ngoài đời. Hãy hình dung một team 7 người tại một công ty fintech ở TP.HCM — gọi là FinUp. Suốt 5 Sprint liên tiếp, mỗi buổi Sprint Retrospective team đều ghi ra cùng những action item: "viết test sớm hơn", "code review nhanh hơn", "giảm họp ngắt quãng". Nhưng Sprint sau, không một action item nào được thực hiện. Cả team bắt đầu chán, có người nói thẳng: "Họp Retro làm gì cho mất thời gian, có thay đổi được đâu."
Câu hỏi đặt ra: Là Scrum Master, cách tiếp cận tốt nhất là gì?
- A. Bỏ các buổi Retrospective vì chúng không tạo ra giá trị.
- B. Tạo điều kiện để team khám phá vì sao các action item trước không được thực hiện, và cùng team chọn ra một (chỉ một) cải tiến khả thi nhất để đưa vào Sprint Backlog kế tiếp.
- C. Tự Scrum Master phân công từng action item cho từng người và theo dõi để đảm bảo hoàn thành.
- D. Báo cáo team lên quản lý cấp trên vì họ thiếu kỷ luật.
Đáp án đúng là B. Mấu chốt nằm ở chỗ: vấn đề thật không phải là "action item không được làm" mà là "vì sao chúng không được làm". Có thể vì team chọn quá nhiều action item một lúc, có thể vì các action item không được đưa vào Sprint Backlog nên vô hình, có thể vì không ai cảm thấy sở hữu chúng. Scrum Master cần facilitation để team tự khám phá nguyên nhân gốc, rồi giúp team cam kết một cải tiến duy nhất, cụ thể, đưa thẳng vào Sprint Backlog tới để nó hiện diện như công việc thật.
Bài học rút ra. Cải tiến chỉ thành sự thật khi nó được đối xử như công việc — tức là vào Sprint Backlog, có người quan tâm, có thể nhìn thấy trên board. "Một cải tiến được làm xong" có giá trị hơn "mười cải tiến được ghi ra rồi quên".
Scenario 2 — Developer "ngôi sao" tự nhận hết việc khó
Bối cảnh. Tại một công ty thương mại điện tử ở Hà Nội — gọi là ShopNhanh — có một Developer kỳ cựu tên Tuấn, giỏi nhất team. Mỗi Sprint Planning, Tuấn tự nhận hết các Product Backlog Item khó nhất vì "để người khác làm thì chậm và dễ lỗi". Kết quả: Tuấn luôn quá tải, các thành viên khác không có cơ hội học, và mỗi khi Tuấn nghỉ phép thì velocity của team rớt thê thảm. Đây là tình huống "single point of failure" kinh điển.
Câu hỏi: Scrum Master nên làm gì?
- A. Để yên, vì team đang giao hàng đúng hạn và Tuấn vui vẻ với việc đó.
- B. Yêu cầu Tuấn ngừng nhận việc khó và bắt buộc chia việc cho người khác.
- C. Giúp team nhìn thấy rủi ro phụ thuộc vào một người (ví dụ qua một hoạt động trong Retrospective hoặc dùng dữ liệu khi Tuấn vắng mặt), để chính team quyết định cách lan tỏa kiến thức.
- D. Báo Product Owner để PO giảm độ phức tạp của các hạng mục backlog.
Đáp án đúng là C. Vai trò Scrum Master ở đây là làm cho rủi ro trở nên hữu hình để team tự thấy. Bạn có thể đưa ra một con số: "Sprint vừa rồi Tuấn nghỉ 3 ngày, velocity giảm 40%." Khi team nhìn thấy dữ liệu, họ sẽ tự đề xuất giải pháp — có thể là pair programming, có thể là luân phiên người nhận task khó, có thể là chia sẻ kiến thức định kỳ. Điều quan trọng là quyết định đến từ team, không phải mệnh lệnh từ bạn.
Bài học rút ra. Khi muốn thay đổi hành vi của team, đừng ra lệnh — hãy làm cho hệ quả của hành vi hiện tại trở nên rõ ràng. Con người thay đổi vì họ tự thấy lý do, không phải vì bị bảo phải thay đổi.
Scenario 3 — Product Owner vắng mặt, team tự "đoán" yêu cầu
Bối cảnh. Một startup giao đồ ăn ở Đông Nam Á — gọi là FoodGo — có Product Owner là người đồng sáng lập, cực kỳ bận. PO gần như không tham gia Sprint Planning, không cập nhật Product Backlog, và thường chỉ xuất hiện ở Sprint Review để... phê bình rằng "đây không phải thứ tôi muốn". Developers bắt đầu tự suy đoán yêu cầu để có việc mà làm, dẫn đến rework liên tục. Tinh thần team đi xuống nhanh.
Câu hỏi: Cách tiếp cận tốt nhất của Scrum Master?
- A. Để một Developer cao cấp đóng vai PO thay thế trong các buổi họp.
- B. Tự Scrum Master sắp xếp lại và ưu tiên Product Backlog giúp PO.
- C. Làm rõ với PO (và nếu cần, với cả tổ chức) tác động thực tế của việc PO vắng mặt — đo bằng lượng rework, giá trị bị lãng phí — và giúp PO hiểu trách nhiệm cũng như tìm cách để PO thực thi vai trò hiệu quả hơn.
- D. Chấp nhận thực tế và tập trung giúp Developers đoán yêu cầu chính xác hơn.
Đáp án đúng là C. Scrum Master phục vụ Product Owner bằng cách giúp họ hiểu và thực thi vai trò hiệu quả. Ở đây, công cụ mạnh nhất là dữ liệu: "Ba Sprint qua, 35% công việc bị làm lại vì hiểu sai yêu cầu — tương đương khoảng 12 ngày công lãng phí." Khi một nhà sáng lập bận rộn nhìn thấy con số lãng phí cụ thể, họ thường thay đổi ưu tiên. Nếu cá nhân PO vẫn không thể cải thiện, Scrum Master có quyền và trách nhiệm làm việc với tổ chức về tầm quan trọng của vai trò PO — nhưng đây là bước sau, không phải bước đầu.
Bài học rút ra. Khi một vai trò trong Scrum không được thực thi đầy đủ, giải pháp không bao giờ là "ai đó làm thay" mà là "giúp người đó thực thi được vai trò của mình". Làm thay là cách nhanh nhất để vấn đề trở nên mãn tính.
Hướng dẫn từng bước
Đây là quy trình bốn bước tôi khuyên bạn áp dụng cho mọi câu hỏi tình huống trong PSM II Practice Set 2. Luyện đến khi nó thành phản xạ:
Bước 1 — Đọc kỹ và xác định "triệu chứng vs gốc rễ". Gạch chân triệu chứng được mô tả (ví dụ: action item không được làm). Tự hỏi: "Đề đang mô tả vấn đề bề mặt hay nguyên nhân?" Hầu như luôn là bề mặt. Đáp án đúng sẽ hướng tới gốc rễ.
Bước 2 — Loại ngay các đáp án thuộc bốn nhóm nhiễu. Quét nhanh: có đáp án nào "né tránh/bỏ sự kiện"? Loại. Có đáp án nào Scrum Master "ra lệnh/làm thay"? Loại. Có đáp án nào "leo thang lên management/HR" khi vấn đề còn xử lý được trong team? Thường loại. Sau bước này, bạn thường chỉ còn một hoặc hai phương án.
Bước 3 — Áp ba trục tư duy lên các đáp án còn lại. Hỏi: đáp án này có tôn trọng ownership của từng vai trò không? Có củng cố self-management không? Có nhắm tới gốc rễ không? Đáp án trả lời "có" cho cả ba gần như chắc chắn là đáp án đúng.
Bước 4 — Kiểm tra "ngữ điệu servant leadership". Đọc lại đáp án và hỏi: nó nghe giống một người tạo điều kiện hay một người kiểm soát? PSM II ưu tiên động từ như "giúp team khám phá", "tạo điều kiện", "làm rõ tác động", "huấn luyện". Nó tránh những động từ như "yêu cầu", "ép buộc", "phân công", "quyết định thay".
Một mẹo về quản lý thời gian: PSM II có 80 câu trong 60 phút, tức trung bình 45 giây mỗi câu. Với scenario dài, đừng đọc đi đọc lại từng từ — hãy đọc một lần, áp quy trình bốn bước, chọn, đánh dấu nếu phân vân, và quay lại sau. Đừng để một câu khó ngốn mất thời gian của năm câu dễ.
Lỗi thường gặp & mẹo
Lỗi 1 — Chọn đáp án "hiệu quả nhất trong ngắn hạn". Nhiều học viên chọn phương án giải quyết vấn đề nhanh nhất, ví dụ Scrum Master tự phân công action item. Nhanh thật, nhưng PSM II không thưởng cho tốc độ — nó thưởng cho tính bền vững và sự trao quyền. Hãy luôn ưu tiên đáp án giúp team mạnh lên lâu dài.
Lỗi 2 — Nhầm "phục vụ" với "làm thay". Servant leadership không có nghĩa là Scrum Master gánh hết việc khó. Phục vụ team đôi khi là không làm gì cả để team tự xoay xở, hoặc chỉ đặt một câu hỏi đúng lúc. Khi đáp án có dạng "Scrum Master tự làm X giúp team", hãy cảnh giác.
Lỗi 3 — Leo thang quá sớm. Có một thứ tự ưu tiên ngầm trong Scrum: trong team trước, rồi mới tới tổ chức. Đáp án "báo cáo lên sếp/HR ngay" hầu như luôn sai trừ khi đề mô tả rõ vấn đề đã vượt khỏi tầm team (ví dụ rào cản tổ chức mang tính chính sách).
Lỗi 4 — Quên rằng các sự kiện Scrum là bất biến. Bất kỳ đáp án nào đề xuất bỏ một sự kiện (Daily Scrum, Retrospective, Review) đều sai. Sự kiện có thể được cải tiến cách tổ chức, nhưng không bị loại bỏ.
Mẹo vàng: Khi phân vân giữa hai đáp án còn lại, hãy chọn đáp án nào trao quyền cho team nhiều hơn và để Scrum Master can thiệp ít hơn. Trong 8/10 trường hợp, đó là đáp án đúng. PSM II về bản chất là bài kiểm tra xem bạn có dám "lùi lại một bước" để team tự lớn lên hay không.
Bài tập thực hành
Bài 1 — Tự giải scenario. Một team có Daily Scrum kéo dài 35 phút mỗi ngày, biến thành buổi báo cáo tiến độ cho Scrum Master. Hãy tự viết ra bốn phương án (một đúng, ba nhiễu thuộc ba nhóm khác nhau), rồi giải thích vì sao đáp án đúng. Gợi ý: gốc rễ thường là "Daily Scrum đang phục vụ ai".
Bài 2 — Mổ xẻ đáp án nhiễu. Quay lại Scenario 1 trong bài. Với mỗi đáp án sai (A, C, D), viết một câu ngắn nêu rõ nó thuộc nhóm nhiễu nào và vi phạm trục tư duy nào. Mục tiêu là rèn phản xạ nhận diện bẫy.
Bài 3 — Áp dụng vào team thật. Chọn một vấn đề lặp lại đang tồn tại trong team bạn ngoài đời. Áp quy trình bốn bước ở phần "Hướng dẫn từng bước" để phân tích: đâu là triệu chứng, đâu là gốc rễ, bạn nên tạo điều kiện thế nào thay vì giải quyết thay. Viết ra hành động cụ thể bạn sẽ thử trong Sprint tới.
Bài 4 — Bấm giờ. Tự đặt 10 câu scenario (lấy từ ngân hàng đề Open Assessment của Scrum.org hoặc tự chế theo mẫu trên), giải trong 8 phút. Sau đó rà lại những câu sai và phân loại lỗi theo bốn nhóm ở phần "Lỗi thường gặp". Lặp lại đến khi tỷ lệ đúng ổn định trên 90%.
Tóm tắt
Practice Set 2 không kiểm tra trí nhớ của bạn về Scrum Guide — nó kiểm tra bản năng ra quyết định của bạn như một servant leader. Toàn bộ bài học này có thể gói gọn trong vài nguyên tắc: luôn phân biệt triệu chứng và gốc rễ; loại ngay các đáp án "né tránh, ra lệnh, leo thang sớm, làm thay"; và khi phân vân, chọn đáp án trao quyền cho team nhiều nhất, để Scrum Master can thiệp ít nhất.
Ba scenario ta đã đi qua — Retrospective vô hiệu lực, Developer ngôi sao gây single-point-of-failure, và Product Owner vắng mặt — đều quy về cùng một bài học cốt lõi: vai trò của bạn là làm cho vấn đề trở nên hữu hình và tạo điều kiện để đúng người, đúng vai trò tự giải quyết nó. Bạn không phải người hùng giải cứu team; bạn là người giúp team tự trở nên mạnh đến mức không cần được giải cứu.
Hãy luyện quy trình bốn bước cho đến khi nó tự động chạy trong đầu bạn. Khi đó, bạn không chỉ vượt qua PSM II trong phòng thi, mà còn ra quyết định đúng mỗi ngày khi đứng trước một team thật, với những con người thật và những vấn đề thật. Đó mới là đích đến cuối cùng của hành trình này.