Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là bác sĩ, và một bệnh nhân bước vào phòng khám than rằng "tôi bị đau đầu". Một bác sĩ non tay sẽ lập tức kê thuốc giảm đau và cho về. Một bác sĩ giỏi sẽ hỏi: đau đã bao lâu? Đau ở vị trí nào? Có kèm theo sốt, mờ mắt, buồn nôn không? Bởi vì cơn đau đầu có thể là triệu chứng của hàng chục căn bệnh khác nhau — từ thiếu ngủ tầm thường cho đến u não nguy hiểm. Kê thuốc giảm đau cho người bị u não chẳng khác nào lau khô sàn nhà trong khi vòi nước vẫn đang xối xả.
Đây chính là khác biệt lớn nhất giữa một Scrum Master ở cấp PSM I và một Scrum Master cấp PSM II. Ở cấp độ sơ cấp, bạn thấy "team không hoàn thành Sprint" thì bạn áp dụng giải pháp có sẵn: thêm buổi refinement, cắt scope, hô hào team cố gắng. Ở cấp độ senior, bạn dừng lại và hỏi: vì sao team không hoàn thành Sprint? Câu trả lời có thể là tech debt, có thể là Product Owner thay đổi yêu cầu liên tục, có thể là team bị kéo đi làm việc khác, hoặc có thể là một vấn đề tổ chức sâu hơn mà không ai dám nói ra.
Bài học này dạy bạn một thứ rất cụ thể: Diagnosis Framework — bộ khung tư duy giúp bạn chẩn đoán đúng gốc rễ (root cause) trước khi hành động. Treating symptom ≠ treating disease (chữa triệu chứng không phải chữa bệnh). Một SM trưởng thành dành thời gian để hiểu trước khi làm. Nắm vững kỹ năng này, bạn sẽ ngừng chữa cháy liên miên và bắt đầu giải quyết vấn đề tận gốc — đó là lý do tổ chức sẵn sàng trả lương cao cho bạn.
Khái niệm cốt lõi
Triệu chứng (symptom) vs. Gốc rễ (root cause)
Triệu chứng là cái bạn quan sát thấy: velocity giảm, Daily Scrum kéo dài 45 phút, team cãi nhau trong Retrospective, stakeholder phàn nàn về chất lượng. Gốc rễ là nguyên nhân thật sự sinh ra các triệu chứng đó. Đặc điểm nguy hiểm của triệu chứng là chúng dễ thấy, dễ đo, dễ khiến ta hành động vội. Còn gốc rễ thường ẩn sâu, khó chịu khi đối mặt, và đôi khi đụng chạm đến những người có quyền lực.
Một quy tắc đáng nhớ: nếu giải pháp của bạn khiến triệu chứng biến mất một thời gian rồi quay lại, gần như chắc chắn bạn mới chỉ chữa triệu chứng.
Tại sao SM thường nhảy thẳng vào giải pháp?
Có ba áp lực vô hình. Thứ nhất là áp lực phải tỏ ra hữu ích — chúng ta sợ bị xem là kẻ "chỉ ngồi quan sát". Thứ hai là thiên kiến hành động (action bias) — não người thích cảm giác đang-làm-gì-đó hơn là đang-suy-nghĩ. Thứ ba là sự thoải mái của giải pháp quen thuộc — nếu công cụ duy nhất bạn có là cái búa, mọi vấn đề trông đều giống cái đinh. SM senior phải có ý thức kháng lại cả ba áp lực này.
Ba tầng chẩn đoán
Tôi muốn bạn ghi nhớ một mô hình phân tầng để định vị gốc rễ:
- Tầng cá nhân (Individual): vấn đề nằm ở một con người cụ thể — thiếu kỹ năng, thiếu động lực, hiểu sai vai trò.
- Tầng nhóm (Team): vấn đề nằm ở tương tác trong nhóm — thiếu thỏa thuận làm việc, xung đột ngầm, thiếu tin tưởng.
- Tầng hệ thống (System/Organization): vấn đề nằm ở cấu trúc, chính sách, cách tổ chức vận hành — KPI sai lệch, phụ thuộc giữa các phòng ban, văn hóa đổ lỗi.
Các công cụ chẩn đoán nền tảng
Bạn không cần phát minh lại bánh xe. Có vài công cụ kinh điển:
- 5 Whys (Hỏi tại sao 5 lần): liên tục hỏi "tại sao" để bóc dần các lớp nguyên nhân cho đến khi chạm gốc.
- Fishbone / Ishikawa Diagram (Sơ đồ xương cá): phân loại các nguyên nhân tiềm năng theo nhóm (con người, quy trình, công cụ, môi trường…) để không bỏ sót.
- Gemba walk: đi đến "hiện trường" — nơi công việc thực sự diễn ra — để quan sát trực tiếp thay vì nghe báo cáo.
- Systems thinking — vòng lặp nhân quả: nhìn ra các vòng phản hồi (feedback loop) khiến vấn đề tự duy trì.
Tình huống thực tế
Tình huống 1 — Sàn thương mại điện tử Tiki: "Team chậm vì lười"
Tại một squad backend của một sàn TMĐT lớn ở TP.HCM (gọi là squad Thanh Toán), velocity trung bình tụt từ 42 xuống 24 story point trong ba Sprint liên tiếp. Engineering Manager kết luận thẳng: "Team này mất lửa, cần thay vài người." Anh ấy đã định luân chuyển hai developer đi nơi khác.
Vị Scrum Master mới về — chúng ta gọi là chị Lan — không chấp nhận kết luận vội. Chị làm một Gemba walk: ngồi cạnh team trong ba ngày, xem họ thực sự làm gì. Chị phát hiện mỗi developer mất trung bình 2-3 tiếng mỗi ngày chỉ để chờ môi trường staging được giải phóng, vì cả công ty chia sẻ chung một môi trường staging duy nhất. Áp dụng 5 Whys: Vì sao velocity giảm? → Vì code xong không test được ngay. → Vì sao? → Vì phải chờ staging. → Vì sao? → Vì chỉ có một staging dùng chung cho 6 squad. → Vì sao? → Vì ngân sách hạ tầng bị đóng băng từ quý trước.
Gốc rễ hóa ra nằm ở tầng hệ thống, không phải tầng cá nhân. Việc thay người sẽ chẳng giải quyết được gì — người mới cũng sẽ ngồi chờ staging y như vậy. Bài học: triệu chứng "team chậm" đã suýt dẫn đến một quyết định nhân sự sai lầm và bất công. Chỉ một phép chẩn đoán đúng đã chuyển hướng cuộc trò chuyện từ "đổ lỗi cho con người" sang "đầu tư thêm môi trường staging" — một việc rẻ hơn nhiều so với mất hai kỹ sư giỏi.
Tình huống 2 — Công ty outsourcing FPT: Daily Scrum "vô hồn"
Một dự án outsourcing cho khách hàng Nhật, team 8 người tại Hà Nội. Triệu chứng: Daily Scrum biến thành buổi báo cáo cho Project Manager, ai cũng nói với PM chứ không nói với nhau, không khí căng thẳng và hình thức. SM trẻ ban đầu định "fix" bằng cách đổi format Daily: dùng walking-the-board, đổi câu hỏi, đổi giờ. Đã thử ba kiểu trong một tháng. Không ăn thua — chỉ vài hôm là đâu lại vào đấy.
Khi đứng lại chẩn đoán nghiêm túc bằng sơ đồ xương cá, SM nhận ra mọi nhánh đều quy về một điểm: PM đánh giá KPI cá nhân của từng developer dựa trên báo cáo Daily. Nói cách khác, hệ thống khen thưởng đang dạy mọi người "hãy trình diễn cho PM thấy mình bận rộn", chứ không phải "hãy phối hợp để đạt Sprint Goal". Đây là gốc rễ tầng hệ thống đội lốt một vấn đề tầng nhóm.
Không format Daily nào sửa được điều này. Giải pháp thực sự là một cuộc đối thoại khó với PM về việc tách KPI cá nhân ra khỏi sự kiện Scrum. Bài học rút ra: khi bạn đã thử nhiều giải pháp bề mặt mà triệu chứng cứ tái phát, đó là tín hiệu rõ ràng rằng bạn đang chẩn đoán sai tầng. Hãy hỏi "ai được lợi gì từ hành vi hiện tại?" — câu hỏi này thường lôi gốc rễ ra ánh sáng.
Tình huống 3 — Startup fintech tại Singapore: "Cần thêm refinement"
Một startup fintech giai đoạn Series A, team product. Triệu chứng: cứ cuối Sprint là 30-40% công việc dở dang (carry-over). Phản xạ đầu tiên của cả team là "chúng ta refine chưa đủ kỹ, hãy thêm một buổi refinement nữa mỗi tuần". Họ thêm thật. Ba Sprint sau, carry-over vẫn nguyên, và giờ team còn mệt hơn vì họp nhiều hơn.
SM senior vào cuộc, vẽ vòng lặp nhân quả (causal loop) và phỏng vấn từng người. Phát hiện: Product Owner thường xuyên nhận yêu cầu "khẩn" trực tiếp từ CEO giữa Sprint và lặng lẽ tuồn vào Sprint Backlog. Việc thêm refinement chẳng liên quan gì — gốc rễ là không có cơ chế bảo vệ Sprint khỏi sự can thiệp của lãnh đạo, cộng với việc PO chưa đủ tự tin để nói "không" với CEO.
Bài học: trùng hợp về thời điểm (carry-over xảy ra ở khâu thực thi) khiến ai cũng tưởng vấn đề nằm ở refinement. Nhưng nguyên nhân thật nằm ở thượng nguồn (cách công việc được đưa vào). Một SM giỏi luôn truy ngược dòng chảy công việc, không dừng lại ở nơi triệu chứng xuất hiện.
Hướng dẫn từng bước
Đây là quy trình chẩn đoán bảy bước bạn có thể áp dụng cho bất kỳ vấn đề nào:
Bước 1 — Mô tả triệu chứng một cách trung lập. Viết ra điều bạn quan sát được bằng dữ liệu, không phán xét. Viết "ba Sprint gần nhất hoàn thành 60% Sprint Goal", không viết "team yếu kém".
Bước 2 — Cưỡng lại cơn ngứa giải pháp. Đặt ra một quy ước cá nhân: chưa được đề xuất giải pháp nào cho đến khi qua bước 5. Hãy ghi giải pháp đầu tiên loé lên trong đầu ra giấy rồi gác lại — nó thường là chữa triệu chứng.
Bước 3 — Thu thập dữ liệu từ nhiều nguồn. Dùng Gemba walk (quan sát trực tiếp), phỏng vấn 1-1, xem metrics (velocity, lead time, cumulative flow). Đừng tin một nguồn duy nhất. Mỗi người sẽ kể câu chuyện qua lăng kính của họ.
Bước 4 — Truy gốc bằng 5 Whys hoặc Fishbone. Bóc từng lớp. Mẹo: nếu một câu "vì sao" dẫn bạn đến một con người, hãy hỏi thêm "vì sao người đó lại hành xử như vậy trong hệ thống này?" để tránh dừng ở tầng cá nhân quá sớm.
Bước 5 — Định vị tầng của gốc rễ. Cá nhân, nhóm hay hệ thống? Phần lớn gốc rễ thực sự nằm ở tầng hệ thống. Tự kiểm tra: nếu thay con người mà vấn đề vẫn còn, đó là vấn đề hệ thống.
Bước 6 — Kiểm chứng giả thuyết. Gốc rễ bạn tìm ra mới chỉ là giả thuyết. Mang nó về cho team: "Tôi nghĩ vấn đề thật sự là X, mọi người thấy đúng không?" Để chính team xác nhận hoặc bác bỏ. Việc này vừa kiểm tra độ chính xác, vừa tạo ownership.
Bước 7 — Chỉ khi đó mới thiết kế giải pháp. Và hãy thiết kế thử nghiệm nhỏ (experiment) có thể đo lường, thay vì "đại tu" toàn bộ. Đặt giả thuyết: "Nếu làm X, chúng ta kỳ vọng Y thay đổi sau hai Sprint." Rồi đo.
Lỗi thường gặp & mẹo
Lỗi 1 — Dừng 5 Whys quá sớm ở tầng con người. Khi câu trả lời là "vì anh A làm ẩu", nhiều người dừng lại và quy trách nhiệm. Hãy luôn hỏi tiếp một bước: "Vì sao hệ thống của chúng ta cho phép/khuyến khích sự ẩu đó tồn tại?"
Lỗi 2 — Chẩn đoán một mình trong phòng kín. Bạn không phải bác sĩ pháp y khám nghiệm tử thi. Chẩn đoán cùng team sẽ chính xác hơn nhiều vì họ sống trong vấn đề mỗi ngày. SM một mình rất dễ rơi vào thiên kiến xác nhận (chỉ thấy bằng chứng ủng hộ giả thuyết có sẵn của mình).
Lỗi 3 — Nhầm tương quan với nhân quả. "Từ khi anh B vào team thì velocity giảm" — chưa chắc anh B là nguyên nhân. Có thể anh B vào đúng lúc team nhận mảng việc khó hơn. Hãy cảnh giác với các trùng hợp về thời điểm.
Lỗi 4 — Tê liệt vì phân tích (analysis paralysis). Chẩn đoán kỹ không có nghĩa là chẩn đoán mãi mãi. Với vấn đề nhỏ, 30 phút 5 Whys là đủ. Hãy cân chỉnh độ sâu chẩn đoán theo mức độ nghiêm trọng của vấn đề.
Mẹo vàng: Câu hỏi quyền lực nhất khi truy gốc rễ tổ chức là "Ai được lợi gì từ việc giữ nguyên hiện trạng?" Hành vi vô lý nhìn từ bên ngoài thường rất hợp lý nếu nhìn từ động cơ của người trong cuộc.
Mẹo thứ hai: Hãy phân biệt vấn đề "đơn giản — phức tạp — rối ren" (theo khung Cynefin). Vấn đề rối ren (complex) không có quan hệ nhân-quả tuyến tính rõ ràng; với loại này, đừng cố tìm một root cause duy nhất, mà hãy chạy nhiều thử nghiệm nhỏ song song và quan sát.
Bài tập thực hành
Bài tập 1 — 5 Whys trên một vấn đề thật. Chọn một vấn đề team bạn đang gặp tuần này. Tự làm 5 Whys trên giấy. Sau đó làm lại cùng team trong 20 phút. So sánh: gốc rễ bạn tìm một mình và gốc rễ team tìm cùng nhau có khác nhau không? Điều đó nói gì với bạn?
Bài tập 2 — Phân loại tầng. Lấy ba vấn đề gần nhất trong Retrospective của team. Với mỗi cái, xác định: triệu chứng là gì, gốc rễ giả định là gì, nó thuộc tầng cá nhân / nhóm / hệ thống? Bao nhiêu phần trăm thực ra thuộc tầng hệ thống?
Bài tập 3 — Thử nghiệm "Ai được lợi". Chọn một hành vi khó hiểu trong tổ chức (ví dụ: tại sao mọi người dự một cuộc họp vô bổ mãi không bỏ?). Liệt kê tất cả những người liên quan và lợi ích họ ngầm nhận được từ hiện trạng. Bạn sẽ ngạc nhiên về những gì tìm ra.
Bài tập 4 — Viết lại như nhà chẩn đoán. Lấy một lần bạn từng "nhảy thẳng vào giải pháp" trong quá khứ. Viết lại tình huống đó: nếu áp dụng quy trình bảy bước, bạn sẽ làm khác đi ở đâu, và gốc rễ thật có thể là gì?
Tóm tắt
Khác biệt cốt lõi giữa SM cấp PSM I và PSM II nằm ở một thói quen tưởng nhỏ mà thay đổi tất cả: dành thời gian để hiểu trước khi hành động. Treating symptom không bao giờ chữa khỏi disease — triệu chứng được dập tắt tạm thời rồi sẽ quay lại, thậm chí nặng hơn, trong khi nguồn lực của bạn cạn dần vì chữa cháy.
Hãy ghi nhớ ba điều. Một, mọi vấn đề có ba tầng — cá nhân, nhóm, hệ thống — và gốc rễ thật thường ẩn ở tầng hệ thống, nơi khó chịu nhất để nhìn vào. Hai, bạn có sẵn bộ công cụ kinh điển: 5 Whys, sơ đồ xương cá, Gemba walk, systems thinking; việc của bạn là kỷ luật sử dụng chúng thay vì phản xạ theo bản năng. Ba, chẩn đoán là việc làm cùng team, không phải làm thay team — và gốc rễ bạn tìm ra luôn chỉ là giả thuyết cho đến khi được kiểm chứng bằng thực tế.
Lần tới khi một triệu chứng xuất hiện và bạn cảm thấy cơn ngứa muốn ra tay ngay lập tức, hãy hít một hơi và tự hỏi: Mình đang nhìn thấy con bệnh, hay chỉ đang nhìn thấy cơn sốt? Câu hỏi đó, lặp đi lặp lại đủ nhiều, sẽ biến bạn từ một người chữa cháy thành một người thực sự chữa lành tổ chức.