Bài 46 — Coaching + Mentoring trong Agile

Mở đầu — vì sao bài này quan trọng

Bạn đã đi qua rất nhiều bài về framework, về kỹ thuật, về metrics. Nhưng có một sự thật khó chịu mà bất kỳ ai từng "rollout Scrum" cũng sớm nhận ra: bạn có thể dạy cho một đội ngũ thuộc lòng 3-5-3, nhưng bạn không thể ép họ thay đổi cách họ tư duy và hành xử. Một đội có thể chạy Daily Scrum đủ 15 phút mỗi ngày trong sáu tháng mà vẫn không hề tự tổ chức, vẫn chờ sếp giao việc, vẫn giấu vấn đề. Framework cho bạn cái khung; chính coaching và mentoring mới là thứ làm cho con người trong cái khung đó thực sự trưởng thành.

Đây là kỹ năng phân biệt một Scrum Master "chạy ceremony" với một Scrum Master thực thụ, và là cây cầu bắt buộc nếu bạn muốn tiến lên vai trò Agile Coach (chúng ta sẽ bàn sâu về lộ trình nghề này ở Bài 57). Nhiều người Việt làm PM giỏi về kế hoạch, giỏi về Excel, nhưng khi chuyển sang Agile lại lúng túng vì bản chất công việc đã đổi: từ điều khiển con người sang phát triển con người. Bài này trang bị cho bạn tư duy và bộ công cụ để làm điều đó.

Khái niệm cốt lõi

Bốn vai trò dễ bị nhầm lẫn: Trainer, Mentor, Consultant, Coach

Sai lầm phổ biến nhất là dùng một cách tiếp cận cho mọi tình huống. Bốn vai trò dưới đây khác nhau về ai nắm câu trả lời và mức độ chỉ dẫn:

Điểm mấu chốt: coaching giả định rằng người đối diện đã có năng lực và câu trả lời nằm bên trong họ — nhiệm vụ của bạn là khơi nó ra, không phải nhồi nó vào. Trong khi đó mentoring là bạn cho mượn kinh nghiệm của chính mình, training là bạn truyền đạt kiến thức chuẩn hóa, và consulting là bạn bán giải pháp.

Một Agile Coach thực thụ phải biết chuyển kênh linh hoạt. Nếu đội đang thiếu kiến thức nền (chưa biết Story Points là gì) mà bạn cứ ngồi đặt câu hỏi khai vấn "Theo em thì nên ước lượng thế nào?", bạn đang lãng phí thời gian của mọi người — lúc đó hãy đeo mũ Trainer. Ngược lại, nếu đội đã biết thừa kiến thức nhưng đang né tránh một quyết định khó, mà bạn lại nhảy vào "consult" giải pháp, bạn đang cướp đi cơ hội trưởng thành của họ.

Mô hình GROW — bộ khung coaching kinh điển

Khi đeo mũ Coach, framework phổ biến và dễ áp dụng nhất là GROW (John Whitmore):

• G — Goal (Mục tiêu): "Kết thúc cuộc nói chuyện này em muốn đạt được điều gì?"
• R — Reality (Thực tại): "Hiện tại tình hình thực sự đang thế nào? Em đã thử gì rồi?"
• O — Options (Lựa chọn): "Có những hướng nào em có thể đi? Còn cách nào khác nữa không?"
• W — Will / Way forward (Cam kết hành động): "Vậy em sẽ làm gì, từ khi nào, và làm sao anh biết em đã làm?"

GROW giúp bạn không sa vào việc giải hộ mà giữ trách nhiệm ở phía người được coach.

Thang đo can thiệp: từ "đẩy" đến "kéo"

Hãy hình dung một trục liên tục (continuum). Bên trái là directive (chỉ dẫn — bạn nói cho họ phải làm gì: dạy, tư vấn, đưa lời khuyên). Bên phải là non-directive (khai mở — bạn lắng nghe, phản chiếu, đặt câu hỏi). Người mới vào nghề thường dùng quá nhiều bên trái vì nó nhanh và cho cảm giác "mình hữu ích". Nhưng coaching đẳng cấp nằm ở khả năng dịch chuyển về bên phải khi đội đã đủ năng lực — đó chính là cách bạn xây dựng đội tự tổ chức (self-organizing) thay vì đội phụ thuộc vào bạn.

Coaching ở ba cấp độ

Agile Coach chuyên nghiệp coach ở ba tầng: cá nhân (1-1 với một Developer đang stress), đội nhóm (giúp cả team xử lý xung đột — nối với Bài 48), và tổ chức (làm việc với lãnh đạo để gỡ rào cản hệ thống — nối với Bài 31). Bài này tập trung vào tầng cá nhân và đội nhóm, vì đó là nơi một Scrum Master bắt đầu.

Tình huống thực tế

Tình huống 1 — Scrum Master "giải hộ" quá nhiều tại một fintech ở TP.HCM

Một startup fintech khoảng 40 người ở Quận 4, TP.HCM, có anh Tuấn làm Scrum Master cho hai team. Tuấn rất nhiệt tình: bất kỳ ai gặp blocker, anh đều xắn tay vào tự gỡ — gọi điện cho phòng IT, tự viết lại ticket, tự thương lượng với Product Owner. Kết quả ngắn hạn rất đẹp: blocker được xử lý nhanh, sprint nào cũng "xanh".

Nhưng sau bốn tháng, một điều kỳ lạ xảy ra: mỗi khi Tuấn đi công tác ba ngày, velocity của team rớt gần 40%, các blocker chất đống chờ anh về. Trong một buổi 1-1 với Agile Coach thuê ngoài, Tuấn nhận ra mình đã vô tình biến cả đội thành những người phụ thuộc. Anh đang ở cực directive 100% của thang đo.

Diễn giải: Tuấn đang làm consulting và "rescue" (giải cứu), không phải coaching. Mỗi lần anh giải hộ, anh gửi đi một thông điệp ngầm: "Các bạn không tự làm được đâu." Coach hướng dẫn anh áp dụng một nguyên tắc đơn giản: khi có người mang blocker tới, thay vì lao vào xử lý, hãy hỏi "Theo em mình có thể làm gì? Em cần ai hỗ trợ?" rồi đứng lùi lại. Sáu tuần đầu chậm và khó chịu, nhưng đến sprint thứ tư team đã tự gỡ được 70% blocker mà không cần Tuấn.

Bài học: Mục tiêu của coaching không phải làm cho mình cần thiết, mà là làm cho mình dần trở nên không cần thiết. Một Scrum Master giỏi để lại một đội tự đứng vững khi anh ta rời đi.

Tình huống 2 — Mentoring một junior PM tại công ty outsourcing ở Đà Nẵng

Chị Linh, một Agile Coach tại một công ty outsourcing 300 người ở Đà Nẵng, được giao kèm cặp Hằng — một Business Analyst vừa được đề bạt làm Scrum Master, chưa có kinh nghiệm. Đây là tình huống mà mentoring đúng hơn coaching thuần túy, vì Hằng còn thiếu cả kiến thức nền lẫn sự tự tin.

Linh không ngồi hỏi "Theo em facilitate Retrospective thế nào?" — vì Hằng chưa từng làm, hỏi vậy chỉ tạo lo lắng. Thay vào đó Linh kể lại lần đầu chính mình làm Retro thất bại ra sao (cả phòng im lặng suốt 30 phút), rồi cho Hằng "shadow" — ngồi quan sát Linh facilitate ba sprint, sau đó đảo ngược: Hằng làm, Linh ngồi sau quan sát và feedback riêng. Linh dùng kỹ thuật feedback theo mô hình SBI (Situation – Behavior – Impact): "Ở phút thứ 10 (tình huống), khi anh Nam ngắt lời, em đã chuyển sang câu hỏi khác (hành vi), khiến ý kiến của chị Mai bị bỏ lửng (tác động) — em thấy có thể xử lý khác đi không?"

Diễn giải: Linh đã đọc đúng "mức độ sẵn sàng" của Hằng và chọn đúng kênh. Khi Hằng cứng cáp hơn sau ba tháng, Linh chuyển dịch dần sang coaching — bớt kể chuyện, tăng đặt câu hỏi.

Bài học: Chọn vai trò theo mức độ trưởng thành của người đối diện, và có lộ trình dịch chuyển từ mentoring sang coaching khi họ lớn lên. Mentoring cho mượn kinh nghiệm; coaching trả lại quyền tự chủ.

Tình huống 3 — Coach tổ chức không có "mandate" tại một ngân hàng

Một Agile Coach được một ngân hàng tầm trung ở Hà Nội thuê để "giúp team IT nhanh hơn". Anh phát hiện vấn đề thật không nằm ở team mà ở chỗ mọi quyết định đều phải qua ba lớp phê duyệt của khối nghiệp vụ. Anh viết một bản phân tích rất sắc bén (consulting) gửi ban lãnh đạo... và bị phớt lờ.

Diễn giải: Anh đã consult khi tổ chức chưa sẵn sàng nghe. Thiếu cái gọi là coaching alliance — sự đồng thuận về việc "chúng ta đang cùng giải quyết vấn đề gì và tôi được phép can thiệp tới đâu". Ở lần thứ hai, anh đổi cách: tổ chức một workshop để chính các lãnh đạo tự nhìn ra nút thắt phê duyệt qua bài tập vẽ value stream. Khi họ tự kết luận, họ mới hành động.

Bài học: Coaching ở tầng tổ chức cần được "mời" và cần thiết lập thỏa thuận rõ ràng trước khi can thiệp. Người ta chống lại giải pháp bị áp đặt, nhưng bảo vệ giải pháp do chính mình tìm ra.

Hướng dẫn từng bước

Đây là quy trình để bạn vận hành một cuộc coaching/mentoring có cấu trúc:

• Thiết lập thỏa thuận (Coaching Alliance). Trước khi vào việc, làm rõ: mục tiêu của mối quan hệ này là gì, tần suất gặp, tính bảo mật, và "tôi được phép thách thức bạn tới đâu?". Bỏ qua bước này là lý do số một khiến coaching thất bại.

• Chẩn đoán: họ thiếu gì? Hỏi thầm trong đầu: người này thiếu kiến thức (→ Train), thiếu kinh nghiệm/sự tự tin (→ Mentor), thiếu giải pháp cho vấn đề hệ thống (→ Consult), hay đã có đủ năng lực chỉ cần được khơi mở (→ Coach)? Chọn mũ phù hợp.

• Lắng nghe ở cấp độ sâu. Lắng nghe để hiểu, không phải để chuẩn bị câu trả lời. Dùng im lặng có chủ đích — sau khi đặt một câu hỏi tốt, đếm thầm đến 5 trước khi nói tiếp.

• Đặt câu hỏi mở (powerful questions). Ưu tiên câu hỏi bắt đầu bằng "Cái gì" và "Như thế nào", tránh "Tại sao" (dễ gây phòng thủ). Ví dụ: "Điều gì đang ngăn em?", "Nếu không có rào cản đó thì em sẽ làm gì?".

• Dùng GROW làm xương sống cho cuộc trò chuyện: Goal → Reality → Options → Will.

• Chốt cam kết hành động cụ thể. Kết thúc luôn bằng: ai làm gì, đến khi nào, và dấu hiệu nào cho thấy đã xong. Không có bước này, cuộc coaching chỉ là buổi tâm sự dễ chịu.

• Theo dõi và phản chiếu. Buổi sau bắt đầu bằng "Lần trước em định làm X, kết quả thế nào?". Vòng lặp này chính là động cơ tạo trách nhiệm.

Lỗi thường gặp & mẹo

• Lỗi: Coaching trong khi đáng lẽ phải Train. Đặt câu hỏi khai vấn cho người chưa có kiến thức nền là một kiểu "tra tấn lịch sự". Mẹo: nếu người đó thật sự không thể biết câu trả lời, hãy dạy thẳng.

• Lỗi: "Rescue" — giải hộ mọi việc. Như anh Tuấn ở trên. Mẹo: trước khi nhảy vào, tự hỏi "Nếu mình không làm việc này, ai sẽ học được gì?".

• Lỗi: Câu hỏi đóng trá hình lời khuyên. "Em đã thử nói chuyện với PO chưa?" — đây không phải câu hỏi coaching, đây là lời khuyên đội lốt. Mẹo: hỏi mở thật sự — "Em đã thử những hướng nào rồi?".

• Lỗi: Bỏ qua coaching alliance. Can thiệp khi chưa được "mời" sẽ vấp phải đề kháng (xem Bài 32). Mẹo: luôn xin phép — "Anh có thể chia sẻ một góc nhìn được không?".

• Lỗi: Coach mà thiếu năng lực tự nhận thức. Bạn không thể đưa người khác đi xa hơn nơi chính bạn đã đến. Mẹo: tìm cho mình một mentor/supervisor riêng, và thực hành tự phản chiếu sau mỗi buổi.

• Mẹo văn hóa Việt: Trong môi trường còn nặng tôn ti, nhân viên thường ngại nói thật. Hãy xây an toàn tâm lý trước: bắt đầu bằng coaching 1-1 kín đáo, dùng câu hỏi nhẹ, và tuyệt đối giữ bảo mật. Niềm tin có rồi, coaching nhóm mới hiệu quả.

Bài tập thực hành

• Phân loại tình huống (15 phút): Lấy 5 tình huống bạn đã gặp tuần qua với đội. Với mỗi tình huống, ghi rõ bạn đã phản ứng như Trainer/Mentor/Consultant/Coach, và bạn đáng lẽ nên dùng vai trò nào. Tìm ra khuynh hướng mặc định của bạn (đa số người Việt mới làm hay nghiêng về Consultant/Rescue).

• Đổi câu khẳng định thành câu hỏi (10 phút): Viết ra 5 lời khuyên gần nhất bạn đã đưa cho đội. Biến mỗi câu thành một câu hỏi mở. Ví dụ "Em nên tách story này ra" → "Em thấy story này có thể chia nhỏ theo cách nào?".

• Một cuộc GROW thật (30 phút): Tìm một đồng nghiệp đang có vướng mắc nghề nghiệp thật. Chạy đúng bốn bước GROW, chỉ đặt câu hỏi, tuyệt đối không đưa giải pháp. Kết thúc bằng một cam kết hành động cụ thể. Sau đó tự đánh giá: bạn đã "lỡ tay" đưa lời khuyên bao nhiêu lần?

• Luyện im lặng (1 tuần): Trong các buổi 1-1 tuần này, sau mỗi câu hỏi hãy đếm thầm đến 5 trước khi nói. Ghi lại điều gì xảy ra — thường người đối diện sẽ tự nói ra điều sâu sắc hơn.

Tóm tắt

• Bốn vai trò khác nhau ở "ai nắm câu trả lời": Trainer truyền kiến thức, Mentor cho mượn kinh nghiệm, Consultant bán giải pháp, Coach khơi mở câu trả lời từ chính người đối diện. Một Agile Coach giỏi chuyển kênh linh hoạt theo tình huống.
• Đọc đúng mức độ trưởng thành của đội/cá nhân rồi chọn vị trí trên thang directive ↔ non-directive; có lộ trình dịch chuyển từ mentoring sang coaching khi họ lớn lên.
• Đừng "rescue". Mục tiêu là làm cho mình dần trở nên không cần thiết, xây đội tự tổ chức chứ không phải đội phụ thuộc.
• GROW (Goal–Reality–Options–Will) là khung coaching dễ dùng; luôn chốt bằng cam kết hành động cụ thể và theo dõi ở buổi sau.
• Thiết lập coaching alliance trước khi can thiệp, đặc biệt ở tầng tổ chức — người ta bảo vệ giải pháp do chính mình tìm ra, và chống lại giải pháp bị áp đặt.
• Trong bối cảnh Việt Nam, an toàn tâm lý và bảo mật là điều kiện tiên quyết để coaching có hiệu quả. Đây cũng là nền tảng cho lộ trình nghề Agile Coach mà ta sẽ bàn ở Bài 57.