Mở đầu — vì sao bài này quan trọng
Trong số tất cả các Scrum event, Sprint Retrospective là sự kiện dễ bị làm hời hợt nhất — và cũng là sự kiện quyết định nhiều nhất đến việc một team có thật sự trưởng thành hay không. Một Scrum Master cấp PSM I thường nghĩ retro chỉ là buổi "What went well / What didn't / Action items" lặp đi lặp lại mỗi hai tuần. Nhưng chính cái sự lặp đi lặp lại máy móc đó là kẻ giết chết retro: team chán, đến cho có, nói qua loa, action item ghi rồi để đó.
Ở tầm PSM II, bạn không còn chỉ "chạy" retro nữa — bạn thiết kế retro. Bạn hiểu rằng mỗi buổi retro là một sản phẩm bạn phải thiết kế riêng cho bối cảnh, tâm trạng và vấn đề cụ thể của team tại Sprint đó. Bạn biết cách dẫn dắt năng lượng của cả nhóm đi qua một hành trình cảm xúc và tư duy có chủ đích, để cuối buổi mọi người rời đi với cam kết thật sự, chứ không phải một danh sách action vô hồn.
Bài này tập trung vào nghệ thuật thiết kế retro của một Senior Scrum Master: cách thay đổi format để chống "retro fatigue" (sự mệt mỏi nhàm chán), cách điều phối theo đường cong năng lượng (energy curve) năm pha, và cách biến action item thành thay đổi thật. Đây là kỹ năng phân biệt một SM "biết Scrum" với một SM thật sự tạo ra giá trị.
Khái niệm cốt lõi
Retro không phải một template — nó là một thiết kế
Sai lầm gốc rễ của hầu hết SM là coi retro như một biểu mẫu cố định. Thực ra retro là một buổi facilitation có cấu trúc, và mỗi buổi cần được thiết kế dựa trên ba câu hỏi: Team đang ở trạng thái nào? Vấn đề lớn nhất cần khai phá lần này là gì? Mình muốn cả nhóm rời đi với điều gì?
Cuốn sách kinh điển Agile Retrospectives của Esther Derby và Diana Larsen đã đưa ra một khung năm pha mà mọi Senior SM nên thuộc nằm lòng. Đây chính là energy curve — đường cong năng lượng của buổi retro.
Đường cong năng lượng — 5 pha
- Set the Stage (Mở màn) — Khoảng 5-10% thời gian. Mục tiêu: kéo mọi người vào phòng cả về thể chất lẫn tâm trí, tạo an toàn để nói thật. Một câu check-in đơn giản như "Một từ mô tả cảm xúc của bạn về Sprint vừa rồi" có sức mạnh lớn hơn bạn tưởng. Nếu bỏ qua pha này, người ta sẽ ngồi đó nhưng đầu óc còn ở task dở dang.
- Gather Data (Thu thập dữ liệu) — Khoảng 30-40%. Mục tiêu: cùng nhau dựng lại bức tranh khách quan về Sprint — cả sự kiện (facts) lẫn cảm xúc (feelings). Đây là pha lấy "nguyên liệu". Timeline, Mad-Sad-Glad, hay biểu đồ cảm xúc theo thời gian đều thuộc pha này.
- Generate Insights (Tạo hiểu biết) — Khoảng 20-30%. Mục tiêu: từ dữ liệu thô, đào sâu để hiểu vì sao. Đây là pha tư duy quan trọng nhất nhưng hay bị bỏ qua. Kỹ thuật 5 Whys, Fishbone, hay nhóm các pattern lại với nhau giúp team thấy được nguyên nhân hệ thống chứ không dừng ở triệu chứng.
- Decide What to Do (Quyết định hành động) — Khoảng 15-20%. Mục tiêu: chọn ra 1-2 cải tiến cụ thể, có chủ sở hữu, có thể đo lường. Ít mà chất. Một action được làm tới nơi tốt hơn năm action ghi cho có.
- Close the Retrospective (Kết thúc) — Khoảng 5-10%. Mục tiêu: chốt lại, cảm ơn, và đánh giá chính buổi retro (ROTI — Return On Time Invested). Pha này tạo cảm giác hoàn tất và khép vòng lặp.
Vì sao phải thay đổi format mỗi lần
"Retro fatigue" là hiện tượng team mất hứng vì buổi retro lúc nào cũng giống nhau. Bộ não ngừng chú ý với cái quen thuộc. Một Senior SM thay đổi format không phải để "cho vui", mà vì mỗi format khai mở một góc nhìn khác:
- Starfish (Keep / More / Less / Start / Stop) — tốt khi team cần tinh chỉnh hành vi đã có.
- Sailboat (gió đẩy / mỏ neo / đá ngầm / hòn đảo mục tiêu) — tốt khi cần nhìn về tương lai và rủi ro.
- Mad-Sad-Glad — tốt khi cảm xúc trong team đang cao, cần được giải tỏa.
- 4Ls (Liked / Learned / Lacked / Longed for) — tốt sau một Sprint nhiều biến động hoặc release lớn.
- Lean Coffee — tốt khi team đã trưởng thành, tự quản tốt và muốn tự dẫn dắt agenda.
Tình huống thực tế
Ví dụ 1 — Team "Tê Liệt Action Item" tại một công ty fintech ở TP.HCM
Tôi từng coach một team 7 người tại một startup ví điện tử ở Quận 1. Họ chạy retro đều đặn theo "What went well / What didn't" suốt 11 Sprint. Khi tôi xem lại, họ có 43 action item được ghi, nhưng chỉ 4 cái thực sự hoàn thành. Tệ hơn, mỗi Sprint cùng một vấn đề "build CI hay fail" được nêu lại mà không bao giờ được giải quyết.
Vấn đề ở đâu? Họ làm rất tốt pha Gather Data nhưng bỏ hoàn toàn pha Generate Insights. Họ nhảy thẳng từ "CI hay fail" sang "action: cần fix CI" — một action mơ hồ, không ai sở hữu.
Tôi đổi format sang Fishbone (biểu đồ xương cá) cho riêng vấn đề CI, và dành trọn 25 phút cho pha Generate Insights. Khi đào sâu, hóa ra nguyên nhân gốc không phải kỹ thuật mà là tổ chức: hai dev cùng push lớn vào cuối ngày thứ Sáu vì sợ "deadline tuần". Action cuối cùng cụ thể đến mức đo được: "Áp dụng quy tắc merge trước 4h chiều, anh Tuấn làm chủ, review lại sau 1 Sprint."
Bài học: Action item vô dụng không phải lỗi của team lười — đó là lỗi thiết kế khi SM bỏ qua pha đào root cause. Một action tốt phải có chủ sở hữu, có thời điểm kiểm tra, và xuất phát từ nguyên nhân gốc chứ không phải triệu chứng.
Ví dụ 2 — Đổi format để phá tan sự im lặng tại một công ty outsourcing ở Đà Nẵng
Một team 6 bạn dev tại công ty outsourcing ở Đà Nẵng có văn hóa rất "ngại nói". Trong retro kiểu thảo luận mở, sếp kỹ thuật vừa nói xong là cả team gật gù theo, không ai phản biện. Đây là vấn đề rất phổ biến trong bối cảnh Việt Nam, nơi tôn ti và sự nể nang ảnh hưởng mạnh đến việc nói thẳng.
Tôi chuyển sang format viết trước, nói sau (silent writing): mỗi người viết ý kiến lên sticky note (dùng công cụ Miro vì có một bạn remote) trong 5 phút im lặng tuyệt đối, sau đó tôi gom nhóm và đọc to một cách ẩn danh. Lần đầu tiên, vấn đề "estimate bị ép xuống cho vừa cam kết với khách" — điều chưa ai dám nói — xuất hiện trên bảng. Vì nó ẩn danh và được viết bởi nhiều người, nó trở thành vấn đề của cả nhóm chứ không phải lời tố cáo của một cá nhân.
Bài học: Format không trung lập. Thảo luận miệng ưu tiên người nói to và có quyền lực. Khi an toàn tâm lý còn thấp, hãy chọn format giảm thiểu áp lực xã hội — viết trước, ẩn danh, hoặc bỏ phiếu im lặng (dot voting). Thiết kế retro chính là thiết kế điều kiện để sự thật được nói ra.
Ví dụ 3 — ROTI cứu một team Scrum đang chán retro tại một ngân hàng ở Hà Nội
Một team tại bộ phận chuyển đổi số của một ngân hàng ở Hà Nội nói thẳng với tôi: "Anh ơi, retro chán lắm, cho bọn em bỏ được không?" Đó là một tín hiệu sống còn. Thay vì tranh luận, tôi áp dụng ngay ROTI (Return On Time Invested) ở cuối mỗi buổi: mọi người giơ tay từ 1 đến 5 điểm đánh giá buổi retro vừa rồi có đáng thời gian không, và ai cho điểm thấp được hỏi "cần gì để nó thành 4 điểm?".
Trong ba Sprint, điểm trung bình tăng từ 2.1 lên 4.0. Vì sao? Vì chính team đã định hình lại retro của họ. Họ đề nghị rút retro xuống 45 phút, tập trung mỗi lần một chủ đề duy nhất, và luân phiên người dẫn. Retro của họ "sống lại" không phải vì tôi giỏi, mà vì tôi để chính họ thiết kế nó qua vòng phản hồi ROTI.
Bài học: Bản thân retro cũng cần được retro. ROTI biến team từ người tiêu thụ thụ động thành người đồng thiết kế. Một team self-managing sẽ tự chữa lành retro của chính mình nếu bạn cho họ công cụ phản hồi.
Hướng dẫn từng bước
Đây là quy trình thiết kế một buổi retro chất lượng cao mà tôi dùng:
- Chẩn đoán trước buổi. Trước retro 1-2 ngày, tự hỏi: Sprint này có sự kiện đặc biệt nào (release lớn, sự cố, mâu thuẫn)? Tâm trạng team đang thế nào? Vấn đề nào lặp lại chưa giải quyết? Câu trả lời định hình mục tiêu của buổi.
- Chọn một mục tiêu duy nhất cho buổi. Đừng tham. Mỗi retro nên có một câu hỏi trung tâm, ví dụ: "Vì sao chúng ta liên tục không đạt Sprint Goal?" Mục tiêu rõ thì mới chọn được format đúng.
- Thiết kế theo 5 pha và phân bổ thời gian. Vẽ ra timeline: bao nhiêu phút cho Set the Stage, Gather, Generate, Decide, Close. Đảm bảo pha Generate Insights được dành đủ thời gian — đây là pha hay bị cắt nhất.
- Chọn format phù hợp mục tiêu, không lặp lại quá 3 lần. Khớp format với mục tiêu (xem phần khái niệm). Nếu an toàn tâm lý thấp, ưu tiên format viết/ẩn danh.
- Chuẩn bị vật liệu và không gian. Sticky note, bảng Miro, timer. Với team distributed, chuẩn bị template online từ trước, đừng dựng giữa buổi.
- Điều phối — giữ năng lượng đi đúng đường cong. Đẩy năng lượng lên ở Gather, đào sâu ở Generate, hội tụ lại ở Decide. Dùng timebox cứng cho mỗi pha.
- Chốt action SMART, có chủ sở hữu. Tối đa 1-2 action. Mỗi action phải có người chịu trách nhiệm và thời điểm kiểm tra. Đưa vào Sprint Backlog tiếp theo như một item thật.
- Đóng buổi bằng ROTI. Đo lại chất lượng buổi, hỏi cách cải thiện. Đây là dữ liệu để thiết kế retro lần sau.
- Theo dõi action giữa Sprint. Việc tệ nhất là để action chết. Nhắc lại trong Daily Scrum hoặc dán lên bảng nơi ai cũng thấy.
Lỗi thường gặp & mẹo
- Lỗi: Bỏ qua pha Generate Insights. Đây là lỗi phổ biến nhất — nhảy thẳng từ dữ liệu sang action mà không hiểu nguyên nhân. Mẹo: ép mình hỏi "vì sao?" ít nhất ba lần trước khi cho phép team đề xuất giải pháp.
- Lỗi: Quá nhiều action item. Ghi 8 action mỗi Sprint nghe có vẻ hiệu quả nhưng thực ra là dấu hiệu thất bại. Mẹo: giới hạn cứng 1-2 action, làm tới nơi.
- Lỗi: SM nói nhiều hơn team. Retro là của team, không phải sân khấu của SM. Mẹo: tự đặt mục tiêu nói dưới 20% thời gian; phần còn lại là đặt câu hỏi và giữ im lặng.
- Lỗi: Lúc nào cũng một format. Dẫn đến retro fatigue. Mẹo: chuẩn bị sẵn một "thư viện" 5-6 format và xoay vòng theo mục tiêu.
- Lỗi: Không có an toàn tâm lý nhưng vẫn dùng thảo luận mở. Người ta sẽ im hoặc nói dối. Mẹo: với team mới hoặc team ngại nói, dùng format viết im lặng và dot voting.
- Lỗi: Action không bao giờ được theo dõi. Team mất niềm tin vào retro. Mẹo: làm action retro hiển thị (visible) ngay trên board và review ở đầu buổi retro kế tiếp.
- Mẹo cao cấp: Thỉnh thoảng làm "retro về retro" — dành nguyên một buổi để team tự thiết kế lại cách họ retro. Đây là biểu hiện cao nhất của self-management.
Bài tập thực hành
- Thiết kế một retro hoàn chỉnh. Chọn một team thật bạn đang làm việc (hoặc tưởng tượng). Viết ra: mục tiêu duy nhất của buổi, format bạn chọn và lý do, phân bổ thời gian cho 5 pha. Tổng thời gian 75 phút.
- Tự kiểm kê action item. Lấy 5 buổi retro gần nhất của team bạn. Đếm số action được ghi và số action thực sự hoàn thành. Tính tỉ lệ. Nếu dưới 50%, viết ra một giả thuyết vì sao và một thay đổi bạn sẽ thử.
- Xây thư viện format. Liệt kê 6 format retro khác nhau. Với mỗi format, ghi một dòng: tình huống nào thì dùng nó. Đây sẽ là bộ công cụ đi làm của bạn.
- Thực hành ROTI. Trong buổi retro tiếp theo, áp dụng ROTI ở cuối buổi. Ghi lại điểm số và ít nhất một đề xuất cải tiến mà team đưa ra. Sprint sau đo lại xem điểm có tăng không.
- Phá im lặng. Nếu team bạn có người trầm, thử một buổi retro hoàn toàn dùng silent writing + dot voting. Quan sát: có ý kiến nào xuất hiện mà bình thường không ai nói ra không?
Tóm tắt
Retrospective Mastery ở tầm PSM II không phải là biết thêm vài format lạ — mà là tư duy của một nhà thiết kế. Bạn coi mỗi buổi retro như một sản phẩm cần thiết kế riêng cho bối cảnh team tại Sprint đó. Bạn nắm vững đường cong năng lượng năm pha (Set the Stage, Gather Data, Generate Insights, Decide What to Do, Close) và phân bổ thời gian có chủ đích, đặc biệt không cắt xén pha Generate Insights — nơi root cause được tìm ra. Bạn thay đổi format để chống retro fatigue và để khai mở những góc nhìn khác nhau. Bạn chọn format dựa trên mức độ an toàn tâm lý của team, ưu tiên viết im lặng và ẩn danh khi sự thật khó nói ra. Bạn chốt 1-2 action thật sự — có chủ sở hữu, đo được, được theo dõi — thay vì một danh sách dài vô hồn. Và bạn dùng ROTI để chính team đồng thiết kế lại retro của họ, vì retro tốt nhất là retro mà team tự sở hữu. Khi bạn làm được những điều này, retro không còn là một nghi thức bắt buộc mỗi hai tuần, mà trở thành động cơ thật sự đưa team đi từ tốt đến xuất sắc.