Mở đầu — vì sao bài này quan trọng
Trong toàn bộ "hộp đồ nghề" của một Scrum Master, có những công cụ thiên về dữ liệu, có những công cụ thiên về quy trình. Nhưng Mad / Sad / Glad lại thuộc về một nhóm rất đặc biệt: nhóm công cụ chạm vào cảm xúc của đội nhóm. Và đây chính là lý do nó quan trọng đến vậy.
Bạn hãy nhớ lại một sự thật mà nhiều Scrum Master Việt Nam thường bỏ qua: con người không ra quyết định và không làm việc thuần lý trí. Một lập trình viên ngồi lặng lẽ suốt Sprint không hẳn vì "không có ý kiến", mà có thể vì anh ấy đang bực bội với việc bị ngắt quãng liên tục, hoặc đang thất vọng vì một tính năng tâm huyết bị cắt bỏ. Nếu retrospective của bạn chỉ hỏi "Cái gì tốt? Cái gì cần cải thiện?", bạn sẽ thu được những câu trả lời an toàn, chung chung, và bỏ lỡ hoàn toàn lớp cảm xúc đang âm ỉ bên dưới.
Mad / Sad / Glad ra đời để giải quyết đúng vấn đề đó. Nó là một định dạng retrospective được Esther Derby và Diana Larsen phổ biến qua cuốn Agile Retrospectives, dùng ba cảm xúc cơ bản làm "ống kính" để team nhìn lại Sprint. Thay vì hỏi về sự kiện một cách trung tính, nó mời mọi người nói thẳng: Điều gì khiến tôi tức giận? Điều gì khiến tôi buồn? Điều gì khiến tôi vui?
Sức mạnh của việc đặt cảm xúc vào trung tâm là: cảm xúc luôn là tín hiệu dẫn đến một vấn đề hoặc một giá trị có thật. Người ta không tự nhiên "Mad" — sự bực bội luôn có nguyên nhân hệ thống đằng sau. Khi bạn để team gọi tên cảm xúc, bạn đang mở một cánh cửa để đi tới gốc rễ mà những định dạng "khô" hơn khó với tới được. Bài học này sẽ giúp bạn nắm vững định dạng đó, biết khi nào nên dùng và quan trọng nhất là cách facilitate nó một cách an toàn trong văn hóa làm việc Việt Nam — nơi việc bộc lộ cảm xúc tiêu cực trước tập thể vẫn còn nhiều e dè.
Khái niệm cốt lõi
Ba cảm xúc, ba ống kính
Mad / Sad / Glad chia trải nghiệm của Sprint thành ba cột tương ứng với ba trạng thái cảm xúc:
- Mad (Tức giận / Bực bội) — những điều gây khó chịu, ức chế, làm bạn mất kiên nhẫn. Đây thường là các trở ngại lặp đi lặp lại: build hỏng liên tục, bị họp xen ngang, yêu cầu thay đổi giữa Sprint, công cụ chậm chạp. "Mad" báo hiệu friction — ma sát trong cách team vận hành.
- Sad (Buồn / Thất vọng) — những điều khiến bạn tiếc nuối, hụt hẫng, kỳ vọng mà không đạt được. Ví dụ: một tính năng tâm huyết bị hoãn, một đồng nghiệp rời nhóm, không kịp hoàn thành mục tiêu Sprint dù đã cố gắng. "Sad" báo hiệu khoảng cách giữa kỳ vọng và thực tế, và thường gắn với những giá trị mà team thực sự quan tâm.
- Glad (Vui / Tự hào) — những điều mang lại niềm vui, sự hài lòng, cảm giác thành tựu. Một lần pair-programming hiệu quả, một lời cảm ơn từ khách hàng, một bug khó cuối cùng cũng bị tiêu diệt. "Glad" báo hiệu điều đáng được giữ gìn và nhân rộng.
Vì sao tách Mad và Sad?
Nhiều người mới sẽ hỏi: "Tức giận và buồn đều là cảm xúc tiêu cực, sao không gộp làm một?". Đây chính là chỗ Mad / Sad / Glad thông minh hơn các định cách như Plus/Delta hay Glad/Sad/Mad gộp.
Mad thường hướng ra ngoài — nó chỉ về một quy trình, một công cụ, một sự cản trở mà ta muốn loại bỏ. Sad thường hướng vào trong — nó chỉ về một mất mát, một kỳ vọng không thành mà ta cần thấu hiểu và chấp nhận hoặc tìm cách bù đắp. Hai loại này dẫn đến hai loại hành động khác nhau: "Mad" thường sinh ra action items để sửa quy trình, còn "Sad" thường mở ra cuộc đối thoại sâu về mục tiêu, kỳ vọng và sự hỗ trợ lẫn nhau. Tách chúng ra giúp team không "cào bằng" mọi vấn đề tiêu cực thành một đống, mà phân loại được bản chất.
Vị trí trong bộ công cụ retrospective
Trong dàn bài khóa học này, bạn đã hoặc sẽ gặp nhiều định dạng retro khác: Sailboat (bài 9), Starfish (bài 10), 4Ls (bài 12), Plus/Delta (bài 14). Vậy Mad / Sad / Glad khác biệt ở đâu? Nó là định dạng tập trung mạnh nhất vào cảm xúc và sức khỏe tinh thần của team. Nếu Sailboat thiên về ẩn dụ chiến lược (gió, mỏ neo, tảng đá), Plus/Delta thiên về sự đơn giản, thì Mad / Sad / Glad là lựa chọn số một khi bạn cảm nhận team đang có căng thẳng ngầm, tinh thần đi xuống, hoặc vừa trải qua một Sprint nhiều biến động. Đây là "nhiệt kế cảm xúc" của bạn.
Tình huống thực tế
Tình huống 1 — Đội fintech ở TP.HCM và những cơn "Mad" lặp lại
Một startup fintech tại Quận 1, TP.HCM (tạm gọi là PayNow, khoảng 8 người trong team phát triển) vừa kết thúc Sprint thứ 6 của một sản phẩm ví điện tử. Velocity tụt từ 34 điểm xuống còn 19 điểm, nhưng trong các retro trước theo kiểu "tốt / cần cải thiện", không ai chỉ ra được nguyên nhân — câu trả lời toàn là "cần estimate tốt hơn".
Scrum Master Linh quyết định đổi sang Mad / Sad / Glad. Khi mở cột Mad, có tới 5 trên 8 sticky note nhắc đến cùng một chủ đề: bị CEO nhắn tin trực tiếp giữa Sprint yêu cầu "làm gấp tính năng này cho nhà đầu tư xem". Một dev viết thẳng: "Mad vì mỗi tuần bị đổi ưu tiên 2-3 lần, code dở dang phải bỏ."
Điều thú vị là ở cột Glad, lại có note: "Glad vì cuối cùng cũng demo được cho nhà đầu tư và họ rất thích." Cùng một nguồn gốc — áp lực từ nhà đầu tư — vừa tạo ra "Mad" (cách thực thi gây gián đoạn) vừa tạo ra "Glad" (kết quả tích cực).
Bài học rút ra: Cảm xúc "Mad" tập trung dày đặc vào một điểm đã giúp Linh nhìn ra vấn đề hệ thống mà các retro trước bỏ lỡ: không phải team estimate kém, mà là Sprint liên tục bị phá vỡ bởi yêu cầu ngoài luồng. Action item không phải "estimate tốt hơn" mà là "thống nhất với CEO một kênh duy nhất để đưa yêu cầu khẩn, xử lý ở Sprint Planning kế tiếp trừ khi thực sự là sự cố sản xuất." Velocity Sprint sau đó hồi phục lên 28 điểm.
Tình huống 2 — Đội outsourcing ở Đà Nẵng và cột "Sad" bị bỏ trống
Một công ty gia công phần mềm ở Đà Nẵng (TechBridge, team 6 người làm cho khách Nhật) áp dụng Mad / Sad / Glad. Scrum Master Đức nhận thấy một hiện tượng lạ: cột Mad và Glad đầy ắp note, nhưng cột Sad gần như trống — chỉ có một note mờ nhạt "Sad vì hơi mệt".
Ban đầu Đức tưởng đó là dấu hiệu tốt — "team không buồn gì cả mà". Nhưng linh cảm của một SM giỏi mách bảo anh điều ngược lại. Trong văn hóa làm việc Việt Nam, đặc biệt với khách hàng nước ngoài, việc thừa nhận "buồn / thất vọng" trước tập thể dễ bị xem là yếu đuối hoặc thiếu chuyên nghiệp. Cột Sad trống không có nghĩa là không có nỗi buồn, mà có nghĩa là chưa đủ an toàn để nói ra.
Đức thử một cách: anh chia sẻ trước nỗi "Sad" của chính mình — "Mình thấy hơi buồn vì hai bạn mới vào nhóm mà mình chưa dành đủ thời gian onboard, làm các bạn phải tự mò." Khi người facilitator dám tổn thương trước, không khí thay đổi. Lần lượt vài note xuất hiện: "Sad vì cảm thấy đóng góp của mình không được khách ghi nhận", "Sad vì làm overtime nhưng kết quả vẫn bị chê."
Bài học rút ra: Cột Sad trống là một tín hiệu cảnh báo, không phải dấu hiệu tốt. Trong bối cảnh Việt Nam, Scrum Master cần chủ động tạo "safety" bằng cách làm gương (vulnerability-first), thậm chí dùng phiếu ẩn danh ở những lần đầu để team quen dần với việc bộc lộ.
Tình huống 3 — Team phân tán và Mad / Sad / Glad trên công cụ online
Một sản phẩm SaaS của công ty có đội ngũ trải khắp Hà Nội, TP.HCM và một bạn ở Singapore. Họ chạy Mad / Sad / Glad trên Miro, mỗi người dán note ẩn danh trong 5 phút đầu trước khi bật webcam thảo luận.
Ở cột Glad, nhiều note khen ngợi việc nhóm bắt đầu dùng async standup qua văn bản. Nhưng cột Mad có một note đáng chú ý: "Mad vì retro toàn diễn ra lúc 4h chiều giờ VN, là 5h chiều giờ SG — bạn ở SG luôn phải họp sát giờ tan làm." Đây là điều mà ba bạn ở Việt Nam hoàn toàn không nhận ra vì với họ giờ đó rất bình thường.
Bài học rút ra: Mad / Sad / Glad đặc biệt hữu ích với team phân tán vì cảm xúc của những người ở "thiểu số múi giờ" hay bị bỏ quên. Định dạng ẩn danh ban đầu trên công cụ số giúp những tiếng nói nhỏ được nghe thấy. (Chi tiết về retro bất đồng bộ cho team phân tán sẽ được đào sâu ở Bài 41; ở đây ta chỉ lưu ý cách Mad / Sad / Glad thích nghi với online.)
Hướng dẫn từng bước
Một phiên Mad / Sad / Glad điển hình kéo dài 30–45 phút cho team 5–9 người. Dưới đây là quy trình năm bước theo khung của Esther Derby và Diana Larsen.
Bước 1 — Set the Stage (Mở màn, 3–5 phút). Đừng bao giờ nhảy thẳng vào việc dán note. Hãy mở đầu bằng một câu nhắc về sự an toàn: "Đây là không gian không phán xét, chúng ta nói về sự việc và cảm xúc, không đổ lỗi cá nhân." Bạn có thể nhắc Retrospective Prime Directive của Norm Kerth: "Dù khám phá ra điều gì, chúng ta đều tin rằng mọi người đã làm tốt nhất có thể với những gì họ biết lúc đó." Trong bối cảnh Việt Nam, câu này cực kỳ quan trọng để gỡ bỏ tâm lý sợ bị "vạch lá tìm sâu".
Bước 2 — Vẽ bảng và giải thích (2 phút). Chia bảng (vật lý hoặc Miro/Mural) thành ba cột: Mad, Sad, Glad. Giải thích ngắn gọn ý nghĩa từng cột bằng tiếng Việt: Bực bội — Thất vọng — Vui mừng. Nhấn mạnh rằng không có cảm xúc nào "sai".
Bước 3 — Gather Data (Thu thập dữ liệu cá nhân, 7–10 phút). Mỗi người viết note trong im lặng, một ý mỗi note. Đây là "silent brainstorming" — quan trọng để tránh hiệu ứng người nói đầu tiên định hướng cả nhóm. Khuyến khích viết cụ thể: thay vì "Mad vì họp nhiều", hãy viết "Mad vì có 3 cuộc họp không liên quan đến team trong tuần này". Sau đó mỗi người lần lượt dán note lên cột tương ứng và đọc to một câu.
Bước 4 — Generate Insights (Nhóm và phân tích, 10–15 phút). Cùng nhau gom các note tương đồng thành cụm (clustering). Đặt câu hỏi đào sâu: "Cụm Mad này lặp lại nhiều — điều gì đứng sau nó?", "Cột Sad này nói lên kỳ vọng gì của chúng ta?". Có thể dùng dot-voting để chọn 1–2 chủ đề ưu tiên thảo luận sâu. Đây là lúc kết nối cảm xúc với nguyên nhân hệ thống.
Bước 5 — Decide What to Do (Quyết định hành động, 5–10 phút) và Close (Kết thúc, 2 phút). Với mỗi chủ đề ưu tiên, thống nhất 1 action item cụ thể: ai làm, làm gì, khi nào kiểm tra. Đừng tham lam — một retro 30 phút chỉ nên ra 1–2 action item thật sự khả thi. Kết thúc bằng một vòng nhanh: "Một từ mô tả cảm giác của bạn sau buổi này." (Kỷ luật theo dõi action item sẽ được bàn kỹ ở Bài 48.)
Lỗi thường gặp & mẹo
Lỗi 1 — Biến cột Glad thành nơi "xã giao". Nhiều team viết Glad rất hời hợt kiểu "Glad vì team đoàn kết". Note Glad mơ hồ thì vô dụng. Mẹo: yêu cầu mỗi note Glad phải gắn với một sự kiện cụ thể có thể lặp lại được, vì Glad chính là thứ bạn muốn nhân rộng.
Lỗi 2 — Dừng ở cảm xúc, không đi tới hành động. Mad / Sad / Glad rất dễ trở thành buổi "xả stress" rồi ai về nhà nấy. Cảm xúc được nói ra mà không dẫn tới thay đổi nào sẽ khiến team mất niềm tin vào retro. Luôn dành đủ thời gian cho bước 5.
Lỗi 3 — Để cột Mad biến thành đổ lỗi cá nhân. "Mad vì anh A toàn merge code lỗi" là note độc hại. Mẹo: reframe ngay tại chỗ thành vấn đề hệ thống — "Vậy có phải ta đang thiếu code review hoặc CI checks?". Hướng năng lượng vào quy trình, không vào con người.
Lỗi 4 — Bỏ qua cột Sad trống (như tình huống TechBridge). Đừng mừng vội. Hãy coi đó là tín hiệu thiếu an toàn tâm lý và xử lý bằng vulnerability-first hoặc ẩn danh.
Lỗi 5 — Dùng đi dùng lại mãi một định dạng. Mad / Sad / Glad mạnh ở cảm xúc nhưng nếu chạy 6 Sprint liên tục, team sẽ chán và viết cho có. Mẹo: luân phiên với các định dạng khác (Sailboat, Starfish, 4Ls) và chỉ rút Mad / Sad / Glad ra khi bạn cảm nhận team đang có căng thẳng cảm xúc cần được giải tỏa.
Mẹo về văn hóa Việt Nam: Ở những lần đầu áp dụng, hãy cho phép viết note ẩn danh (giấy không ghi tên hoặc công cụ số). Văn hóa "giữ hòa khí" và ngại làm mất lòng khiến nhiều người Việt khó bộc lộ Mad/Sad công khai. Khi team đã đủ tin tưởng sau vài Sprint, bạn có thể chuyển dần sang công khai để tăng chiều sâu đối thoại.
Bài tập thực hành
- Tự chạy một "mini Mad / Sad / Glad" cho bản thân. Nhìn lại tuần làm việc vừa qua, viết ra 2 note Mad, 2 note Sad, 2 note Glad của riêng bạn. Với mỗi note Mad, hãy hỏi: nguyên nhân hệ thống đằng sau là gì? Bài tập này giúp bạn cảm nhận trước trải nghiệm mà team sẽ trải qua.
- Soạn kịch bản facilitate 30 phút. Viết ra timeline chi tiết cho một phiên Mad / Sad / Glad với team 7 người: phân bổ thời gian từng bước, câu mở màn (set the stage) bằng tiếng Việt, và 3 câu hỏi đào sâu bạn sẽ dùng ở bước Generate Insights.
- Tình huống xử lý. Giả sử trong phiên retro, một thành viên dán note "Mad vì sếp luôn thiên vị nhóm khác". Bạn sẽ reframe và facilitate cuộc thảo luận này thế nào để vừa tôn trọng cảm xúc của bạn ấy, vừa không biến retro thành buổi công kích lãnh đạo? Viết ra 3–4 câu bạn sẽ nói.
- So sánh công cụ. Liệt kê 3 dấu hiệu cụ thể của một team cho thấy bạn nên chọn Mad / Sad / Glad thay vì Plus/Delta hay Starfish cho Sprint Retrospective sắp tới.
Tóm tắt
Mad / Sad / Glad là định dạng retrospective lấy cảm xúc làm lăng kính: Mad (bực bội — báo hiệu friction trong quy trình), Sad (thất vọng — báo hiệu khoảng cách kỳ vọng và mất mát), Glad (vui mừng — báo hiệu điều đáng nhân rộng). Sức mạnh của nó nằm ở chỗ cảm xúc luôn là tín hiệu dẫn tới nguyên nhân hệ thống có thật, điều mà các định dạng "khô" hơn dễ bỏ lỡ.
Quy trình năm bước — Set the Stage, Gather Data, Generate Insights, Decide What to Do, Close — gói gọn trong 30–45 phút và nên kết thúc bằng 1–2 action item cụ thể. Hãy nhớ ba điều cốt lõi cho Scrum Master Việt Nam: (1) tạo an toàn tâm lý trước, thậm chí dùng ẩn danh ở giai đoạn đầu; (2) coi cột Sad trống là tín hiệu cảnh báo chứ không phải tin vui; (3) luôn reframe Mad từ đổ lỗi cá nhân thành vấn đề hệ thống, và luôn biến cảm xúc thành hành động. Dùng đúng lúc — khi team có căng thẳng ngầm hoặc tinh thần đi xuống — Mad / Sad / Glad sẽ là chiếc nhiệt kế cảm xúc đắt giá nhất trong hộp đồ nghề của bạn.