Mở đầu — vì sao bài này quan trọng
Một trong những hiểu lầm phổ biến nhất khi mới làm Scrum Master là nghĩ rằng công việc của mình chỉ gói gọn trong việc "chạy các ceremony" và "gỡ impediment". Nhưng nếu bạn quan sát một Scrum Master thực thụ làm việc, bạn sẽ thấy điều thú vị: trong cùng một ngày, họ liên tục đổi "vai" — lúc thì im lặng đặt câu hỏi để Developer tự tìm ra giải pháp, lúc thì kể lại kinh nghiệm cá nhân để hướng dẫn một Product Owner mới, lúc thì đứng lên giảng giải về timebox của Daily Scrum, và lúc thì điều phối một buổi họp căng thẳng giữa các bên.
Bốn "vai" đó — trong tài liệu Scrum và trong giới Agile coaching gọi là bốn stances (tư thế, lập trường): Coaching, Mentoring, Teaching, Facilitating — là trái tim của accountability "leading & coaching". Đây không chỉ là kiến thức để áp dụng tại nơi làm việc; nó còn là một vùng kiến thức mà đề thi PSM I rất hay kiểm tra, đặc biệt qua các câu hỏi tình huống dạng "Trong trường hợp này, Scrum Master nên làm gì?".
Lý do PSM I quan tâm điều này: rất nhiều câu hỏi cài bẫy bằng cách đưa ra một đáp án "Scrum Master tự giải quyết vấn đề thay cho team" hoặc "Scrum Master ra lệnh cho team phải làm gì". Nếu bạn hiểu rõ bốn stances và biết stance nào phù hợp với tình huống nào, bạn sẽ tránh được hầu hết các bẫy đó. Hiểu sâu bài này, bạn vừa thi tốt vừa làm việc tốt. Cùng đi vào từng stance một cách rõ ràng.
Khái niệm cốt lõi
Bản chất của bốn stances là trả lời câu hỏi: "Khi đối mặt với một con người hoặc một tình huống, Scrum Master nên can thiệp ở mức độ nào và bằng cách nào?". Trục quyết định nằm ở hai yếu tố: (1) người kia đã có sẵn năng lực/kiến thức chưa, và (2) mục tiêu là chuyển giao kiến thức hay khơi gợi năng lực tự thân.
Coaching — giúp người khác tự khám phá insight
Coaching là stance trung tâm và cũng là khó nhất. Mục đích của coaching là giúp người khác tự khám phá ra insight, giải pháp, và năng lực của chính họ — chứ không phải đưa cho họ câu trả lời. Tiền đề của coaching là: người được coach đã có sẵn nguồn lực bên trong để tự giải quyết vấn đề; việc của coach chỉ là tạo điều kiện để họ nhìn thấy điều đó.
Coaching không gắn với việc coach phải là chuyên gia về chủ đề đang bàn. Một Scrum Master có thể coach một Developer về cách ra quyết định kỹ thuật ngay cả khi bản thân Scrum Master không viết code, bởi vì coaching tập trung vào quá trình tư duy chứ không vào nội dung chuyên môn.
Công cụ của coaching gồm:
- Powerful questions (câu hỏi khơi gợi): những câu hỏi mở, không dẫn dắt, buộc người nghe phải suy nghĩ. Ví dụ: "Điều gì đang ngăn cản em làm việc đó?", "Nếu không có giới hạn nào, em sẽ làm gì?", "Em định nghĩa thành công ở đây như thế nào?".
- Active listening (lắng nghe chủ động): lắng nghe không chỉ nội dung mà cả cảm xúc, sự ngập ngừng, điều chưa nói ra. Coach phản chiếu lại ("Anh đang nghe thấy em lo về deadline, đúng không?") để người kia tự nhìn rõ vấn đề của mình.
- GROW model: một khung coaching kinh điển gồm bốn bước — Goal (mục tiêu muốn đạt), Reality (thực tế hiện tại), Options (các lựa chọn khả thi), Will/Way forward (cam kết hành động cụ thể). Coach dẫn người được coach đi qua bốn bước này bằng câu hỏi, chứ không bằng lời khuyên.
Mentoring — chia sẻ kinh nghiệm từ chuyên môn của mình
Mentoring khác coaching ở một điểm mấu chốt: mentor là người có kinh nghiệm và chuyên môn trong lĩnh vực cụ thể, và họ chủ động chia sẻ kinh nghiệm đó. Nếu coaching là "tôi giúp em tự tìm ra câu trả lời", thì mentoring là "tôi đã đi qua con đường này rồi, để tôi kể cho em nghe những gì tôi học được".
Trong Scrum, mentoring xuất hiện rõ nhất khi Scrum Master kèm cặp một Scrum Master mới, hay một Product Owner lần đầu làm việc với backlog. Mentor chia sẻ câu chuyện cá nhân, đưa lời khuyên dựa trên trải nghiệm, gợi ý cách tránh những sai lầm mình từng mắc. Mentoring mang tính cá nhân, dài hạn, và dựa trên mối quan hệ tin cậy.
Điểm cần nhớ cho PSM I: mentoring dựa trên kinh nghiệm của người mentor, không phải khơi gợi năng lực tự thân như coaching.
Teaching — truyền đạt kiến thức về Scrum
Teaching là stance đơn giản nhất về bản chất: truyền đạt kiến thức, quy tắc, khung làm việc. Khi một Scrum Master giải thích Scrum Guide nói gì, Daily Scrum timebox bao nhiêu phút, ai sở hữu Sprint Backlog, hay Definition of Done là gì — đó là teaching.
Teaching cần thiết khi team thiếu kiến thức nền tảng. Bạn không thể coach một người về cách áp dụng Scrum nếu họ chưa biết Scrum là gì. Vì vậy với một team mới, teaching thường đến trước, sau đó mới chuyển dần sang coaching khi team đã nắm vững nền tảng.
Lưu ý quan trọng: teaching là một chiều (truyền kiến thức xuống), và Scrum Master ở đây đóng vai chuyên gia về Scrum — chứ không phải chuyên gia về nội dung công việc của team.
Facilitating — điều phối để nhóm tự đi đến kết quả
Facilitating là stance khi Scrum Master giúp một nhóm người có cuộc trao đổi hiệu quả và đi đến quyết định của chính họ — mà bản thân facilitator giữ thái độ trung lập về nội dung. Facilitator lo về quá trình của cuộc họp: đảm bảo mọi người được lắng nghe, hội thoại đi đúng hướng, thời gian được tôn trọng, và nhóm đạt được mục tiêu của buổi họp.
Đây là stance nổi bật khi Scrum Master điều phối các Scrum Event. Khi facilitate một Sprint Retrospective, Scrum Master không áp đặt "team phải cải tiến cái này"; thay vào đó họ thiết kế cấu trúc buổi họp (ví dụ kỹ thuật "Start-Stop-Continue"), giữ cho thảo luận cân bằng, và để team tự quyết định action item.
Khác biệt then chốt giữa facilitating và teaching: teaching là Scrum Master có nội dung muốn truyền, còn facilitating là Scrum Master trung lập về nội dung, chỉ lo cho dòng chảy của cuộc trao đổi.
Bảng so sánh nhanh bốn stances
| Stance | Mục đích | Ai có "đáp án" | Vai của Scrum Master |
|---|---|---|---|
| Coaching | Khơi gợi insight tự thân | Người được coach | Đặt câu hỏi, lắng nghe |
| Mentoring | Chia sẻ kinh nghiệm | Mentor | Người đi trước, cố vấn |
| Teaching | Truyền kiến thức Scrum | Scrum Master (về Scrum) | Chuyên gia, giảng dạy |
| Facilitating | Giúp nhóm tự ra quyết định | Cả nhóm | Trung lập, điều phối |
Tình huống thực tế
Tình huống 1 — Tiki: Developer bị kẹt một quyết định kỹ thuật
Tại một squad của một công ty thương mại điện tử lớn ở TP.HCM (lấy bối cảnh kiểu Tiki), một Developer tên Hùng đến gặp Scrum Master Lan và than: "Em không biết nên dùng kiến trúc microservice hay giữ monolith cho module thanh toán mới. Chị quyết giúp em đi."
Phản xạ sai sẽ là Lan tự đưa ra quyết định — nhưng Lan không phải kiến trúc sư, và quan trọng hơn, làm vậy sẽ tước đi quyền tự quản (self-management) của team. Lan chọn coaching. Cô hỏi: "Tiêu chí quan trọng nhất của em ở quyết định này là gì — tốc độ ship hay khả năng mở rộng sau này?", "Nếu chọn microservice, ba rủi ro lớn nhất em thấy là gì?", "Trong team mình ai có thể cùng em phân tích cái này?".
Sau 20 phút, Hùng tự nhận ra rằng với quy mô hiện tại, monolith vẫn ổn và team chưa có năng lực vận hành nhiều service. Quyết định đến từ chính Hùng.
Bài học: Khi vấn đề thuộc chuyên môn của team và team có đủ năng lực, Scrum Master nên coach chứ không quyết hộ. PSM I rất hay test điểm này — đáp án "Scrum Master tự ra quyết định kỹ thuật" gần như luôn sai.
Tình huống 2 — Một startup fintech ở Hà Nội: Product Owner mới toanh
Một startup fintech khoảng 30 người vừa bổ nhiệm chị Mai từ vị trí business analyst lên làm Product Owner. Mai chưa từng quản lý Product Backlog, không biết cách sắp xếp ưu tiên, và lúng túng khi stakeholder gây áp lực.
Ở đây coaching đơn thuần sẽ không đủ — Mai thiếu cả kiến thức nền lẫn kinh nghiệm. Scrum Master Tuấn dùng kết hợp: đầu tiên là teaching (giải thích Product Owner accountability, Product Backlog là gì, cách commitment Product Goal hoạt động), sau đó là mentoring (Tuấn từng làm PO ba năm, anh kể lại cách mình từng xử lý stakeholder đòi mọi thứ "ưu tiên cao", chia sẻ kỹ thuật anh hay dùng). Khi Mai đã vững nền tảng sau vài Sprint, Tuấn chuyển dần sang coaching — để Mai tự ra quyết định ưu tiên và chỉ đặt câu hỏi khi cần.
Bài học: Các stances không loại trừ nhau; một Scrum Master giỏi biết phối hợp chúng theo trình độ của người đối diện. Người mới cần nhiều teaching và mentoring; người đã trưởng thành cần nhiều coaching hơn.
Tình huống 3 — Một công ty outsourcing ở Đà Nẵng: Retrospective bế tắc
Tại một công ty outsourcing phần mềm ở Đà Nẵng (khoảng 200 nhân sự), một team 8 người bước vào Sprint Retrospective với không khí căng thẳng: Sprint vừa rồi miss Sprint Goal, hai Developer bắt đầu đổ lỗi cho nhau, còn vài người im lặng không nói gì.
Scrum Master Nga chọn facilitating. Cô không đứng về phía ai và không đưa ra phán xét về nội dung. Thay vào đó, cô thiết kế quá trình: bắt đầu bằng một vòng "an toàn tâm lý" để hạ nhiệt, dùng kỹ thuật viết ý kiến lên giấy note ẩn danh trước khi thảo luận (để người ngại nói cũng được lắng nghe), đặt timebox cho từng phần, và dẫn nhóm gom nhóm vấn đề rồi tự bỏ phiếu chọn hai cải tiến quan trọng nhất.
Kết quả: thay vì một buổi đổ lỗi, team rời phòng với hai action item cụ thể do chính họ chọn. Nga gần như không cho ý kiến về nội dung — cô chỉ lo cho dòng chảy của cuộc họp.
Bài học: Trong các Scrum Event, facilitating thường là stance chủ đạo. Scrum Master tạo ra môi trường để nhóm tự đi đến kết quả, chứ không áp đặt kết luận.
Hướng dẫn từng bước
Khi đối mặt với một tình huống và phân vân nên dùng stance nào, hãy đi qua quy trình suy nghĩ sau:
- Xác định bản chất nhu cầu. Người/nhóm đang thiếu gì? Thiếu kiến thức (chưa biết Scrum), thiếu kinh nghiệm thực tế, đã có năng lực nhưng bị kẹt trong tư duy, hay đang cần một cuộc trao đổi nhóm hiệu quả?
- Nếu thiếu kiến thức nền về Scrum → Teaching. Giảng giải rõ ràng quy tắc, vai trò, sự kiện, artifact. Đừng coach một người chưa có nền — hãy dạy trước.
- Nếu thiếu kinh nghiệm và cần người đi trước dẫn dắt → Mentoring. Chia sẻ trải nghiệm cá nhân, đưa lời khuyên cụ thể dựa trên những gì bạn đã từng trải.
- Nếu đã có đủ năng lực nhưng đang kẹt/cần tự khám phá → Coaching. Đặt powerful questions, lắng nghe chủ động, dùng GROW. Kiềm chế việc đưa câu trả lời.
- Nếu cần một nhóm trao đổi và tự ra quyết định → Facilitating. Thiết kế quá trình họp, giữ trung lập về nội dung, đảm bảo mọi tiếng nói được lắng nghe.
- Sẵn sàng chuyển stance trong cùng một cuộc trò chuyện. Bạn có thể bắt đầu bằng teaching, rồi mentoring, rồi kết thúc bằng coaching khi người kia đã đủ tự tin. Sự linh hoạt này chính là dấu hiệu của một Scrum Master trưởng thành.
- Mặc định nghiêng về coaching và facilitating khi có thể. Vì mục tiêu dài hạn của Scrum Master là xây dựng team tự quản (self-managing), hai stance này nuôi dưỡng năng lực tự thân tốt nhất. Teaching và mentoring cần thiết nhưng nên giảm dần khi team trưởng thành.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm coaching với mentoring. Đây là bẫy số một. Nhiều người nghĩ coaching là "cho lời khuyên hay". Không. Coaching là khơi gợi để người kia tự tìm câu trả lời; cho lời khuyên dựa trên kinh nghiệm là mentoring. Mẹo nhớ: Coaching = câu hỏi đến từ bạn, câu trả lời đến từ họ. Mentoring = cả hai đến từ bạn.
Lỗi 2 — Dùng coaching khi người ta thiếu kiến thức nền. Đặt câu hỏi khơi gợi cho một người chưa biết Scrum Guide nói gì chỉ khiến họ bối rối. Lúc đó cần teaching. Coaching chỉ hiệu quả khi người được coach có sẵn nguồn lực bên trong.
Lỗi 3 — Mất tính trung lập khi facilitating. Khoảnh khắc Scrum Master nói "Theo tôi team nên làm cái này" trong một Retrospective, họ đã rời khỏi vai facilitator và chuyển sang áp đặt nội dung. Nếu Scrum Master thực sự cần đóng góp nội dung, hãy nói rõ "Giờ tôi xin đổi vai một chút để chia sẻ quan điểm" — minh bạch về việc đổi stance.
Lỗi 4 — Coi mình là người giải quyết mọi vấn đề. Phản xạ "để tôi lo" tước đi quyền tự quản của team và tạo ra sự phụ thuộc. Scrum Master là leader phục vụ, không phải người làm thay.
Mẹo cho PSM I:
- Khi câu hỏi mô tả Scrum Master tự giải quyết vấn đề chuyên môn của team hoặc ra lệnh, đáp án đó thường sai.
- Khi câu hỏi nói về việc giúp người khác tự tìm ra giải pháp → đó là coaching.
- Khi nói về chia sẻ kinh nghiệm cá nhân → mentoring.
- Khi nói về giải thích quy tắc Scrum → teaching.
- Khi nói về điều phối một cuộc họp/sự kiện để nhóm tự quyết → facilitating.
- Ghi nhớ: bốn stances bổ trợ cho accountability "true leader who serves" của Scrum Master.
Bài tập thực hành
Bài tập 1 — Phân loại stance. Với mỗi tình huống dưới đây, hãy xác định stance phù hợp nhất:
- (a) Một Developer mới hỏi "Definition of Done là gì?".
- (b) Team tranh cãi gay gắt trong Sprint Planning và cần đi đến Sprint Goal chung.
- (c) Một Tester có năng lực nhưng tự ti, không dám đề xuất ý tưởng cải tiến.
- (d) Một Scrum Master mới nhờ bạn kể về lần đầu bạn xử lý một stakeholder khó tính.
Bài tập 2 — Soạn powerful questions. Một Developer nói: "Em nghĩ team mình estimate quá lạc quan nên Sprint nào cũng tràn việc." Hãy viết ra ba câu hỏi coaching mở, không dẫn dắt, để giúp người này tự khám phá nguyên nhân và giải pháp. Tránh các câu kiểu "Tại sao em không chỉ estimate cao hơn?" (đó là lời khuyên trá hình).
Bài tập 3 — Tự quan sát. Trong tuần làm việc tới (hoặc trong một buổi họp bạn tham gia), hãy ghi lại ba lần bạn can thiệp và tự hỏi: lúc đó mình đang ở stance nào? Stance đó có phù hợp không, hay lẽ ra nên chọn stance khác? Viết một đoạn ngắn rút kinh nghiệm.
Bài tập 4 — Đổi stance trong một kịch bản. Hình dung bạn đang kèm một Product Owner hoàn toàn mới trong suốt ba Sprint. Hãy phác ra trình tự stance bạn sẽ dùng từ Sprint 1 đến Sprint 3 và lý do chuyển đổi giữa các stance đó.
Tóm tắt
- Scrum Master vận hành bằng bốn stances: Coaching, Mentoring, Teaching, Facilitating — đây là biểu hiện cụ thể của accountability "true leader who serves".
- Coaching: giúp người khác tự khám phá insight; công cụ gồm powerful questions, active listening, GROW model; câu trả lời đến từ người được coach.
- Mentoring: chia sẻ kinh nghiệm và lời khuyên từ chuyên môn của mentor; dựa trên mối quan hệ và trải nghiệm cá nhân.
- Teaching: truyền đạt kiến thức Scrum (quy tắc, vai trò, sự kiện, artifact); cần thiết với người/team chưa có nền tảng.
- Facilitating: điều phối nhóm để họ tự đi đến quyết định; Scrum Master trung lập về nội dung, chỉ lo về quá trình.
- Bốn stances bổ trợ nhau, không loại trừ; Scrum Master giỏi biết chọn và chuyển stance theo trình độ người đối diện, ưu tiên coaching và facilitating khi muốn nuôi dưỡng team tự quản.
- Trong PSM I: cảnh giác với đáp án Scrum Master "tự giải quyết" hay "ra lệnh"; nhận diện từ khóa để map về đúng stance (tự tìm ra giải pháp → coaching; chia sẻ kinh nghiệm → mentoring; giải thích quy tắc → teaching; điều phối → facilitating).