Mở đầu — vì sao bài này quan trọng
Bạn đã từng dự một buổi Retrospective mà ngay từ phút đầu tiên, không khí đã uể oải chưa? Mọi người ngồi xuống, Scrum Master hỏi câu quen thuộc "Điều gì tốt? Điều gì chưa tốt? Chúng ta cần cải thiện gì?", rồi cả nhóm im lặng nhìn nhau. Có người lôi điện thoại ra trả lời tin nhắn. Có người lặp lại đúng ý kiến của Sprint trước. Buổi họp kết thúc với vài action item nửa vời mà ai cũng biết sẽ chẳng được thực hiện.
Đó là căn bệnh phổ biến nhất của Retrospective: sự nhàm chán do lặp lại. Khi bạn dùng đúng một format, đúng một bộ câu hỏi, Sprint này qua Sprint khác, não bộ của cả nhóm sẽ chuyển sang chế độ "tự lái". Họ trả lời theo quán tính, không còn suy nghĩ sâu. Năng lượng cạn dần, và giá trị thật sự của Retrospective — không gian an toàn để cải tiến liên tục — bị bào mòn.
Đây chính là lý do Sprint Retrospective Themes (Retrospective theo chủ đề) ra đời. Thay vì hỏi chung chung về toàn bộ Sprint, bạn chọn một chủ đề cụ thể — chất lượng code, sự cộng tác, niềm tin trong nhóm, dòng chảy công việc — và xoáy sâu vào đó. Một buổi Retrospective theo chủ đề vừa mang lại sự mới mẻ, vừa cho phép nhóm đào sâu hơn nhiều so với cách hỏi dàn trải.
Trong bài này, tôi sẽ giảng cho bạn vì sao chủ đề lại tạo ra khác biệt lớn, một thư viện các theme thực dụng để bạn áp dụng ngay, cách chọn theme phù hợp với tình hình nhóm, và cách dẫn dắt một buổi Retro theo chủ đề từ đầu đến cuối. Lưu ý: bài này tập trung vào việc chọn và thiết kế CHỦ ĐỀ cho Retro — còn các format kỹ thuật cụ thể như Sailboat, Starfish, Mad/Sad/Glad hay 4Ls đã có bài riêng. Ở đây, theme là "câu hỏi trọng tâm", còn format chỉ là cái khuôn để chứa nó.
Khái niệm cốt lõi
Theme là gì và khác gì với Format?
Hãy phân biệt rõ hai khái niệm dễ nhầm lẫn:
- Format là cấu trúc hoạt động — cách bạn tổ chức việc thu thập và xử lý ý kiến. Ví dụ: Sailboat (thuyền buồm với gió, mỏ neo), Starfish (giữ nguyên, làm nhiều hơn, làm ít hơn...), Plus/Delta (giữ/đổi).
- Theme là chủ đề trọng tâm — lăng kính mà qua đó cả nhóm nhìn lại Sprint. Ví dụ: "Sprint này, chúng ta chỉ nói về chất lượng" hoặc "Hôm nay chúng ta chỉ bàn về cách giao tiếp với nhau".
Vì sao thu hẹp lại giúp đào sâu hơn?
Đây là nghịch lý quan trọng nhất của bài học: khi bạn hỏi ít hơn, bạn thường nhận được nhiều hơn.
Câu hỏi "Sprint này thế nào?" quá rộng. Não bộ con người, khi đối mặt với câu hỏi mở rộng, có xu hướng chọn câu trả lời an toàn, dễ nói, nằm trên bề mặt. Nhưng khi bạn hỏi "Lần này, điều gì về chất lượng code đã khiến bạn ngạc nhiên?", bạn đã khóa sự chú ý vào một điểm và mời gọi một loại phản hồi sâu hơn, cảm xúc hơn, cụ thể hơn.
Thu hẹp phạm vi còn giúp action item trở nên tập trung. Một Retro dàn trải thường sinh ra 7-8 action item rải rác khắp nơi, không cái nào được làm tới nơi. Một Retro theo chủ đề thường sinh ra 2-3 action item cùng hướng về một mục tiêu — dễ theo dõi, dễ hoàn thành.
Thư viện các theme thực dụng
Dưới đây là những theme tôi thường dùng nhất. Bạn không cần thuộc lòng — hãy xem đây như một thực đơn để chọn món phù hợp với "khẩu vị" của nhóm trong từng Sprint.
1. Theme Chất lượng (Quality) Phù hợp khi nhóm vừa trải qua một Sprint nhiều bug, nhiều hotfix, hoặc khi nợ kỹ thuật đang chồng chất. Câu hỏi mẫu:
- "Điều gì về chất lượng sản phẩm/code lần này khiến bạn ngạc nhiên — theo cả hướng tốt lẫn xấu?"
- "Nếu khách hàng nhìn vào công việc của chúng ta tuần này, họ sẽ tự hào về điều gì và xấu hổ về điều gì?"
- "Một việc nhỏ nào chúng ta có thể làm ngay để Sprint sau ít bug hơn?"
- "Khi nào trong Sprint này bạn cảm thấy thật sự được nhóm hỗ trợ?"
- "Lần gần nhất bạn ngại hỏi hoặc ngại nói ra ý kiến là khi nào?"
- "Thông tin nào bạn ước mình biết sớm hơn?"
- "Trong Sprint vừa rồi, bạn có khoảnh khắc nào ngần ngại nói thật không?"
- "Điều gì giúp bạn cảm thấy an toàn để mắc lỗi ở nhóm này?"
- "Công việc của chúng ta bị 'đứng' lâu nhất ở đâu trong Sprint này?"
- "Điều gì khiến một task mất nhiều thời gian hơn dự kiến?"
- "Việc nào tuần này thực sự tạo ra giá trị cho người dùng, và việc nào chỉ là 'bận rộn'?"
- "Điều gì tuần này khiến bạn cạn năng lượng nhất? Điều gì nạp năng lượng cho bạn?"
Theme nên đến từ đâu?
Một sai lầm là Scrum Master tự nghĩ ra theme mỗi tuần như một trò vui. Theme tốt nhất đến từ dữ liệu và quan sát:
- Từ metrics (số bug tăng → theme Chất lượng; lead time dài → theme Flow).
- Từ những gì bạn nghe lỏm trong Daily Scrum (có người liên tục bị block → theme Flow).
- Từ chính nhóm — bạn có thể hỏi cuối Sprint trước: "Lần sau anh em muốn đào sâu chủ đề gì?"
Tình huống thực tế
Ví dụ 1: Tiki và chuỗi Sprint nhàm chán
Một nhóm phát triển 9 người tại một công ty thương mại điện tử lớn ở TP.HCM (gọi là nhóm Checkout) đã chạy Scrum được hơn một năm. Scrum Master tên Hằng nhận thấy điểm tham gia Retrospective tụt dốc rõ rệt: từ chỗ trung bình mỗi buổi có khoảng 25-30 ý kiến dán sticky note, ba Sprint gần nhất chỉ còn 8-10 ý kiến, và phần lớn là lặp lại ("cần estimate tốt hơn", "họp nhiều quá").
Hằng dùng đúng một format Mad/Sad/Glad suốt 18 Sprint liên tiếp. Cô quyết định đổi cách tiếp cận. Thay vì lại hỏi chung chung, cô nhìn vào dữ liệu: Sprint vừa rồi nhóm để lọt 4 bug nghiêm trọng lên production, gấp đôi bình thường. Cô chọn theme Chất lượng và mở đầu bằng câu: "Hôm nay chúng ta sẽ không nói về mọi thứ. Chúng ta chỉ nói về một câu: Điều gì về chất lượng tuần này khiến bạn ngạc nhiên?"
Kết quả rất khác. Vì câu hỏi cụ thể và chạm vào nỗi đau thực, mọi người có chuyện để kể. Một dev tiết lộ rằng anh đã bỏ qua viết unit test cho phần thanh toán vì "thấy nó đơn giản" — và đó chính là nơi 2 trong 4 bug xảy ra. Một QA chia sẻ cô nhận task quá muộn, chỉ còn nửa ngày để test. Buổi Retro sinh ra đúng 2 action item: thêm checklist "có test cho luồng tiền chưa?" vào Definition of Done, và QA tham gia refinement sớm hơn. Sprint sau, số bug production về 1.
Bài học: Theme không phải để cho vui — nó hiệu quả nhất khi xuất phát từ một vấn đề thật mà dữ liệu đã chỉ ra. Sự cụ thể của câu hỏi mở khóa những câu trả lời mà câu hỏi chung chung không bao giờ chạm tới.
Ví dụ 2: Một startup fintech và theme Niềm tin dùng sai lúc
Một startup fintech khoảng 30 người ở Hà Nội có một nhóm vừa trải qua biến động: hai thành viên kỳ cựu nghỉ việc, ba người mới gia nhập trong vòng một tháng. Scrum Master tên Phong, sau khi đọc một bài viết về an toàn tâm lý, hào hứng chọn ngay theme Niềm tin cho buổi Retro đầu tiên với đội hình mới. Anh mở màn bằng câu hỏi khá nặng: "Lần gần nhất bạn cảm thấy không thể tin tưởng đồng nghiệp là khi nào?"
Buổi họp rơi vào im lặng đến khó xử. Ba người mới chưa quen ai, không có gì để chia sẻ và cũng không cảm thấy đủ an toàn để nói thật. Những người cũ thì dè dặt vì sợ câu trả lời bị hiểu lầm. Phong rời buổi họp với cảm giác thất bại, và tệ hơn, vài thành viên thấy ngại tham gia Retro tiếp theo.
Phong nhận ra mình đã chọn đúng theme nhưng sai thời điểm. Với một nhóm chưa có nền tảng tin tưởng, theme Niềm tin là quá sớm — nó đòi hỏi cái mà nhóm chưa có. Sprint sau, anh quay lại với một theme nhẹ nhàng và xây dựng hơn: theme Cộng tác, với câu hỏi "Khi nào tuần này bạn cảm thấy được nhóm hỗ trợ?" Câu hỏi tích cực này giúp người mới có cơ hội ghi nhận đồng đội, từ đó dần xây niềm tin một cách tự nhiên.
Bài học: Mức độ "sâu" của theme phải khớp với mức độ trưởng thành và an toàn của nhóm. Theme càng chạm vào cảm xúc và niềm tin thì càng đòi hỏi nền tảng vững. Với nhóm mới hoặc đang biến động, hãy bắt đầu từ theme mang tính xây dựng, tích cực, rồi mới tăng độ sâu.
Ví dụ 3: Nhóm gia công ở Đà Nẵng luân phiên theme theo nhịp
Một công ty gia công phần mềm ở Đà Nẵng có nhóm 7 người làm dự án cho khách hàng Nhật. Scrum Master tên Linh áp dụng cách tiếp cận có hệ thống: thay vì ngẫu hứng, cô lập một lịch theme luân phiên mềm dựa trên nhịp dự án. Cô không cứng nhắc, nhưng có một nguyên tắc: mỗi 4 Sprint thì có ít nhất một Retro "mở" (không theme, hỏi rộng để bắt vấn đề mới), xen kẽ với các Retro theo chủ đề.
Cụ thể, trong một quý cô chạy: Sprint 1 theme Flow (vì hay bị block bởi việc chờ khách hàng Nhật phản hồi), Sprint 2 Retro mở, Sprint 3 theme Chất lượng (trước mốc bàn giao lớn), Sprint 4 theme Năng lượng (sau mốc bàn giao, nhóm mệt). Cô luôn thông báo theme trước một ngày qua kênh chat nhóm để mọi người có thời gian suy nghĩ, kèm một câu mồi.
Sau hai quý, Linh nhận thấy chất lượng action item cải thiện rõ: tỷ lệ action item được hoàn thành tăng từ khoảng 50% lên gần 85%, vì mỗi Retro chỉ tập trung 2-3 hành động cùng hướng. Đồng thời, việc giữ một Retro "mở" định kỳ giúp nhóm không bỏ lỡ những vấn đề nằm ngoài chủ đề đã chọn.
Bài học: Theme là công cụ mạnh nhưng đừng biến mọi Retro thành theme. Hãy luân phiên giữa Retro theo chủ đề (đào sâu) và Retro mở (quét rộng) để không bị "đường hầm hóa" — chỉ nhìn thấy thứ mình đang soi mà bỏ qua vấn đề khác.
Hướng dẫn từng bước
Đây là quy trình tôi khuyên bạn dùng để chuẩn bị và dẫn dắt một buổi Sprint Retrospective theo chủ đề.
Bước 1 — Chẩn đoán trước khi chọn theme. Vài ngày trước Retro, dành 15 phút xem lại Sprint: metrics (số bug, lead time, velocity biến động), những gì nghe được trong Daily, tâm trạng chung của nhóm. Hỏi: "Đâu là một điều, nếu cải thiện được, sẽ tạo khác biệt lớn nhất?" Đó là ứng viên cho theme.
Bước 2 — Chọn một theme duy nhất. Đừng tham. Một buổi Retro chỉ nên có một theme. Nếu bạn thấy hai vấn đề lớn ngang nhau, hãy chọn cái cấp bách hơn và để cái kia cho Sprint sau.
Bước 3 — Viết câu hỏi mồi. Mỗi theme cần 2-4 câu hỏi mở, cụ thể, gợi cảm xúc. Tránh câu hỏi đóng (trả lời có/không) và câu hỏi quy chụp ("Tại sao chất lượng tệ thế?"). Ưu tiên dạng "Điều gì khiến bạn ngạc nhiên...", "Khi nào bạn cảm thấy...".
Bước 4 — Chọn format chứa theme. Ghép theme vào một format phù hợp. Theme Flow hợp với timeline; theme Chất lượng hợp với Plus/Delta hoặc Five Whys; theme Cộng tác hợp với câu hỏi cảm xúc theo vòng tròn. Format chỉ là cái khuôn, đừng để nó lấn át chủ đề.
Bước 5 — Thông báo theme trước. Gửi tin nhắn cho nhóm một ngày trước, nêu theme và một câu mồi. Việc này giúp người hướng nội có thời gian suy nghĩ và nâng chất lượng đóng góp.
Bước 6 — Mở màn bằng cách neo theme. Đầu buổi, dành một phút giải thích vì sao chọn theme này (gắn với dữ liệu). Điều này cho nhóm thấy theme không tùy hứng mà có lý do.
Bước 7 — Thu thập, nhóm, đào sâu. Cho mọi người viết ý kiến, nhóm các ý tương đồng, rồi chọn 1-2 cụm để đào sâu bằng câu hỏi tiếp theo. Đây là lúc theme phát huy sức mạnh: vì phạm vi hẹp, bạn có thời gian đi sâu thay vì lướt qua.
Bước 8 — Chốt 2-3 action item cùng hướng. Vì theme đã thu hẹp phạm vi, action item sẽ tự nhiên hội tụ. Mỗi action cần có người chịu trách nhiệm và cách kiểm chứng.
Lỗi thường gặp & mẹo
Lỗi 1: Theme hóa mọi thứ. Nếu mỗi Retro đều có theme, nhóm có thể bỏ lỡ vấn đề nằm ngoài chủ đề. Mẹo: Cứ vài Sprint chèn một Retro mở để quét rộng.
Lỗi 2: Chọn theme quá sâu cho nhóm chưa sẵn sàng. Như ví dụ fintech, theme Niềm tin với nhóm mới sẽ phản tác dụng. Mẹo: Khớp độ sâu của theme với mức trưởng thành và an toàn của nhóm. Bắt đầu nhẹ, tăng dần.
Lỗi 3: Theme tùy hứng, không gắn dữ liệu. Chọn theme chỉ vì "thấy hay" khiến nhóm cảm giác bị làm trò. Mẹo: Luôn neo theme vào một quan sát hoặc con số thật, và nói rõ điều đó lúc mở màn.
Lỗi 4: Câu hỏi mồi mang tính quy chụp. "Vì sao team lười test thế?" sẽ khiến mọi người phòng thủ. Mẹo: Dùng câu hỏi trung lập, gợi tò mò: "Điều gì về việc test tuần này khiến bạn ngạc nhiên?"
Lỗi 5: Để format lấn át theme. Sa đà vào trò chơi của format mà quên đào sâu chủ đề. Mẹo: Nhớ rằng theme là vua, format là người hầu.
Mẹo nâng cao: Lưu lại một "thư viện theme" của riêng nhóm bạn — mỗi lần dùng theme nào, ghi lại hiệu quả ra sao, action item gì. Sau vài quý, bạn sẽ có một bộ công cụ được cá nhân hóa, hiểu rõ theme nào hợp với nhóm mình ở giai đoạn nào.
Bài tập thực hành
Bài tập 1 — Chẩn đoán và chọn theme. Nhìn lại Sprint gần nhất của nhóm bạn (hoặc một Sprint giả định). Liệt kê 3 quan sát: một con số (bug, velocity, lead time), một điều nghe được trong Daily, một cảm nhận về tâm trạng nhóm. Từ đó, chọn MỘT theme phù hợp nhất và viết một câu lý giải tại sao.
Bài tập 2 — Thiết kế bộ câu hỏi. Với theme đã chọn ở bài 1, viết 3 câu hỏi mồi. Tự kiểm tra: câu hỏi của bạn có mở không (không trả lời được bằng có/không)? Có cụ thể không? Có trung lập, không quy chụp không? Sửa lại bất kỳ câu nào vi phạm.
Bài tập 3 — Lập lịch theme cho một quý. Phác một lịch theme mềm cho 6 Sprint tới của nhóm: Sprint nào theo chủ đề (theme gì), Sprint nào để mở. Ghi chú lý do cho mỗi lựa chọn dựa trên nhịp dự án dự kiến.
Bài tập 4 — Tự đánh giá độ sâu. Cho nhóm hiện tại của bạn, xếp 6 theme trong bài (Chất lượng, Cộng tác, Niềm tin, Flow, Giá trị, Năng lượng) theo thứ tự "an toàn để dùng ngay" đến "cần chuẩn bị thêm". Viết một câu giải thích cho theme bạn xếp cuối cùng.
Tóm tắt
Sprint Retrospective theo chủ đề là liều thuốc chữa căn bệnh nhàm chán và hời hợt của Retro lặp lại. Khác với format (cách tổ chức hoạt động), theme là lăng kính trọng tâm mà qua đó nhóm nhìn lại Sprint. Nghịch lý cốt lõi: khi bạn thu hẹp phạm vi câu hỏi, bạn thường nhận được câu trả lời sâu sắc hơn và action item tập trung hơn.
Hãy ghi nhớ ba nguyên tắc. Thứ nhất, theme nên đến từ dữ liệu — metrics, quan sát trong Daily, tâm trạng nhóm — chứ không phải từ sự ngẫu hứng. Thứ hai, khớp độ sâu của theme với mức trưởng thành của nhóm: nhóm mới hay đang biến động thì bắt đầu bằng theme xây dựng, tích cực; theme nhạy cảm như Niềm tin cần nền tảng an toàn vững chắc. Thứ ba, đừng theme hóa mọi thứ — luân phiên giữa Retro theo chủ đề (đào sâu) và Retro mở (quét rộng) để không bỏ lỡ vấn đề ngoài tầm soi.
Với một thư viện theme thực dụng trong tay — Chất lượng, Cộng tác, Niềm tin, Flow, Giá trị, Năng lượng — cùng quy trình tám bước từ chẩn đoán đến chốt action, bạn đã có đủ công cụ để biến mỗi Retrospective thành một buổi cải tiến thực sự có sức sống, thay vì một thủ tục lặp đi lặp lại mà ai cũng ngán.