Mở đầu — vì sao bài này quan trọng
Trong tất cả các accountability của Scrum, Scrum Master có lẽ là vai trò bị hiểu sai nhiều nhất — cả ngoài đời thực lẫn trong phòng thi PSM I. Rất nhiều người nghĩ Scrum Master là "thư ký dự án", người ghi chú họp, người đặt lịch meeting, hay tệ hơn là một dạng "sếp nhỏ" quản lý đội. Nếu bạn bước vào phòng thi với những hình dung này, bạn sẽ trả lời sai một loạt câu hỏi.
Scrum Guide 2020 định nghĩa Scrum Master một cách rất cô đọng nhưng đầy sức nặng: Scrum Master chịu trách nhiệm thiết lập Scrum như được định nghĩa trong Scrum Guide (establishing Scrum as defined in the Scrum Guide). Một câu duy nhất, nhưng nó là kim chỉ nam cho toàn bộ hành vi của vai trò này. Đề thi PSM I khai thác rất sâu sự khác biệt giữa một Scrum Master "đúng sách" (true leader who serves) và một "project manager đội lốt Scrum Master".
Bài học này giúp bạn nắm chắc accountability cốt lõi của Scrum Master, ba nhóm đối tượng mà Scrum Master phục vụ (Scrum Team, Product Owner, Organization), ranh giới giữa "giúp đỡ" và "ra lệnh", và những bẫy phổ biến mà đề thi giăng ra. Đây là một trong những bài có trọng số cao trong cấu trúc câu hỏi PSM I.
Khái niệm cốt lõi
Accountability chính: Thiết lập Scrum
Câu nền tảng bạn cần thuộc nằm lòng:
> "The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization."
Hãy chú ý hai từ khóa: establishing (thiết lập) và helping (giúp đỡ). Scrum Master không "áp đặt" Scrum, không "ép buộc" team làm theo. Họ thiết lập Scrum bằng cách giúp mọi người hiểu lý thuyết và thực hành Scrum. Cơ chế ảnh hưởng của Scrum Master là thông qua dạy, hướng dẫn, và làm cho mọi thứ minh bạch — chứ không phải qua quyền lực ra lệnh.
Một điểm quan trọng khác: "The Scrum Master is accountable for the Scrum Team's effectiveness." Scrum Master chịu trách nhiệm về hiệu quả của cả team. Họ làm điều này bằng cách giúp Scrum Team cải thiện thực hành của mình, trong khuôn khổ Scrum framework.
True leader who serves
Scrum Guide 2020 mô tả Scrum Master là "true leaders who serve the Scrum Team and the larger organization" — những nhà lãnh đạo thực thụ phục vụ team và tổ chức rộng lớn hơn. Đây là sự thay thế tinh tế cho cụm "servant-leader" của bản 2017, nhưng tinh thần thì giống nhau và mạnh hơn: Scrum Master vừa là leader vừa là người phục vụ. Họ dẫn dắt nhưng không cai trị; họ phục vụ nhưng không phải là "người làm việc vặt".
Scrum Master phục vụ ba nhóm đối tượng
Đây là phần đề thi cực kỳ ưa thích. Scrum Guide chia dịch vụ của Scrum Master thành ba nhóm rõ ràng:
1. Phục vụ Scrum Team:
- Coach các thành viên team về self-management (tự quản lý) và cross-functionality (đa chức năng).
- Giúp Scrum Team tập trung tạo ra Increment giá trị cao đáp ứng Definition of Done.
- Gây tác động để loại bỏ các impediment (trở ngại) cản trở tiến độ của Scrum Team.
- Đảm bảo tất cả Scrum events diễn ra, mang lại giá trị tích cực, và nằm trong timebox.
- Giúp tìm các kỹ thuật để định nghĩa Product Goal và quản lý Product Backlog hiệu quả.
- Giúp Scrum Team hiểu sự cần thiết của các Product Backlog item rõ ràng, súc tích.
- Giúp thiết lập product planning theo lối thực nghiệm (empirical) trong môi trường phức tạp.
- Tạo điều kiện cho sự cộng tác với stakeholder khi được yêu cầu hoặc khi cần.
- Lead, train, và coach tổ chức trong việc áp dụng Scrum.
- Lập kế hoạch và tư vấn cho việc triển khai Scrum trong tổ chức.
- Giúp nhân viên và stakeholder hiểu và thực hành cách tiếp cận thực nghiệm với công việc phức tạp.
- Loại bỏ các rào cản giữa stakeholder và Scrum Team.
Scrum Master KHÔNG phải là gì
Đây là phần dễ mất điểm nhất. Theo đúng sách:
- Scrum Master không phải là người gán việc cho Developers. Developers tự tổ chức công việc (self-managing).
- Scrum Master không phải là người quyết định nội dung Product Backlog. Đó là Product Owner.
- Scrum Master không phải là người đánh giá hiệu suất cá nhân hay ra quyết định lương thưởng (không phải line manager).
- Scrum Master không "chạy" Daily Scrum. Daily Scrum là của Developers; Scrum Master chỉ đảm bảo nó diễn ra và đúng timebox.
- Scrum Master không giải quyết hộ mọi vấn đề. Họ giúp team tự giải quyết, và chỉ trực tiếp can thiệp vào những impediment vượt khả năng của team.
Một Scrum Master, nhiều team
Một câu hỏi hay gặp: một người có thể làm Scrum Master cho nhiều team không? Câu trả lời "by the book": có thể, miễn là họ vẫn đảm bảo được hiệu quả cho từng team. Scrum Guide không quy định tỉ lệ một-một. Tuy nhiên, accountability về effectiveness vẫn không đổi.
Tình huống thực tế
Tình huống 1: Scrum Master "đặt lịch và giao việc" tại một startup fintech ở TP.HCM
Công ty MoMoPay (giả định, một ví điện tử cỡ vừa tại quận 1) thuê Linh làm Scrum Master cho team 6 Developers. Sau ba Sprint, Linh than phiền: "Em quá tải. Mỗi sáng em phân công ai làm task gì, em cập nhật bảng Jira hộ cả team, em viết biên bản Daily Scrum gửi sếp, và em là người đầu tiên bị hỏi khi tiến độ chậm."
Vấn đề ở đây rất rõ: Linh đang đóng vai project manager, không phải Scrum Master. Việc phân công task cho Developers vi phạm nguyên tắc self-management — Developers phải tự quyết ai làm gì. Việc cập nhật Jira hộ làm giảm tính minh bạch (transparency) vì người làm việc không phải người cập nhật trạng thái. Việc gửi "biên bản Daily Scrum cho sếp" biến một event inspect-and-adapt của Developers thành báo cáo cho cấp trên.
Diễn giải: Một Scrum Master đúng sách sẽ làm ngược lại. Linh nên coach Developers tự nhận và tự quản lý task; dạy họ cập nhật Jira của chính mình để bảng phản ánh đúng thực tế; và giải thích cho sếp rằng Daily Scrum không phải buổi báo cáo tiến độ mà là buổi Developers tự inspect-adapt kế hoạch tiến tới Sprint Goal. Thay vì làm thay, Linh phải giúp team tự đứng vững.
Bài học: Khi Scrum Master càng bận rộn làm những việc "tay chân", team càng phụ thuộc và càng kém self-managing. Thước đo thành công của Scrum Master là team ngày càng ít cần đến mình cho các việc vận hành, để mình dồn sức vào coaching và gỡ impediment hệ thống.
Tình huống 2: Gỡ impediment cấp tổ chức tại một công ty outsourcing ở Hà Nội
Tại FPT-style outsourcing house (giả định, tên SoftViet), team của Scrum Master tên Hùng liên tục bị chậm vì mỗi lần cần truy cập môi trường staging, họ phải gửi email cho phòng IT trung tâm và chờ trung bình 4 ngày làm việc. Trong một Sprint 2 tuần, mất 4 ngày chờ quyền truy cập là thảm họa.
Đây không phải impediment mà Developers tự gỡ được — nó nằm ở chính sách của tổ chức. Đây là lúc Scrum Master thể hiện đúng vai trò "phục vụ Organization". Hùng không la mắng phòng IT, cũng không tự ý lách quy trình. Anh thu thập dữ liệu: trong 3 Sprint, đội mất tổng cộng 11 ngày-người chỉ để chờ truy cập, tương đương khoảng 18% năng lực. Anh trình bày con số này cho trưởng phòng IT và quản lý cấp trên, đề xuất cấp quyền truy cập theo nhóm (group-based access) cho team thay vì duyệt từng lần.
Diễn giải: Scrum Master gỡ impediment bằng ảnh hưởng và dữ liệu, không bằng quyền lực (vì Scrum Master không có quyền chỉ huy phòng IT). Anh làm cho vấn đề trở nên minh bạch ở cấp tổ chức, biến một bức xúc mơ hồ thành một con số khó chối cãi.
Bài học: Phần lớn impediment đáng giá nhất nằm ở tầng tổ chức, vượt khỏi tầm tay của team. Khả năng "lead change" ở cấp tổ chức chính là điều phân biệt một Scrum Master trưởng thành với một người chỉ biết điều phối họp.
Tình huống 3: Khi Product Owner nhờ Scrum Master "viết hộ" Product Backlog
Tại Tiki-style e-commerce (giả định, tên ShopLine), Product Owner mới tên Mai quá bận họp với ban lãnh đạo nên nhờ Scrum Master tên Đạt: "Anh giúp em viết và sắp xếp thứ tự Product Backlog luôn nhé, em duyệt sau."
Một Scrum Master non kinh nghiệm sẽ vui vẻ nhận lời — và vô tình tiếm quyền của Product Owner. Theo Scrum Guide, ordering của Product Backlog và quyết định giá trị sản phẩm là accountability không thể ủy thác của Product Owner. Nếu Đạt viết và sắp Backlog, ranh giới accountability sẽ bị xóa nhòa, và khi sản phẩm đi sai hướng, không ai biết trách nhiệm thuộc về ai.
Diễn giải: Đạt nên phục vụ Product Owner theo đúng nghĩa: dạy Mai các kỹ thuật quản lý Backlog hiệu quả, gợi ý cách viết Product Backlog item rõ ràng, facilitate buổi refinement để cả team giúp Mai tinh chỉnh — nhưng không thay Mai ra quyết định. Đạt có thể nói: "Em sẽ không viết hộ Backlog vì đó là quyết định giá trị của chị, nhưng em sẽ chỉ chị cách làm nhanh hơn và tổ chức buổi refinement để cả team hỗ trợ."
Bài học: Phục vụ Product Owner nghĩa là trao quyền năng lực, không phải gánh hộ trách nhiệm. Đề thi PSM I rất thích bẫy này: phân biệt giữa "Scrum Master giúp PO" và "Scrum Master làm thay PO".
Hướng dẫn từng bước
Nếu bạn muốn vận hành accountability của Scrum Master một cách đúng sách, đây là một lộ trình tư duy:
Bước 1 — Xác định bạn đang phục vụ ai trong tình huống này. Trước mỗi hành động, hỏi: việc này phục vụ Scrum Team, Product Owner, hay Organization? Câu trả lời định hình hành vi đúng. Ví dụ, gỡ rào cản giữa stakeholder và team là phục vụ Organization; coach về self-management là phục vụ Team.
Bước 2 — Chọn chế độ tác động phù hợp. Scrum Master có nhiều "công cụ": teaching, coaching, facilitating, mentoring. Với một team mới, có thể bạn cần dạy nhiều. Với một team trưởng thành, bạn coach và facilitate nhiều hơn. Luôn ưu tiên giúp người khác tự tìm ra câu trả lời thay vì đưa câu trả lời sẵn.
Bước 3 — Bảo vệ các Scrum events. Đảm bảo cả năm event diễn ra, đúng timebox, và mang lại giá trị. Bạn không "sở hữu" event, nhưng bạn chịu trách nhiệm để chúng không bị bỏ qua, kéo dài lê thê, hay biến tướng (ví dụ Daily Scrum thành buổi báo cáo cho sếp).
Bước 4 — Săn và phân loại impediment. Lập danh sách trở ngại. Phân loại: cái nào team tự gỡ được (để team tự xử và bạn chỉ coach), cái nào cần bạn dùng ảnh hưởng ở cấp tổ chức. Với loại thứ hai, thu thập dữ liệu để tăng tính thuyết phục.
Bước 5 — Đo bằng effectiveness, không phải bằng độ bận. Tự hỏi mỗi Sprint: team có self-managing hơn không? Có ít phụ thuộc vào mình hơn không? Có tạo Increment giá trị cao đáp ứng Definition of Done không? Đó mới là thước đo accountability của bạn.
Lỗi thường gặp & mẹo
Lỗi 1: Nhầm Scrum Master với người ghi chú/đặt lịch. Trong đề thi, bất kỳ đáp án nào mô tả Scrum Master như "thư ký" hoặc "người gán task" gần như chắc chắn sai. Mẹo: nếu hành động làm giảm self-management của team, đó không phải việc của Scrum Master.
Lỗi 2: Cho rằng Scrum Master giải quyết mọi impediment một mình. Đúng sách là Scrum Master gây tác động để (causes the removal of) impediment, và ưu tiên giúp team tự gỡ. Họ không phải "siêu nhân dọn rác".
Lỗi 3: Để Scrum Master ra quyết định nội dung sản phẩm. Đó là lãnh địa của Product Owner. Scrum Master chỉ giúp về kỹ thuật và quy trình.
Lỗi 4: Nghĩ Scrum Master là quản lý nhân sự của team. Scrum Master không đánh giá hiệu suất cá nhân, không quyết lương, không tuyển/sa thải với tư cách vai trò này. Họ là leader phục vụ, không phải sếp.
Lỗi 5: Quên nhóm Organization. Nhiều người chỉ nhớ Scrum Master phục vụ team. Đề thi rất hay hỏi về phần phục vụ tổ chức — lead, train, coach việc áp dụng Scrum, và loại bỏ rào cản giữa stakeholder và team.
Mẹo trả lời thi: Khi gặp câu hỏi "Scrum Master nên làm gì trong tình huống X", hãy ưu tiên đáp án có động từ help, coach, facilitate, teach, enable, cause hơn các đáp án có động từ assign, decide, order, control, report to. Scrum đề cao việc trao quyền, không phải kiểm soát.
Mẹo phân biệt accountability vs activity: Accountability (chịu trách nhiệm) là cái không đổi: thiết lập Scrum, hiệu quả của team. Activity (hoạt động) là cách thực hiện, có thể linh hoạt. Đề thi thường hỏi về accountability — hãy bám vào câu định nghĩa gốc.
Bài tập thực hành
- Phân loại ba nhóm phục vụ. Viết ra giấy ba cột: Scrum Team / Product Owner / Organization. Không nhìn tài liệu, điền các hành động của Scrum Master vào đúng cột. Sau đó đối chiếu với Scrum Guide. Mục tiêu: đặt đúng tối thiểu 10 hành động.
- Tình huống tự xử. Đội bạn có một Developer thường xuyên đến trễ Daily Scrum, làm event lệch giờ. Hãy viết ra cách một Scrum Master "đúng sách" xử lý — và chỉ ra vì sao việc "ra lệnh kỷ luật" lại không phải lựa chọn của Scrum Master.
- Bài tập "không làm thay". Liệt kê 5 việc mà người ta hay nhờ Scrum Master làm hộ (viết Backlog, gán task, ra quyết định kỹ thuật, viết báo cáo cho sếp, phê duyệt nghỉ phép). Với mỗi việc, viết một câu từ chối lịch sự kèm một đề xuất phục vụ đúng vai trò.
- Mô phỏng đề thi. Tự đặt 5 câu hỏi trắc nghiệm dạng "Scrum Master nên làm gì khi...", mỗi câu 4 đáp án, trong đó có ít nhất một bẫy "project manager". Đổi đề với bạn học và chấm cho nhau.
- Tự kiểm độ bận. Nhìn lại một tuần làm việc gần nhất (hoặc tưởng tượng nếu bạn chưa làm Scrum Master), ghi ra việc nào làm team phụ thuộc hơn vào bạn và việc nào làm team tự chủ hơn. Mục tiêu dài hạn: tăng nhóm thứ hai.
Tóm tắt
Scrum Master chịu trách nhiệm cốt lõi là thiết lập Scrum như định nghĩa trong Scrum Guide, và họ làm điều đó bằng cách giúp mọi người hiểu lý thuyết và thực hành Scrum — bên trong team lẫn trong toàn tổ chức. Họ cũng chịu trách nhiệm về hiệu quả (effectiveness) của Scrum Team.
Scrum Master là true leader who serves — vừa dẫn dắt vừa phục vụ — đối với ba nhóm: Scrum Team (coach self-management, cross-functionality, gỡ impediment, bảo vệ events), Product Owner (giúp về Product Goal, quản lý Backlog, cộng tác stakeholder), và Organization (lead/train/coach việc áp dụng Scrum, gỡ rào cản giữa stakeholder và team).
Điểm mấu chốt để không mất điểm thi và làm đúng ngoài đời: Scrum Master không gán việc, không quyết nội dung sản phẩm, không làm quản lý nhân sự, và không làm thay trách nhiệm của người khác. Họ trao quyền, không kiểm soát. Thước đo thành công không phải là Scrum Master bận đến đâu, mà là team ngày càng tự chủ, hiệu quả, và tạo ra Increment giá trị cao đáp ứng Definition of Done đến mức nào.
Khi gặp câu hỏi PSM I về Scrum Master, hãy ưu tiên các đáp án mang tinh thần help, coach, facilitate, teach, cause-the-removal-of — và cảnh giác với mọi đáp án biến Scrum Master thành một project manager đội lốt.