Mở đầu — vì sao bài này quan trọng
Bạn đã đi qua hai bộ luyện đề trước. Đến Practice Set 3 này, độ khó được nâng lên một bậc: các tình huống không còn xoay quanh một team đơn lẻ nữa, mà bắt đầu chạm tới những vấn đề mang tính tổ chức — nhiều team làm việc song song, sự trùng lặp nỗ lực giữa các nhóm, ranh giới trách nhiệm giữa Scrum Master với quản lý cấp trung, và những tình huống mà "câu trả lời đúng theo lý thuyết" lại va chạm với "câu trả lời sống sót được trong thực tế công ty Việt Nam".
Đề thi PSM II của Scrum.org nổi tiếng là dạng đề "chọn câu ít sai nhất" — cả bốn đáp án nghe đều hợp lý, và điểm khác biệt nằm ở việc bạn có giữ vững tinh thần Scrum (empiricism, self-management, servant leadership) hay không khi bị áp lực. Rất nhiều người trượt PSM II không phải vì thiếu kiến thức, mà vì khi đọc câu hỏi tình huống, họ chọn theo bản năng "Scrum Master phải đứng ra giải quyết", thay vì để team tự giải quyết.
Bài này là một bộ luyện đề có lời giải sâu. Mỗi câu hỏi tôi sẽ không chỉ nói đáp án đúng, mà còn mổ xẻ vì sao các đáp án còn lại sai, và bẫy tâm lý ẩn sau chúng. Mục tiêu không phải để bạn thuộc lòng đáp án, mà để bạn rèn được "phản xạ tư duy Scrum Master cấp PSM II".
Khái niệm cốt lõi
Trước khi vào đề, hãy ghim lại bốn nguyên tắc lọc đáp án mà bạn nên áp dụng cho mọi câu hỏi tình huống trong Practice Set này — và cả trong kỳ thi thật.
Nguyên tắc 1 — Self-management là mặc định, không phải ngoại lệ
Khi một tình huống có thể được giải quyết bởi chính team (hoặc bởi nhiều team tự phối hợp với nhau), thì đáp án đúng gần như luôn là đáp án giúp team tự giải quyết, chứ không phải đáp án mà Scrum Master hoặc quản lý đứng ra quyết hộ. Bẫy phổ biến nhất ở PSM II là đáp án dạng "Scrum Master assigns…", "The manager decides…", "Escalate immediately to leadership". Những đáp án này thường sai vì chúng tước đi quyền tự quản của team.
Nguyên tắc 2 — Empiricism trước, giải pháp sau
Scrum vận hành trên ba trụ: transparency (minh bạch), inspection (kiểm tra), adaptation (thích nghi). Khi gặp một vấn đề mơ hồ, đáp án đúng thường là làm cho vấn đề trở nên minh bạch và tạo không gian để team kiểm tra–thích nghi, chứ không phải nhảy thẳng vào một giải pháp đóng gói sẵn. Nếu một đáp án bắt đầu bằng việc "áp một quy trình mới" mà chưa qua bước làm rõ vấn đề, hãy nghi ngờ nó.
Nguyên tắc 3 — Scrum Master tạo điều kiện, không ra lệnh
Scrum Master là servant leader. Vai trò là tạo môi trường, đặt câu hỏi mạnh, gỡ impediment, dạy và coach — chứ không phải là người ra quyết định kỹ thuật hay quản lý con người. Bất cứ đáp án nào biến Scrum Master thành "sếp" hay "người điều phối công việc" đều đáng ngờ.
Nguyên tắc 4 — Phối hợp giữa nhiều team là việc của các team, có Scrum Master làm cầu nối
Khi đề nói về nhiều team (multiple teams, adjacent products), nguyên tắc không đổi: để các team tự kết nối và đồng bộ với nhau. Scrum Master có thể tạo điều kiện cho cuộc trao đổi đó diễn ra — ví dụ tổ chức một buổi để hai team gặp nhau — nhưng không tự mình "gom việc" hay tự quyết thay cho họ.
Hãy giữ bốn nguyên tắc này trong đầu khi đọc các câu dưới đây.
Tình huống thực tế
Tôi sẽ trình bày ba scenario theo đúng phong cách đề PSM II: bối cảnh, bốn đáp án, sau đó diễn giải đáp án đúng và bài học.
Scenario 1 — Hai team trùng lặp nỗ lực
Bối cảnh: Tại Tiki, hai Scrum Master phụ trách hai sản phẩm liền kề (một team làm trang Tìm kiếm, một team làm trang Danh mục). Họ nhận thấy hai team đang giải quyết những vấn đề kỹ thuật rất giống nhau một cách độc lập — cả hai cùng tự viết một module cache riêng, cùng vật lộn với cùng một API chậm. Nỗ lực đang bị trùng lặp. Hành động tốt nhất là gì?
A. Chờ ban quản lý nhận ra và chỉ định một team đứng ra làm module dùng chung. B. Hai Scrum Master tự quyết định team nào sẽ làm module cache, rồi thông báo cho hai team. C. Tạo điều kiện để Developers của hai team gặp nhau, làm minh bạch sự trùng lặp, và để họ tự thống nhất cách phối hợp. D. Báo cáo lên CTO rằng các team đang lãng phí và đề nghị gộp hai team lại.
Đáp án đúng: C.
Diễn giải: Đây là tình huống kinh điển kiểm tra Nguyên tắc 1 và Nguyên tắc 4. Sự trùng lặp là một vấn đề có thật, nhưng nó là vấn đề của các Developers — những người hiểu rõ nhất kỹ thuật. Vai trò của Scrum Master là làm cho sự trùng lặp trở nên minh bạch và tạo không gian để hai team gặp nhau (Nguyên tắc 2 và 3), rồi để chính họ quyết định: dùng chung module, tách thư viện, hay cử người sang hỗ trợ nhau.
Vì sao các đáp án khác sai:
- A sai vì nó thụ động và đặt quyền quyết định vào tay quản lý — đi ngược self-management. "Chờ" cũng không phải hành động của một Scrum Master chủ động gỡ impediment.
- B sai vì hai Scrum Master đang ra quyết định kỹ thuật thay cho Developers. Đó là vượt quyền, biến Scrum Master thành người chỉ huy.
- D sai vì leo thang lên CTO khi vấn đề hoàn toàn có thể giải quyết ở cấp team, và đề xuất gộp team là một quyết định tổ chức nặng nề, vội vàng, không cần thiết.
Scenario 2 — Quản lý muốn dùng velocity để đánh giá nhân viên
Bối cảnh: Tại một công ty fintech ở TP.HCM, một Engineering Manager đến gặp Scrum Master và nói: "Tôi muốn dùng velocity của từng người trong team để xếp loại hiệu suất cuối quý. Anh gửi tôi số story points mỗi người hoàn thành mỗi Sprint nhé." Velocity team đang ổn định ở mức khoảng 40 điểm/Sprint. Scrum Master nên phản ứng thế nào?
A. Cung cấp dữ liệu vì manager là cấp trên và có quyền yêu cầu. B. Từ chối thẳng và nói với manager rằng anh ta không hiểu gì về Agile. C. Coach manager về việc velocity là công cụ dự báo của cả team, không phải thước đo cá nhân; giải thích tác hại của việc dùng nó để đánh giá người, và cùng tìm cách đánh giá hiệu suất phù hợp hơn. D. Bí mật chia nhỏ số liệu cho manager nhưng dặn team đừng lo lắng.
Đáp án đúng: C.
Diễn giải: Đây là một impediment ở tầng tổ chức (organizational impediment) đội lốt một yêu cầu hành chính. Velocity là chỉ số dự báo (forecasting) của cả team, vốn dao động theo độ phức tạp công việc và cách team ước lượng. Dùng nó để chấm điểm cá nhân sẽ gây ra hành vi méo mó: thành viên thổi phồng story points, từ chối giúp đồng đội, né việc khó. Nó phá hủy chính sự an toàn và tinh thần tự quản mà Scrum cần.
Vai trò PSM II ở đây là coach và teach — không phải tuân lệnh, cũng không phải đối đầu. Scrum Master cần giúp manager thấy được tác hại và cùng tìm một cách đánh giá tốt hơn (ví dụ dựa trên đóng góp giá trị, sự hợp tác, năng lực phát triển).
Vì sao các đáp án khác sai:
- A sai vì tuân thủ một cách mù quáng một yêu cầu gây hại cho team. Servant leadership không có nghĩa là phục tùng.
- B sai vì thái độ đối đầu, hạ thấp manager ("anh không hiểu gì") phá hủy quan hệ và cơ hội thay đổi. Scrum Master gây ảnh hưởng bằng coaching, không bằng buộc tội.
- D sai vì "bí mật" đi ngược hoàn toàn trụ cột transparency, và còn tệ hơn cả A vì nó vừa gây hại vừa lén lút.
Scenario 3 — Product Owner liên tục bỏ Sprint Review
Bối cảnh: Tại VNG, một Product Owner rất bận, ba Sprint Review gần nhất đều vắng mặt và nhờ Scrum Master "trình bày hộ" kết quả cho stakeholder. Stakeholder bắt đầu phàn nàn rằng họ không nhận được phản hồi rõ ràng về hướng sản phẩm. Scrum Master nên làm gì?
A. Tiếp tục trình bày hộ để Sprint Review không bị gián đoạn. B. Hủy Sprint Review cho tới khi nào PO có thời gian tham dự. C. Trao đổi riêng với PO để hiểu nguyên nhân vắng mặt, làm rõ vì sao sự có mặt của PO là thiết yếu cho việc thu thập phản hồi và điều chỉnh Product Backlog, và giúp PO gỡ rào cản để tham dự. D. Báo với stakeholder rằng PO không làm tròn vai trò và đề nghị thay PO.
Đáp án đúng: C.
Diễn giải: Sprint Review không phải buổi "báo cáo kết quả" — nó là sự kiện kiểm tra Increment và điều chỉnh Product Backlog dựa trên phản hồi của stakeholder. Người duy nhất chịu trách nhiệm về Product Backlog và việc tối đa hóa giá trị sản phẩm là Product Owner. Khi PO vắng mặt và Scrum Master trình bày hộ, buổi review mất đi giá trị thực: stakeholder không đối thoại được với người ra quyết định về sản phẩm.
Cách tiếp cận PSM II là đi tìm root cause (vì sao PO vắng) và coach PO về tầm quan trọng của sự hiện diện, đồng thời gỡ impediment giúp PO (có thể PO đang quá tải, bị kéo vào quá nhiều cuộc họp khác).
Vì sao các đáp án khác sai:
- A sai vì nó che giấu vấn đề và khiến Scrum Master lấn sang vai PO — một dạng "anti-pattern" làm tổ chức tưởng mọi thứ vẫn ổn.
- B sai vì hủy một sự kiện Scrum bắt buộc là cực đoan, và trừng phạt cả team lẫn stakeholder vì lỗi tham dự của một người.
- D sai vì đi sau lưng PO, phá hủy lòng tin, và quyết định nhân sự không thuộc thẩm quyền Scrum Master.
Hướng dẫn từng bước
Khi gặp một câu hỏi tình huống trong PSM II, hãy đi qua quy trình lọc sau — luyện đến khi nó thành phản xạ:
- Xác định ai sở hữu vấn đề. Vấn đề thuộc về Developers, về PO, về cả team, hay về tổ chức? Đáp án đúng thường trao quyền giải quyết cho đúng người sở hữu, chứ không chuyển nó sang Scrum Master.
- Loại ngay các đáp án "ra lệnh" và "leo thang vội". Gạch bỏ những đáp án có động từ kiểu "assign", "decide for them", "escalate immediately", "force", "report to leadership" khi vấn đề còn có thể giải quyết tại chỗ.
- Ưu tiên đáp án làm minh bạch vấn đề. Đáp án nào giúp transparency (đưa vấn đề ra ánh sáng, tạo không gian inspect–adapt) thường là đáp án đúng, hoặc là bước đầu đúng.
- Kiểm tra qua lăng kính servant leadership. Đáp án đúng để Scrum Master ở vai coach/facilitator/teacher, không phải vai sếp hay người gánh việc hộ.
- Chọn đáp án "ít can thiệp nhất mà vẫn tạo tiến triển". Scrum Master can thiệp tối thiểu cần thiết để team tự đi tiếp, không nhiều hơn.
- Đọc lại câu hỏi xem nó hỏi "now/first" hay "best". Nếu hỏi "hành động đầu tiên", chọn bước làm rõ/minh bạch. Nếu hỏi "tốt nhất về dài hạn", chọn đáp án coaching/gỡ root cause.
Lỗi thường gặp & mẹo
- Lỗi chọn "Scrum Master tự giải quyết". Bản năng nghề khiến nhiều người chọn đáp án mà Scrum Master đứng ra xử lý. Ở PSM II, đây thường là bẫy. Hỏi lại: ai mới thực sự nên giải quyết việc này?
- Lỗi nhầm "leo thang" với "chủ động". Báo lên sếp/CTO nghe có vẻ quyết liệt, nhưng leo thang khi chưa thử giải quyết ở cấp team là dấu hiệu Scrum Master né trách nhiệm coaching. Chỉ leo thang khi impediment thực sự vượt khả năng của team và Scrum Master.
- Lỗi chọn đáp án "đúng quy trình nhưng cứng nhắc". Ví dụ "hủy sự kiện", "ép tuân thủ luật Scrum". Scrum coi trọng tinh thần hơn là sự cứng nhắc về luật. Đáp án đúng thường mềm mỏng, tập trung vào con người.
- Mẹo đọc đáp án có chữ "và". Đáp án đúng ở dạng tình huống phức tạp thường ghép hai vế: "làm rõ nguyên nhân VÀ coach/gỡ rào cản". Đáp án sai thường chỉ có một vế hoặc nhảy thẳng tới giải pháp.
- Mẹo về thời gian. Đề PSM II có 30 câu trong 90 phút (1.5 giờ), pass mark 85%. Đừng sa lầy: gắn cờ câu khó, làm hết một lượt rồi quay lại. Trung bình bạn có khoảng 3 phút/câu — đủ để đọc kỹ nhưng không đủ để phân vân quá lâu.
- Mẹo loại trừ. Khi phân vân giữa hai đáp án, hãy tìm đáp án nào vi phạm một trong bốn nguyên tắc cốt lõi ở trên — loại nó đi, kể cả khi nó "nghe hay".
Bài tập thực hành
Hãy tự làm các câu sau, viết ra lý do chọn và lý do loại từng đáp án trước khi xem hướng giải ở cuối.
Câu A. Một team yêu cầu Scrum Master ngồi họp Daily Scrum để "giữ trật tự" vì mọi người hay lan man. Scrum Master nên?
- Điều hành Daily Scrum để đảm bảo đúng giờ.
- Coach team về mục đích Daily Scrum và giúp họ tự tìm cách giữ buổi họp tập trung, rồi rút lui dần.
- Bỏ Daily Scrum vì nó không hiệu quả.
- Báo manager rằng team thiếu kỷ luật.
- Mỗi Scrum Master tự lo cho team mình, không can thiệp việc team khác.
- Tạo điều kiện cho ba team cùng nhìn thấy dependency (ví dụ một buổi refinement/planning chung) và tự thống nhất cách phối hợp.
- Đề nghị một quản lý dự án điều phối tập trung mọi dependency.
- Gộp ba team thành một team lớn.
- Yêu cầu Developers thêm ngay vào Sprint hiện tại.
- Hướng stakeholder làm việc với Product Owner về Product Backlog và bảo vệ Sprint Goal đang chạy.
- Tự thêm item vào Sprint Backlog.
- Từ chối stakeholder và bảo họ chờ Sprint sau.
- Câu A: 2. Daily Scrum thuộc về Developers; Scrum Master coach rồi lùi ra, không điều hành thay (Nguyên tắc 1, 3).
- Câu B: 2. Dependency giữa nhiều team được giải quyết bằng minh bạch và để các team tự đồng bộ, không bằng điều phối tập trung hay gộp team (Nguyên tắc 4).
- Câu C: 2. PO sở hữu Product Backlog; quyết định thay đổi Sprint thuộc về team và phải tôn trọng Sprint Goal. Scrum Master định tuyến đúng người và bảo vệ tính tập trung của Sprint.
Tóm tắt
Practice Set 3 nâng độ khó lên tầng nhiều team và tầng tổ chức, nhưng cách giải vẫn quy về bốn nguyên tắc bất biến: self-management là mặc định, empiricism trước giải pháp, Scrum Master tạo điều kiện chứ không ra lệnh, và phối hợp đa team là việc của các team. Ba scenario — trùng lặp nỗ lực giữa hai team, manager đòi velocity cá nhân, PO bỏ Sprint Review — đều minh họa cùng một bài học: đừng gánh việc thay người khác, hãy làm minh bạch vấn đề và gỡ rào cản để đúng người tự giải quyết. Khi đứng trước một câu hỏi tình huống, hãy lọc đáp án bằng quy trình sáu bước, loại ngay các đáp án "ra lệnh" và "leo thang vội", rồi chọn đáp án ít can thiệp nhất mà vẫn tạo được tiến triển. Luyện đủ nhiều, phản xạ này sẽ tự bật lên trong phòng thi — và quan trọng hơn, ngay trong công việc thật của bạn.