Mở đầu — vì sao bài này quan trọng
Nếu bạn đã đi qua hơn bốn mươi bài học trước, bạn đã có trong tay một kho khái niệm: facilitation, coaching stance, diagnosis framework, organizational impediments, EBM, các framework scaling. Nhưng có một sự thật phũ phàng mà nhiều học viên Việt Nam vấp phải khi bước vào phòng thi PSM II của Scrum.org: biết khái niệm không đồng nghĩa với chọn đúng đáp án.
PSM II không kiểm tra việc bạn thuộc lòng Scrum Guide. Nó kiểm tra cách bạn ra quyết định trong tình huống mơ hồ. Đề thi hầu hết là dạng tình huống (scenario-based): cho bạn một bối cảnh nhóm, một mâu thuẫn, một áp lực từ bên ngoài, rồi hỏi "Scrum Master nên làm gì TIẾP THEO tốt nhất?". Bốn phương án đưa ra thường đều "nghe có vẻ đúng". Sự khác biệt giữa người đậu và người trượt nằm ở khả năng phân biệt giữa một hành động đúng và hành động đúng nhất theo tinh thần Scrum.
Bài này là bộ luyện đề số 1. Mục tiêu của tôi không phải đưa cho bạn đáp án rồi đi tiếp, mà là dạy bạn cách suy luận để khi gặp một câu hoàn toàn mới trong phòng thi thật, bạn vẫn chọn được. Chúng ta sẽ đi qua các scenario điển hình, mổ xẻ từng phương án, và quan trọng nhất là rút ra các nguyên tắc lọc đáp án lặp đi lặp lại trong toàn bộ đề PSM II.
Khái niệm cốt lõi
Tư duy "best next action" — không phải "đúng/sai"
Khác với PSM I (đa phần là true/false về Scrum Guide), PSM II buộc bạn chọn hành động tốt nhất tiếp theo. Điều này có nghĩa: trong bốn phương án, có thể có hai hoặc ba phương án "không sai", nhưng chỉ một phương án thể hiện đúng vai trò Scrum Master ở thời điểm đó. Bạn phải hỏi: "Việc gì nên làm trước? Việc gì giúp nhóm tự giải quyết thay vì tôi giải quyết hộ?".
Năm bộ lọc giúp loại đáp án sai
Qua hàng trăm câu hỏi, tôi tổng kết được năm bộ lọc mà bạn nên áp dụng theo thứ tự:
- Lọc "ra lệnh" (command-and-control): Bất kỳ phương án nào để Scrum Master ra lệnh, ép buộc, tăng commitment thay nhóm, quyết định thay Product Owner hay Developers — gần như luôn sai. Scrum Master là servant-leader, không phải sếp.
- Lọc "đi tìm dữ kiện trước khi hành động": Khi tình huống mơ hồ và bạn chưa biết nguyên nhân gốc, phương án đúng thường là quan sát, đặt câu hỏi, đưa vấn đề ra nhóm thảo luận — chứ không phải nhảy ngay vào giải pháp.
- Lọc "trao quyền cho nhóm tự giải": Phương án giúp nhóm tự khám phá và tự quyết thường thắng phương án mà Scrum Master tự xử lý.
- Lọc "tôn trọng accountability của từng vai trò": Việc của Product Owner (thứ tự Product Backlog, value) thì để PO quyết. Việc kỹ thuật, ước lượng, "how" thì để Developers quyết. Scrum Master không lấn sân.
- Lọc "minh bạch thay vì che giấu": Phương án làm cho vấn đề minh bạch (transparency) với đúng người, đúng sự kiện, thường đúng. Phương án che giấu, "để tôi xử lý ngầm cho êm", thường sai.
Cảnh giác với các "từ khóa cạm bẫy"
Trong đề PSM II có những từ ngữ là red flag — thấy chúng trong một phương án, hãy nghi ngờ ngay: "Scrum Master assigns tasks", "SM increases the commitment", "SM decides", "force the team", "report to management to discipline", "remove the team member". Ngược lại, các động từ thường gắn với đáp án đúng: facilitate, coach, make transparent, help the team explore, bring it to the Retrospective, ask the team.
Tình huống thực tế
Tình huống 1 — Velocity giảm 30% và Product Owner đang sốt ruột
Bối cảnh: Tại Tiki, một nhóm phát triển tính năng thanh toán có velocity trung bình 40 story point/Sprint. Qua bốn Sprint gần đây, con số rơi xuống 28 (giảm 30%). Product Owner — anh Hùng — đang chịu áp lực từ ban giám đốc vì roadmap chậm. Anh tìm Scrum Master và nói: "Em phải làm gì đó, nhóm đang lười đi rồi".
Câu hỏi (đúng dạng đề): Hành động đầu tiên TỐT NHẤT của Scrum Master là gì?
A. Tăng commitment của nhóm ở Sprint Planning kế tiếp để bù lại phần đã chậm. B. Báo cáo từng cá nhân có velocity thấp lên quản lý để có biện pháp. C. Tạo không gian để nhóm cùng nhìn lại dữ liệu và tự khám phá nguyên nhân đằng sau xu hướng giảm. D. Trấn an Product Owner rằng velocity dao động là bình thường và đề nghị anh kiên nhẫn.
Diễn giải: Áp ngay bộ lọc. Phương án A vi phạm bộ lọc số 1 — Scrum Master không "tăng commitment thay nhóm"; commitment là của Developers, và velocity không phải con số để ép. Loại. Phương án B vi phạm cả bộ lọc số 1 và số 5 — biến velocity (vốn là công cụ hỗ trợ nhóm tự cải thiện) thành công cụ trừng phạt cá nhân, phá hủy tâm lý an toàn. Loại thẳng. Phương án D không hoàn toàn sai về mặt kiến thức (velocity đúng là có dao động), nhưng nó né tránh vấn đề, không tìm nguyên nhân gốc, và bỏ rơi sự lo lắng chính đáng của PO — vi phạm bộ lọc số 2.
Phương án C thắng vì nó kết hợp ba bộ lọc: đi tìm dữ kiện trước (lọc 2), trao cho nhóm quyền tự khám phá (lọc 3), và làm minh bạch xu hướng (lọc 5). Lưu ý chữ "tự khám phá" — Scrum Master không tự kết luận "do nhóm có người nghỉ" hay "do nợ kỹ thuật"; anh tạo điều kiện để chính nhóm nhìn ra. Có thể nguyên nhân thật là: hai Developer nghỉ phép, một loạt bug từ Sprint trước phải sửa, hoặc các hạng mục gần đây phức tạp hơn. Nhóm mới là người biết rõ nhất.
Bài học rút ra: Khi một metric "xấu đi", phản xạ của Scrum Master non tay là sửa metric. Phản xạ của Scrum Master PSM II là điều tra hệ thống tạo ra metric. Velocity là triệu chứng, không phải bệnh.
Tình huống 2 — Một Developer "ôm" hết task khó, người khác ngồi không
Bối cảnh: Tại một công ty fintech ở Singapore làm việc với team ở TP.HCM, anh Minh là kỹ sư senior giỏi nhất nhóm. Mỗi Sprint anh nhận hết các hạng mục phức tạp, làm rất nhanh. Nhưng hệ quả: ba Developer còn lại chỉ làm việc dễ, kiến thức không được chia sẻ, và khi anh Minh nghỉ một Sprint, velocity sụp đổ vì "không ai đụng được vào phần core". Scrum Master nhận ra đây là rủi ro single point of failure.
Câu hỏi: Scrum Master nên làm gì?
A. Trực tiếp phân công lại task để các Developer khác buộc phải làm phần khó. B. Nêu vấn đề một cách minh bạch tại Sprint Retrospective và để nhóm tự thiết kế cách cải thiện việc chia sẻ kiến thức. C. Yêu cầu Product Owner không ưu tiên các hạng mục phức tạp cho đến khi nhóm cân bằng kỹ năng. D. Nói riêng với anh Minh rằng anh nên làm chậm lại để người khác có cơ hội.
Diễn giải: Phương án A vi phạm bộ lọc số 4 — việc ai làm gì trong Sprint là của Developers tự tổ chức (self-managing), Scrum Master không phân công. Loại. Phương án C vi phạm bộ lọc số 4 ở chiều ngược lại — nó can thiệp vào quyền của Product Owner đối với thứ tự Product Backlog, và tệ hơn, làm giảm giá trị giao cho khách hàng chỉ để "chữa" vấn đề nội bộ. Loại. Phương án D nghe có vẻ tế nhị, nhưng nó là Scrum Master âm thầm xử lý cá nhân thay vì làm vấn đề minh bạch với cả nhóm — vi phạm bộ lọc số 5, và lại biến giải pháp thành "bảo người giỏi làm chậm lại" (giảm hiệu suất, vô lý).
Phương án B thắng: đưa vấn đề ra Retrospective (đúng sự kiện cho cải tiến), làm minh bạch rủi ro, và để nhóm — bao gồm cả anh Minh — tự nghĩ ra giải pháp như pair programming, luân phiên hạng mục, hay xây dựng tài liệu. Đây là coaching ở cấp độ self-managing team.
Bài học rút ra: Đề PSM II rất hay dựng các tình huống mà giải pháp kỹ thuật trông hợp lý (phân công lại, bảo người giỏi chậm lại) nhưng vi phạm vai trò. Hãy luôn hỏi: "Quyết định này thuộc accountability của ai?" trước khi chọn.
Tình huống 3 — Sprint Review biến thành buổi demo một chiều
Bối cảnh: Tại VNG, một nhóm game tổ chức Sprint Review nhưng nó chỉ còn là buổi "trình diễn": Developers bật màn hình demo tính năng, stakeholder ngồi nghe, vỗ tay, rồi về. Không có thảo luận về thị trường, không ai điều chỉnh Product Backlog, Product Owner ít nói. Scrum Master cảm thấy buổi này đang mất giá trị.
Câu hỏi: Đâu là cách Scrum Master cải thiện đúng tinh thần Scrum nhất?
A. Hủy Sprint Review vì nó không còn hiệu quả, thay bằng email cập nhật tiến độ. B. Tự mình điều phối toàn bộ Sprint Review và thay PO trình bày để buổi họp sôi nổi hơn. C. Coaching để Sprint Review trở thành buổi làm việc cộng tác: thu thập phản hồi, cùng stakeholder và PO điều chỉnh Product Backlog cho hướng đi tiếp theo. D. Mời thêm thật nhiều stakeholder cấp cao để tạo áp lực buộc nhóm trình bày nghiêm túc.
Diễn giải: Phương án A hiểu sai bản chất Sprint Review — đó là sự kiện cộng tác để thanh tra Increment và thích nghi Product Backlog, không thể thay bằng email một chiều. Loại. Phương án B vi phạm bộ lọc số 4 — Scrum Master không thay PO làm việc của PO; điều đó tước đi accountability và khả năng phát triển của Product Owner. Loại. Phương án D dùng "áp lực cấp cao" — sai cả về văn hóa lẫn mục đích; Review không phải sân khấu gây áp lực. Loại.
Phương án C đúng: nó kéo Sprint Review về đúng bản chất là working session, nơi Increment được thanh tra cùng stakeholder và Product Backlog được điều chỉnh. Vai trò Scrum Master ở đây là coaching/facilitation, không phải "làm thay".
Bài học rút ra: Khi một sự kiện Scrum "biến chất", đáp án đúng hầu như luôn là khôi phục mục đích thật của sự kiện đó thông qua coaching, chứ không phải bỏ sự kiện hay tự làm thay.
Hướng dẫn từng bước
Đây là quy trình tôi khuyên bạn áp dụng cho mọi câu scenario trong PSM II:
Bước 1 — Đọc câu hỏi trước khi đọc phương án. Xác định chính xác đang hỏi gì: "best first action", "next step", "how should the SM respond", hay "what is the SM's accountability". Câu hỏi quyết định bộ lọc nào quan trọng nhất.
Bước 2 — Nhận diện vai trò liên quan. Vấn đề thuộc về Developers (cách làm việc, ước lượng), Product Owner (value, thứ tự backlog), hay tổ chức (impediment hệ thống)? Việc này kích hoạt bộ lọc số 4.
Bước 3 — Quét từ khóa cạm bẫy. Gạch ngay các phương án chứa "assign", "force", "increase commitment", "decide for", "discipline", "report individual". Thường loại được 1–2 phương án trong 10 giây.
Bước 4 — Áp năm bộ lọc theo thứ tự. Bắt đầu từ lọc "ra lệnh", rồi "tìm dữ kiện trước", "trao quyền", "tôn trọng accountability", "minh bạch". Mỗi phương án còn lại, hỏi nó vi phạm bộ lọc nào.
Bước 5 — So sánh hai phương án "sống sót" cuối cùng. Đề thường để lại hai phương án đều hợp lý. Người thắng là phương án làm trước, trao quyền nhiều hơn, hoặc minh bạch hơn. Hỏi: "Cái nào giúp nhóm tự đứng vững lâu dài, không phải chữa cháy trước mắt?".
Bước 6 — Cảnh giác với phương án "đúng nhưng vội". Một phương án có thể đúng về giải pháp cuối cùng nhưng sai về thời điểm (nhảy vào giải pháp khi chưa điều tra). Trong PSM II, đúng-nhưng-quá-sớm = sai.
Lỗi thường gặp & mẹo
Lỗi 1 — Chọn phương án "anh hùng". Nhiều học viên chọn phương án nơi Scrum Master nhảy vào tự giải quyết mọi thứ ("tôi sẽ nói chuyện với từng người", "tôi sẽ phân công lại"). Đây là tư duy team lead, không phải servant-leader. Mẹo: nếu một phương án khiến Scrum Master làm việc thay người khác, hãy nghi ngờ.
Lỗi 2 — Bỏ qua chữ "first" hoặc "next". Câu hỏi hỏi hành động đầu tiên, nhưng học viên chọn phương án mô tả giải pháp cuối. Đúng đích đến nhưng sai bước đi. Mẹo: khoanh tròn chữ "first/next/best" mỗi khi gặp.
Lỗi 3 — Nhầm velocity/metric là KPI cá nhân. Bất kỳ phương án nào dùng metric để xếp hạng, ép, hay kỷ luật cá nhân đều sai. Mẹo: metric trong Scrum phục vụ nhóm tự cải thiện, không phục vụ quản lý đánh giá người.
Lỗi 4 — Lấn sân accountability. Chọn phương án để Scrum Master quyết thứ tự backlog (việc của PO) hoặc quyết kỹ thuật (việc của Developers). Mẹo: luôn tự hỏi "đây là quyết định của ai?".
Lỗi 5 — Sợ để vấn đề lộ ra. Phương án "xử lý ngầm cho êm" hấp dẫn về mặt cảm xúc nhưng phản Scrum. Transparency là một trong ba trụ cột empiricism. Mẹo: phương án làm minh bạch với đúng người thường thắng.
Mẹo tổng: Khi phân vân giữa hai đáp án cuối, hãy chọn cái giúp nhóm tự giải quyết và còn giá trị lâu dài, thay vì cái giải quyết nhanh nhưng tạo phụ thuộc vào Scrum Master.
Bài tập thực hành
Bài 1 — Tự giải có ghi lý do. Với mỗi tình huống dưới đây, viết ra phương án bạn chọn VÀ ghi rõ bạn đã loại ba phương án kia bằng bộ lọc nào.
Tình huống A: Daily Scrum của nhóm kéo dài 35 phút, biến thành buổi báo cáo cho Scrum Master. Một số Developer thấy chán. SM nên làm gì đầu tiên? (i) Tự rút ngắn bằng cách cấm nói quá 1 phút mỗi người. (ii) Coaching để nhóm nhớ lại mục đích Daily Scrum là lập kế hoạch cho 24h tới, và để nhóm tự thiết kế lại cách chạy. (iii) Bỏ Daily Scrum vì nhóm đã quá quen việc. (iv) Đứng ra điều phối và gọi tên từng người báo cáo.
Tình huống B: Product Owner thường xuyên vắng mặt, Developers tự đoán yêu cầu và làm sai hướng. SM nên ưu tiên điều gì? (i) Tự đóng vai PO để trả lời câu hỏi của Developers. (ii) Làm minh bạch tác động của việc PO vắng mặt (rework, sai hướng) và coaching cả PO lẫn tổ chức về tầm quan trọng của vai trò. (iii) Đề nghị quản lý thay PO khác. (iv) Yêu cầu Developers ngừng làm cho đến khi PO quay lại.
Bài 2 — Viết phương án sai. Lấy tình huống 1 (velocity giảm) ở trên. Hãy tự sáng tác một phương án "đúng nhưng sai thời điểm" — nghe rất hợp lý nhưng vi phạm bộ lọc số 2. Việc tự tạo bẫy giúp bạn nhận ra bẫy trong phòng thi.
Bài 3 — Đối chiếu nhóm thật của bạn. Chọn một metric đang "xấu đi" ở nhóm bạn đang làm (velocity, số bug, thời gian cycle). Áp quy trình 6 bước và viết ra "best first action" bạn sẽ thực hiện. So sánh với phản xạ ban đầu của bạn — chúng có khác nhau không?
Gợi ý đáp án Bài 1: A → (ii); B → (ii). Hãy chắc rằng bạn loại được các phương án kia bằng đúng tên bộ lọc, không chỉ "cảm thấy".
Tóm tắt
PSM II không thưởng cho người thuộc bài, mà thưởng cho người suy luận đúng vai trò trong tình huống mơ hồ. Qua ba scenario kinh điển — velocity giảm, single point of failure, Sprint Review biến chất — bạn thấy một khuôn mẫu lặp lại: phương án đúng gần như luôn là phương án điều tra trước khi hành động, trao quyền cho nhóm tự giải, tôn trọng accountability của từng vai trò, và làm vấn đề minh bạch.
Hãy ghi nhớ năm bộ lọc và quy trình sáu bước như một phản xạ. Khi bạn áp chúng đủ nhiều, bạn sẽ không còn "đoán" đáp án nữa — bạn sẽ thấy tại sao ba phương án kia sai. Đó chính là sự khác biệt giữa một Scrum Master vừa đủ và một Scrum Master PSM II. Ở Practice Set 2 và 3 sắp tới, chúng ta sẽ tăng độ khó với các tình huống scaling và tổ chức — nhưng bộ lọc tư duy vẫn không đổi. Hãy luyện cho đến khi nó thành bản năng.