Mở đầu — vì sao bài này quan trọng
Là một Scrum Master, bạn sẽ rất quen với cảnh này: team gặp đi gặp lại cùng một vấn đề. Sprint nào cũng có story bị "carry over", lần nào cũng có bug tràn về sau khi release, daily nào cũng nghe câu "đang chờ bên kia". Trong retrospective, mọi người đổ lỗi loanh quanh, đưa ra vài giải pháp cho có, rồi sprint sau vấn đề lại quay về y nguyên. Đó là dấu hiệu kinh điển của việc team đang xử lý triệu chứng thay vì nguyên nhân gốc.
Ở Bài 15, bạn đã làm quen với Five Whys — một công cụ đào sâu theo chiều dọc, đi theo một chuỗi nhân quả tuyến tính. Nhưng đời thực hiếm khi tuyến tính. Một vấn đề như "release chậm" thường không có một nguyên nhân duy nhất, mà là sự cộng hưởng của nhiều yếu tố đến từ nhiều hướng khác nhau: con người, quy trình, công cụ, môi trường. Đây chính là lúc Fishbone Diagram (sơ đồ xương cá), hay còn gọi là Ishikawa Diagram hoặc Cause-and-Effect Diagram, phát huy sức mạnh.
Fishbone giúp bạn và team nhìn vấn đề theo chiều rộng — bung ra tất cả các nhóm nguyên nhân tiềm năng một cách có cấu trúc, trực quan, để không bỏ sót góc nào. Nó biến một cuộc tranh luận hỗn loạn thành một bức tranh có hệ thống mà cả team cùng nhìn vào và cùng đồng thuận. Với một Scrum Master, đây là một trong những công cụ facilitation giá trị nhất để dẫn dắt team từ "cảm giác bực bội" đến "hiểu rõ vấn đề".
Khái niệm cốt lõi
Fishbone Diagram được Kaoru Ishikawa — một chuyên gia kiểm soát chất lượng người Nhật — phát triển vào những năm 1960 trong bối cảnh quản lý chất lượng tại các nhà máy. Tên gọi "xương cá" đến từ hình dáng của sơ đồ: khi vẽ xong, nó trông giống bộ xương cá nằm ngang.
Cấu trúc của sơ đồ
Hãy hình dung một con cá:
- Đầu cá (head) — nằm bên phải, ghi phát biểu vấn đề (problem statement). Đây là "effect", tức là hệ quả mà bạn muốn tìm nguyên nhân. Ví dụ: "Tỷ lệ bug production tăng 40% trong quý vừa rồi".
- Xương sống (spine) — đường ngang lớn nối từ đầu cá kéo về bên trái.
- Xương lớn (major bones) — các đường chéo đâm vào xương sống, mỗi đường đại diện cho một nhóm nguyên nhân (category). Đây là phần quan trọng nhất về mặt cấu trúc.
- Xương nhỏ (sub-bones) — các nhánh nhỏ hơn đâm vào xương lớn, ghi các nguyên nhân cụ thể trong từng nhóm. Bạn có thể tiếp tục chia nhỏ nữa thành "xương con của xương nhỏ" khi cần đào sâu.
Các nhóm nguyên nhân chuẩn
Điểm khác biệt lớn nhất giữa Fishbone và Five Whys là Fishbone bắt buộc bạn phân loại nguyên nhân thành các nhóm có sẵn. Việc có khung phân loại giúp não bộ của team không bị "mắc kẹt" ở một hướng duy nhất.
Khung kinh điển trong sản xuất là 6M:
- Manpower (Con người) — kỹ năng, kinh nghiệm, số lượng người, sự sẵn sàng, động lực.
- Machines (Máy móc / Công cụ) — phần cứng, phần mềm, công cụ, hạ tầng.
- Methods (Phương pháp / Quy trình) — cách làm việc, quy trình, chính sách, định nghĩa Done.
- Materials (Nguyên vật liệu / Đầu vào) — dữ liệu đầu vào, yêu cầu, tài liệu, dependency.
- Measurement (Đo lường) — cách đo, chỉ số, độ chính xác của dữ liệu giám sát.
- Mother Nature / Milieu (Môi trường) — văn hóa, không gian làm việc, áp lực bên ngoài, yếu tố tổ chức.
Fishbone khác Five Whys ở đâu
Hai công cụ này bổ trợ cho nhau, không thay thế nhau. Một cách dùng rất hay: Fishbone trước, Five Whys sau. Fishbone giúp bung rộng tất cả nhóm nguyên nhân (chiều rộng), sau đó với mỗi nguyên nhân tiềm năng quan trọng nhất, bạn dùng Five Whys để đào sâu xuống tận gốc (chiều sâu). Fishbone là tấm bản đồ; Five Whys là chiếc xẻng.
Tình huống thực tế
Ví dụ 1: Tiki — Bug production tăng đột biến sau release
Một squad gồm 7 người tại một công ty e-commerce lớn (tạm gọi theo mô hình của Tiki) nhận thấy tỷ lệ bug nghiêm trọng trên production tăng từ trung bình 3 lên 11 trong hai sprint gần nhất. Tech Lead muốn "thêm bước review code", PO muốn "test kỹ hơn", còn vài dev thì thầm bảo nhau là do "deadline ép quá". Mỗi người một hướng, không ai sai nhưng cũng không ai nhìn được bức tranh tổng thể.
Scrum Master quyết định dành 45 phút trong retrospective để vẽ Fishbone. Đầu cá ghi rõ: "Bug nghiêm trọng trên production tăng từ 3 lên 11 trong 2 sprint". Team chọn 5 nhóm: Con người, Quy trình, Công cụ, Đầu vào/Yêu cầu, Môi trường.
Sau khi brainstorm, các xương nhỏ hiện ra:
- Con người: hai dev senior nghỉ phép cùng lúc; một junior mới onboard chưa quen codebase.
- Quy trình: bỏ qua bước code review khi gấp; không có regression test trước release.
- Công cụ: pipeline CI chạy 40 phút nên dev hay skip để release nhanh.
- Đầu vào: yêu cầu thay đổi giữa sprint 3 lần, acceptance criteria mơ hồ.
- Môi trường: chiến dịch sale 12/12 tạo áp lực giao hàng đúng hạn.
Bài học: Fishbone giúp team thấy các nguyên nhân tưởng riêng lẻ thực ra hội tụ về một điểm đòn bẩy. Hành động cuối cùng họ chọn không phải "review kỹ hơn" mơ hồ, mà là một việc cụ thể có thể đo được: tối ưu pipeline CI xuống dưới 15 phút.
Ví dụ 2: FPT Software — Daily Scrum lê thê và vô vị
Một team gia công phần mềm tại một công ty outsourcing lớn ở Việt Nam có daily kéo dài đều đặn 35–40 phút, vượt xa khung 15 phút. Mọi người chán, đến trễ, và buổi họp trở thành nơi báo cáo cho Scrum Master nghe thay vì để team đồng bộ.
Scrum Master vẽ Fishbone với đầu cá: "Daily Scrum luôn kéo dài 35–40 phút và mọi người không thấy giá trị". Thay vì 6M cứng nhắc, anh chọn 4 nhóm gần gũi với team: Con người, Cách thức tổ chức, Công cụ, Giao tiếp.
- Con người: nhiều người kể chi tiết kỹ thuật; client đôi khi tham gia khiến mọi người chuyển sang chế độ "báo cáo".
- Cách tổ chức: không có timebox rõ ràng; bàn cả việc giải quyết vấn đề ngay trong daily thay vì để sau.
- Công cụ: board Jira không cập nhật nên phải đọc lại từ đầu mỗi sáng.
- Giao tiếp: lệch múi giờ với khách hàng Nhật khiến daily bị nhét thêm phần cập nhật cho client.
Bài học: đôi khi giá trị lớn nhất của Fishbone không phải là tìm ra "nguyên nhân", mà là giúp team nhìn thấy một mâu thuẫn cấu trúc mà trước đó họ chỉ cảm nhận mơ hồ. Giải pháp: tách phần cập nhật cho client thành một buổi async riêng, trả daily về đúng mục đích.
Ví dụ 3: Startup fintech — Velocity tụt dốc không rõ lý do
Một startup fintech khoảng 25 người ở TP.HCM thấy velocity của team chính giảm liên tục 4 sprint, từ 42 xuống 26 điểm. Founder lo lắng và bắt đầu nghi ngờ team "lười đi". Scrum Master biết rằng quy kết kiểu đó vừa sai vừa nguy hiểm, nên đề xuất một buổi Fishbone có cả founder tham gia để mọi người cùng nhìn dữ liệu thay vì cảm tính.
Đầu cá: "Velocity giảm 38% trong 4 sprint liên tiếp". Khi các xương được lấp đầy, bức tranh hiện ra rất khác với giả định ban đầu:
- Con người: 2 thành viên bị kéo sang hỗ trợ dự án khác 50% thời gian.
- Quy trình: ngày càng nhiều thời gian dành cho họp cross-team không liên quan.
- Đầu vào: backlog refinement bị bỏ qua 3 sprint nên dev vào sprint mới hiểu yêu cầu.
- Công cụ: môi trường staging hỏng, dev mất nhiều giờ tự dựng lại.
Bài học: Fishbone là công cụ tuyệt vời để chuyển một cuộc trò chuyện cảm tính, dễ quy kết cá nhân thành một cuộc phân tích dựa trên hệ thống. Khi mọi người cùng nhìn vào sơ đồ, năng lượng chuyển từ "đổ lỗi cho ai" sang "sửa cái gì".
Hướng dẫn từng bước
Bước 1 — Viết phát biểu vấn đề thật sắc. Đặt vào đầu cá một câu mô tả hệ quả cụ thể, đo được, không phán xét. "Team làm việc kém" là tệ. "Tỷ lệ story carry-over tăng từ 1 lên 4 trong 3 sprint" là tốt. Một problem statement mơ hồ sẽ tạo ra một sơ đồ vô dụng.
Bước 2 — Chọn các nhóm nguyên nhân. Bắt đầu với một khung gợi ý (6M, hoặc Con người – Quy trình – Công cụ – Đầu vào – Môi trường). Vẽ các xương lớn và đặt tên nhóm. Đừng quá cầu kỳ; 4–6 nhóm là vừa đủ.
Bước 3 — Brainstorm nguyên nhân trong từng nhóm. Dẫn dắt team đặt câu hỏi "Vì sao điều này xảy ra?" cho từng nhóm một. Mẹo facilitation: cho mọi người viết ý tưởng ra sticky note (vật lý hoặc trên Miro/Mural) trong im lặng 5 phút trước, rồi mới dán lên xương. Cách này tránh việc người nói to lấn át, và đảm bảo các thành viên trầm tính cũng đóng góp.
Bước 4 — Đào sâu các nhánh quan trọng. Với những nguyên nhân nổi bật, hỏi tiếp "Vì sao?" để tạo xương con — đây là nơi Five Whys lồng vào Fishbone. Đừng đào tất cả; chỉ đào nhánh nào team thấy đáng giá.
Bước 5 — Tìm điểm hội tụ và bỏ phiếu. Lùi lại nhìn toàn cảnh. Có nguyên nhân nào xuất hiện ở nhiều nhóm không? Có cụm nào đậm đặc bất thường không? Sau đó cho team dot-voting để chọn 2–3 nguyên nhân gốc đáng hành động nhất.
Bước 6 — Chuyển thành action. Mỗi nguyên nhân được chọn cần một action item cụ thể, có người chịu trách nhiệm và có cách kiểm chứng. Đây là cầu nối sang Bài 48 về Action Item Discipline — vẽ Fishbone đẹp mà không ra hành động thì chỉ là một bức tranh trang trí.
Lỗi thường gặp & mẹo
Nhầm triệu chứng với nguyên nhân. Nhiều team điền vào xương những thứ thực ra vẫn là hệ quả. "Bug nhiều" đặt làm nguyên nhân là sai — nó là triệu chứng. Hãy luôn hỏi "cái này còn do cái gì nữa?" cho đến khi chạm tới thứ có thể tác động được.
Problem statement quá rộng. "Sprint không thành công" sẽ tạo ra một sơ đồ khổng lồ và vô dụng. Thu hẹp lại thành một vấn đề cụ thể, đo được. Nếu vấn đề quá lớn, hãy chẻ nó thành nhiều Fishbone nhỏ.
Bị ám ảnh với 6M. Khung phân loại là công cụ gợi mở, không phải luật. Nếu nhóm "Materials" không hợp với team dịch vụ của bạn, hãy đổi tên hoặc bỏ. Đặt tên nhóm sao cho team thấy gần gũi sẽ ra nhiều ý tưởng hơn.
Brainstorm theo kiểu nói to. Người hướng ngoại sẽ chiếm sóng. Mẹo: dùng silent brainstorming với sticky note trước, để cân bằng tiếng nói. Đây cũng là cách kết nối Fishbone với các Liberating Structures bạn học ở đầu khóa.
Vẽ xong rồi để đó. Lỗi chí mạng nhất. Một Fishbone không dẫn tới action có thể đo lường thì chỉ tốn thời gian. Luôn kết thúc bằng dot-voting và action item rõ ràng.
Đào sâu mọi nhánh. Bạn không có thời gian, và cũng không cần. Chỉ đào sâu nhánh nào team thấy đáng giá nhất. Fishbone là để định hướng, không phải để liệt kê vô tận.
Mẹo timebox. Một buổi Fishbone hiệu quả thường gói trong 30–45 phút: 5 phút viết problem statement, 5 phút chọn nhóm, 15 phút brainstorm, 10 phút đào sâu và bỏ phiếu, 10 phút ra action. Đừng để nó trôi.
Bài tập thực hành
- Chọn một vấn đề thật của team bạn — một vấn đề lặp lại trong 2–3 sprint gần đây (ví dụ: story hay bị carry-over, demo hay trục trặc, daily kéo dài). Viết một problem statement cụ thể, đo được, không phán xét. Viết lại 3 lần cho đến khi bạn hài lòng.
- Vẽ Fishbone solo trong 20 phút trên giấy hoặc Miro. Tự chọn 4–6 nhóm nguyên nhân phù hợp với team bạn (không nhất thiết 6M). Điền ít nhất 2 nguyên nhân cho mỗi nhóm. Với 2 nhánh bạn thấy quan trọng nhất, hỏi "Vì sao?" thêm 2 lần để tạo xương con.
- Tìm điểm hội tụ. Nhìn lại sơ đồ và tự hỏi: có nguyên nhân nào xuất hiện ở nhiều nhóm không? Khoanh tròn 2–3 nguyên nhân gốc bạn cho là đáng hành động nhất, và viết cho mỗi cái một action item kèm cách kiểm chứng kết quả.
- (Nâng cao) Facilitate một buổi thật. Đưa Fishbone vào retrospective tiếp theo với cả team. Sau buổi, tự đánh giá: team có ra được action cụ thể không? Có ai trầm tính mà vẫn đóng góp được nhờ silent brainstorming không? Ghi lại một điều bạn sẽ làm khác lần sau.
Tóm tắt
Fishbone (Ishikawa) Diagram là công cụ phân tích nguyên nhân gốc theo chiều rộng: đặt vấn đề ở đầu cá, phân loại nguyên nhân thành các nhóm (6M hoặc khung tùy biến), rồi brainstorm có cấu trúc để không bỏ sót góc nào. Sức mạnh thật sự của nó không chỉ là liệt kê nguyên nhân, mà là giúp team nhìn thấy điểm hội tụ và các mâu thuẫn cấu trúc mà tranh luận thông thường bỏ lỡ — đồng thời chuyển một cuộc trò chuyện dễ quy kết cá nhân thành phân tích dựa trên hệ thống.
Hãy nhớ ba điều: problem statement phải sắc và đo được; khung phân loại chỉ là cái khung gợi mở, đừng cứng nhắc; và Fishbone phải kết thúc bằng dot-voting và action item cụ thể. Kết hợp Fishbone (chiều rộng) với Five Whys (chiều sâu) bạn sẽ có một bộ đôi mạnh mẽ để dẫn dắt team từ cảm giác bực bội đến hiểu rõ và hành động đúng chỗ. Đó chính là điều một Scrum Master giỏi mang lại trong mỗi buổi facilitation.