Mở đầu — vì sao bài này quan trọng
Khi mới làm Scrum Master, hầu hết chúng ta đều rơi vào một cái bẫy rất dễ chịu: trở thành "người biết tất cả". Team gặp vướng mắc, ta lập tức đưa lời khuyên. Có ai hỏi về Scrum, ta giảng giải ngay tại chỗ. Có xung đột, ta nhảy vào phân xử. Cảm giác này rất thỏa mãn — vì ta thấy mình hữu ích, thấy mình "đang làm việc". Nhưng đây chính là ranh giới phân biệt một Scrum Master cấp PSM I và một Scrum Master cấp PSM II.
Sự thật phũ phàng là: nếu team chỉ làm tốt khi có bạn ở đó, thì bạn đã thất bại trong vai trò cốt lõi của mình. Mục tiêu tối thượng của Scrum Master không phải là giải quyết vấn đề cho team, mà là xây dựng một team có khả năng tự giải quyết vấn đề. Và để làm được điều đó, bạn cần biết khi nào nên dạy, khi nào nên cố vấn, và khi nào nên im lặng để hỏi một câu hỏi đúng.
Đó chính là nội dung của bài học này: Coaching Stance — các "tư thế" (stance) mà một Scrum Master luân chuyển qua lại. Hiểu sai về stance khiến bạn hoặc trở thành một giáo viên áp đặt, hoặc một cố vấn nói thay người khác, hoặc một coach hỏi vu vơ không đi đến đâu. Hiểu đúng, bạn sẽ biết chọn đúng "tư thế" cho đúng tình huống — và đó là kỹ năng nền tảng cho toàn bộ phần coaching trong khóa học này.
Khái niệm cốt lõi
"Stance" trong tiếng Anh nghĩa là tư thế đứng, vị trí mà bạn đặt mình vào khi tương tác với người khác. Một Scrum Master không có một stance cố định — bạn liên tục chuyển đổi giữa nhiều stance tùy theo nhu cầu của tình huống. Ba stance nền tảng nhất, theo thứ tự từ "trao kiến thức" đến "khơi gợi tự thân", là: Teacher (Người dạy), Mentor (Người cố vấn), và Coach (Người khai vấn).
Hãy hình dung ba stance này nằm trên một trục. Bên trái là nơi bạn nắm giữ câu trả lời và trao nó đi (Teacher). Đi sang phải, bạn chia sẻ kinh nghiệm cá nhân nhưng để người kia tự quyết (Mentor). Đến cực phải, bạn không trao câu trả lời nào cả — bạn tin rằng người đối diện đã có sẵn nguồn lực để tự tìm ra (Coach). Bậc thầy của nghề là người biết mình đang đứng ở đâu trên trục này, và chuyển dịch một cách có chủ đích.
Teacher — Người dạy
Stance Teacher được dùng khi có một khoảng trống kiến thức rõ ràng. Team không biết Sprint Review khác Sprint Retrospective ở chỗ nào, không hiểu vì sao Definition of Done lại quan trọng, không nắm được các nguyên tắc của Scrum Guide — đây là lúc bạn dạy. Teacher trao đi thông tin khách quan, đúng/sai rõ ràng.
Dấu hiệu nhận biết bạn cần stance Teacher: câu hỏi có một câu trả lời chuẩn xác. "Daily Scrum kéo dài bao lâu?" — đây là câu hỏi của Teacher, không phải Coach. Sai lầm phổ biến là dùng coaching để xử lý một khoảng trống kiến thức: bạn hỏi "Theo bạn Daily Scrum nên kéo dài bao lâu?" trong khi team thực sự không biết — kết quả là bạn lãng phí thời gian và làm team bối rối. Nếu họ không biết, hãy dạy.
Mentor — Người cố vấn
Mentor đứng giữa. Bạn chia sẻ kinh nghiệm, câu chuyện, lời khuyên dựa trên những gì bản thân đã trải qua — nhưng khác Teacher ở chỗ đây là kinh nghiệm chủ quan, không phải chân lý phổ quát. "Hồi tôi làm ở một team thương mại điện tử, chúng tôi cũng gặp tình huống tương tự, và điều hiệu quả với chúng tôi là..." — đó là giọng của Mentor.
Điểm tinh tế: Mentor trao lời khuyên nhưng không áp đặt. Bạn nói "đây là điều đã hiệu quả với tôi", chứ không nói "bạn phải làm thế này". Người nghe được tự do nhận hoặc bỏ. Mentor đặc biệt giá trị khi đào tạo một Scrum Master mới, hoặc khi team đối mặt với một tình huống mà kinh nghiệm thực chiến của bạn có thể rút ngắn đường đi của họ.
Coach — Người khai vấn
Đây là stance khó nhất và cũng là "trái tim" của nghề Scrum Master cấp cao. Coach không trao câu trả lời. Coach tin vào một tiền đề căn bản: người đối diện có khả năng và nguồn lực để tự tìm ra giải pháp tốt nhất cho chính họ. Vai trò của coach là dùng câu hỏi mạnh mẽ (powerful questions), sự lắng nghe sâu, và sự im lặng có chủ đích để giúp họ tự khám phá.
Vì sao Coach lại quan trọng đến vậy? Vì một giải pháp do team tự nghĩ ra sẽ được họ cam kết và thực thi mạnh hơn nhiều so với một giải pháp bạn áp đặt. Hơn nữa, khi bạn coach, bạn đang dạy team cách tư duy, chứ không chỉ trao một đáp án dùng một lần. Đây chính là cách bạn xây dựng năng lực tự quản (self-management) — thứ Scrum Guide đặt làm nền tảng.
Một lưu ý quan trọng về mặt đạo đức nghề nghiệp: khi ở stance Coach thuần túy, bạn phải "agenda-free" — không có chương trình nghị sự riêng. Bạn không dùng câu hỏi để dẫn dắt người ta đến câu trả lời mà bạn đã định sẵn trong đầu (đó gọi là "leading questions" trá hình thành coaching). Coach thật sự tò mò về câu trả lời của người kia.
Nghệ thuật chuyển đổi stance
Điều phân biệt một Scrum Master xuất sắc không phải là làm chủ một stance, mà là chuyển đổi linh hoạt và có chủ đích giữa các stance trong cùng một cuộc trò chuyện. Một cuộc đối thoại 15 phút có thể bắt đầu bằng Coach ("Bạn thấy điều gì đang cản trở team?"), chuyển sang Teacher khi phát hiện một khoảng trống kiến thức ("À, ở đây có một quy tắc Scrum bạn nên biết..."), rồi quay lại Coach ("Với thông tin đó, bạn sẽ thử cách nào?"). Bài học sau trong khóa (Bài 36 — Coaching Stances Switching) sẽ đào sâu kỹ thuật chuyển đổi này; ở đây bạn chỉ cần nắm vững rằng stance là thứ linh hoạt, không cố định.
Tình huống thực tế
Tình huống 1 — Tiki và cái bẫy "Teacher quá đà"
Tại một công ty công nghệ lớn ở TP.HCM (gọi là bối cảnh kiểu Tiki), một Scrum Master tên Hùng phụ trách một team 7 người làm về tính năng thanh toán. Hùng vốn là một developer giỏi, hiểu Scrum rất sâu. Vấn đề là: mỗi lần Daily Scrum, khi ai đó nêu một trở ngại kỹ thuật, Hùng lập tức đưa ra giải pháp. Khi team tranh luận về cách chia user story, Hùng "chốt" luôn.
Sau ba tháng, một điều kỳ lạ xảy ra: trong hai tuần Hùng nghỉ phép, năng suất team tụt 40%, và các quyết định bị treo lại chờ Hùng về. Manager nhận xét: "Team này không chạy được nếu thiếu Hùng."
Diễn giải: Hùng đã mắc kẹt vĩnh viễn ở stance Teacher/Mentor. Mỗi lần anh trao câu trả lời, anh tiết kiệm cho team 5 phút suy nghĩ — nhưng cũng tước đi của họ cơ hội tự rèn năng lực ra quyết định. Anh vô tình tạo ra một team phụ thuộc.
Bài học rút ra: Khi bạn liên tục là người có câu trả lời, bạn đang xây một cây cầu mà chính bạn là trụ chống duy nhất. Hùng cần học cách kìm phản xạ "trả lời ngay" và thay bằng câu hỏi: "Mọi người nghĩ cách nào để gỡ chỗ này?" — đặc biệt với những vấn đề team hoàn toàn đủ năng lực tự giải. Đo lường thành công của bạn không phải bằng số vấn đề bạn giải, mà bằng số vấn đề team tự giải mà không cần đến bạn.
Tình huống 2 — Một startup fintech ở Singapore và sức mạnh của câu hỏi
Tại một startup fintech ở Singapore với team phân tán giữa Việt Nam và Singapore, Scrum Master tên Mai đối mặt với một Product Owner liên tục thay đổi ưu tiên giữa Sprint, khiến team bức xúc. Phản xạ đầu tiên của Mai là muốn "dạy" PO về nguyên tắc bảo vệ Sprint Goal — tức nhảy vào stance Teacher.
Nhưng Mai dừng lại và chọn stance Coach. Trong một buổi 1-on-1 với PO, thay vì giảng giải, cô hỏi: "Điều gì khiến anh cảm thấy cần thay đổi ưu tiên giữa chừng?" PO trả lời rằng anh bị sales gây áp lực mỗi tuần và sợ mất khách hàng lớn. Mai hỏi tiếp: "Nếu chúng ta có cách cho sales thấy lộ trình rõ ràng hơn, liệu anh có còn cần đổi ưu tiên giữa Sprint không?" PO suy nghĩ và tự đề xuất: tạo một buổi review ngắn với sales mỗi đầu Sprint.
Diễn giải: Nếu Mai chọn Teacher ngay từ đầu ("anh không được đổi ưu tiên giữa Sprint vì Scrum quy định..."), cô đã xử lý triệu chứng và biến PO thành đối thủ. Nhưng vì cô coach để tìm ra nguyên nhân gốc — áp lực từ sales — giải pháp được PO tự đưa ra và cam kết.
Bài học rút ra: Stance Coach giúp bạn chạm tới nguyên nhân gốc thay vì triệu chứng, và biến người đối diện từ "đối tượng cần sửa" thành "đồng minh tự nguyện". Lưu ý: việc tìm root cause sẽ được đào sâu ở Bài 5; ở đây trọng tâm là Mai đã chọn đúng stance.
Tình huống 3 — Đào tạo Scrum Master mới: lúc Mentor tỏa sáng
Tại một công ty gia công phần mềm ở Đà Nẵng (bối cảnh kiểu một công ty outsourcing 300 người), chị Lan là Agile Coach, kèm cặp một Scrum Master mới tên Tú. Tú vừa kết thúc Sprint đầu tiên và buổi Retrospective của cậu... im lặng đến đáng sợ — không ai nói gì.
Nếu chị Lan dùng stance Coach thuần ("Tú nghĩ vì sao team im lặng?"), Tú — vốn chưa có kinh nghiệm — sẽ chỉ đoán mò. Đây là lúc khoảng trống kinh nghiệm quá lớn để coach. Chị Lan chọn Mentor: "Hồi mới làm, Retro của chị cũng từng im như tờ. Điều giúp chị là không hỏi câu mở quá rộng ngay, mà bắt đầu bằng một hoạt động ẩn danh — ví dụ mỗi người viết một điều ra giấy note. Em thử xem có hợp với team em không."
Tú áp dụng, và Retro tiếp theo sôi nổi hẳn.
Diễn giải: Chị Lan không áp đặt ("em phải làm thế này"), mà chia sẻ kinh nghiệm và để Tú tự quyết ("em thử xem có hợp không"). Đó là Mentor đúng nghĩa. Dùng Coach lúc này sẽ là sai stance, vì Tú chưa đủ vốn liếng để tự khám phá.
Bài học rút ra: Mentor là cầu nối hoàn hảo khi người đối diện có động lực nhưng thiếu kinh nghiệm. Hãy chia sẻ câu chuyện của bạn như một lựa chọn, không phải mệnh lệnh.
Hướng dẫn từng bước
Đây là quy trình để chọn đúng stance trong một tình huống cụ thể:
- Tạm dừng phản xạ. Khoảnh khắc bạn muốn buột miệng đưa ra câu trả lời chính là khoảnh khắc cần dừng lại. Hít một hơi. Đừng để phản xạ "tỏ ra hữu ích" lái bạn vào Teacher một cách vô thức.
- Chẩn đoán khoảng trống. Tự hỏi: vấn đề ở đây là gì? (a) Thiếu kiến thức khách quan → Teacher. (b) Thiếu kinh nghiệm thực chiến, người đối diện có động lực nhưng chưa biết đường → Mentor. (c) Họ có đủ kiến thức và năng lực, chỉ cần được giúp tự khám phá hoặc tự cam kết → Coach.
- Kiểm tra mức độ năng lực và động lực của người đối diện. Người mới hoàn toàn thường cần Teacher/Mentor nhiều hơn. Người có kinh nghiệm nhưng bị kẹt thường cần Coach. Đừng coach một người không có nền tảng, và đừng dạy một người đã thừa kiến thức.
- Chọn stance một cách có chủ đích và tuyên bố ngầm. Nếu chuyển sang Teacher, hãy báo hiệu: "Mình chia sẻ một quy tắc Scrum ở đây nhé." Nếu Mentor: "Cho mình kể một kinh nghiệm." Việc gọi tên stance giúp người nghe biết họ đang nhận thông tin loại nào.
- Ưu tiên Coach khi có thể, dùng Teacher/Mentor khi cần. Nguyên tắc vàng: mặc định nghiêng về Coach để xây năng lực tự quản, nhưng đừng giáo điều — nếu có khoảng trống kiến thức thật sự, dạy là đúng đắn.
- Quan sát phản ứng và sẵn sàng chuyển stance. Nếu bạn coach mà người ta cứ trả lời "em không biết" một cách chân thật, đó là tín hiệu cần lùi về Teacher/Mentor. Stance không phải lựa chọn một lần — nó là dòng chảy.
Lỗi thường gặp & mẹo
Lỗi 1 — Mặc kẹt ở Teacher vì nó dễ chịu. Trao câu trả lời cho cảm giác hữu ích tức thì. Nhưng nó tạo ra team phụ thuộc, như câu chuyện của Hùng. Mẹo: mỗi tuần, đếm xem bạn đã trao bao nhiêu câu trả lời mà lẽ ra có thể hỏi một câu hỏi. Đặt mục tiêu giảm dần.
Lỗi 2 — "Coaching giả" bằng leading questions. Bạn đã có sẵn đáp án trong đầu và dùng câu hỏi để lùa người ta tới đó: "Bạn không nghĩ là chúng ta nên... đúng không?" Đây không phải coach, đây là Teacher đội lốt. Người đối diện cảm nhận được sự thao túng này. Mẹo: nếu bạn đã biết "câu trả lời đúng" mình muốn nghe, hãy thành thật chuyển sang Teacher thay vì giả vờ hỏi.
Lỗi 3 — Coach một người đang thiếu kiến thức nền. Hỏi "theo bạn nên làm gì?" với người thật sự không biết chỉ gây hoang mang. Mẹo: chẩn đoán khoảng trống trước. Thiếu kiến thức thì dạy.
Lỗi 4 — Mentor biến thành áp đặt. "Kinh nghiệm của tôi là..." nhưng kèm theo ánh mắt thất vọng nếu người ta không làm theo. Mẹo: sau khi chia sẻ kinh nghiệm, hãy nói rõ "nhưng tình huống của bạn có thể khác, bạn tự cân nhắc nhé" — và thật lòng chấp nhận nếu họ chọn khác.
Mẹo tổng quát: Hãy nhớ rằng ngoài ba stance này, Scrum Master còn nhiều stance khác (Facilitator, Change Agent, Impediment Remover...) sẽ xuất hiện ở các bài sau. Ba stance Teacher–Mentor–Coach là nền móng. Thành thạo việc đọc tình huống và chọn đúng một trong ba, bạn đã có nền tảng vững cho mọi stance phức tạp hơn.
Bài tập thực hành
Bài tập 1 — Nhật ký stance (1 tuần). Mỗi ngày, ghi lại 3 tương tác đáng chú ý với team. Với mỗi tương tác, viết: (a) bạn đã ở stance nào, (b) đáng lẽ stance nào phù hợp hơn, (c) vì sao. Cuối tuần, đếm tỷ lệ Teacher / Mentor / Coach của bạn. Đa số Scrum Master mới sẽ giật mình vì tỷ lệ Teacher quá cao.
Bài tập 2 — Phân loại tình huống. Với mỗi tình huống sau, chọn stance phù hợp nhất và giải thích:
- Một dev mới hỏi "Definition of Done là gì?" → (gợi ý: khoảng trống kiến thức khách quan).
- Team tranh cãi không dứt về cách ước lượng, ai cũng đủ năng lực nhưng bế tắc → (gợi ý: họ có nguồn lực, cần được giúp tự gỡ).
- Một Scrum Master mới bạn đang kèm hỏi "làm sao để buổi Retro bớt nhàm chán?" → (gợi ý: thiếu kinh nghiệm, có động lực).
Bài tập 4 — Tự đánh giá leading question. Ghi âm (với sự đồng ý) hoặc tự nhớ lại một buổi coaching gần nhất. Đếm xem bao nhiêu câu hỏi của bạn thực sự mở (bạn không biết câu trả lời) và bao nhiêu là câu hỏi dẫn dắt trá hình. Mục tiêu: tăng dần tỷ lệ câu hỏi mở thật sự.
Tóm tắt
Coaching Stance là khả năng nhận biết và luân chuyển giữa ba "tư thế" nền tảng của một Scrum Master: Teacher (trao kiến thức khách quan khi có khoảng trống hiểu biết), Mentor (chia sẻ kinh nghiệm như một lựa chọn, không áp đặt, đặc biệt khi người đối diện thiếu kinh nghiệm nhưng có động lực), và Coach (không trao câu trả lời, mà dùng câu hỏi và sự lắng nghe để giúp người khác tự khám phá, xây dựng năng lực tự quản).
Điều phân biệt một Scrum Master cấp PSM II không phải là làm chủ một stance, mà là chẩn đoán đúng tình huống và chọn đúng stance một cách có chủ đích — rồi chuyển đổi linh hoạt trong cùng một cuộc trò chuyện. Cái bẫy lớn nhất là mắc kẹt ở Teacher vì nó dễ chịu, tạo ra một team phụ thuộc vào bạn. Cái bẫy tinh vi nhất là "coaching giả" — dùng câu hỏi dẫn dắt để lùa người ta về đáp án bạn đã định sẵn.
Hãy mặc định nghiêng về Coach để xây năng lực tự quản cho team, nhưng đừng giáo điều: khi có khoảng trống kiến thức thật, dạy là đúng. Thước đo thành công của bạn không phải số vấn đề bạn giải, mà là số vấn đề team tự giải mà không cần đến bạn. Đó là tinh thần servant leadership mà chúng ta sẽ theo đuổi suốt khóa học này.