Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng một đội bóng đá thi đấu hết trận này đến trận khác mà không bao giờ xem lại băng ghi hình, không bao giờ ngồi lại bàn xem pha phối hợp nào bị hỏng, vì sao thủng lưới ở phút 80. Họ sẽ lặp lại đúng những sai lầm cũ, mùa này qua mùa khác. Một Scrum Team không có Sprint Retrospective tử tế cũng giống hệt như vậy: chạy hết Sprint này đến Sprint kia, giao sản phẩm đều đặn, nhưng cách làm việc thì giậm chân tại chỗ.
Trong toàn bộ khóa học này, bạn đã được học về Sprint Planning (Bài 16), Daily Scrum (Bài 17) và Sprint Review (Bài 18). Có một điểm cần phân biệt rất rõ ngay từ đầu: Sprint Review xem xét SẢN PHẨM (cái team làm ra — the WHAT), còn Sprint Retrospective xem xét CÁCH LÀM VIỆC (cách team làm việc với nhau — the HOW). Đây là hai sự kiện hoàn toàn khác nhau về mục tiêu, và việc gộp chúng làm một là một trong những lỗi phổ biến nhất ở các team Việt Nam mới áp dụng Scrum.
Retrospective chính là cơ chế "liên tục cải tiến" (continuous improvement) được nhúng thẳng vào nhịp làm việc của Scrum. Nó là sự kiện cuối cùng khép lại một Sprint, và là lý do tại sao một team Scrum trưởng thành sau một năm sẽ làm việc hiệu quả hơn rất nhiều so với chính họ ở ngày đầu — không phải vì họ thông minh hơn, mà vì họ học được cách tự sửa mình một cách có hệ thống. Với vai trò Product Owner, bạn không "sở hữu" sự kiện này, nhưng bạn là một thành viên tham gia đầy đủ và tiếng nói của bạn ảnh hưởng trực tiếp đến chất lượng cải tiến của cả team.
Khái niệm cốt lõi
Sprint Retrospective là gì
Sprint Retrospective là sự kiện trong đó toàn bộ Scrum Team — gồm Developers, Scrum Master và Product Owner — cùng ngồi lại để kiểm tra (inspect) cách họ đã làm việc trong Sprint vừa qua và xác định những cải tiến (improvements) cho Sprint tiếp theo. Mục đích cốt lõi gói gọn trong một câu: Inspect HOW the team works + identify improvements.
Theo Scrum Guide, đội nhóm sẽ xem xét cách Sprint vừa rồi diễn ra dưới nhiều góc độ: con người (individuals), các mối quan hệ (interactions), quy trình (processes), công cụ (tools) và cả Definition of Done (DoD — tiêu chuẩn "xong"). Họ thảo luận điều gì đã diễn ra tốt, vấn đề nào đã gặp phải, và những vấn đề đó đã (hoặc chưa) được giải quyết ra sao.
Điều quan trọng nhất: Retrospective không dừng ở việc "than thở cho nhẹ lòng". Nó phải kết thúc bằng những hành động cải tiến cụ thể mà team cam kết thực hiện. Một Retrospective hay là một Retrospective tạo ra thay đổi thật.
Time-box: giới hạn thời gian
Scrum quy định Retrospective là sự kiện có time-box (giới hạn thời gian) rõ ràng:
- Tối đa 3 giờ cho một Sprint dài 1 tháng (4 tuần).
- Khoảng 1,5 giờ cho Sprint dài 2 tuần.
- Sprint càng ngắn thì Retrospective càng ngắn tương ứng — Sprint 1 tuần thường chỉ cần 45 phút đến 1 giờ.
Ai tham gia và ai điều phối
Toàn bộ Scrum Team tham gia. Scrum Master thường đóng vai facilitator (người điều phối) — chuẩn bị format, giữ nhịp, đảm bảo mọi người được lên tiếng. Tuy nhiên Scrum Master không phải "sếp" của buổi họp; lý tưởng nhất là cả team cùng sở hữu sự kiện này.
Một câu hỏi rất hay gặp ở Việt Nam: Quản lý cấp trên (manager, trưởng phòng) có nên ngồi dự Retrospective không? Câu trả lời thường là không, hoặc chỉ khi được team mời. Lý do: sự hiện diện của sếp khiến mọi người không dám nói thật, và Retrospective sống chết bằng sự thẳng thắn.
Nguyên tắc nền tảng: An toàn tâm lý
Đây là khái niệm quan trọng nhất của cả bài. Psychological safety (an toàn tâm lý) là cảm giác rằng mình có thể nói ra vấn đề, thừa nhận sai lầm, đặt câu hỏi "ngớ ngẩn" mà không sợ bị trừng phạt hay bị chê cười. Không có an toàn tâm lý, Retrospective chỉ còn là một buổi họp hình thức nơi mọi người gật gù "Sprint vừa rồi ổn" rồi giải tán.
Có một nguyên tắc nổi tiếng được gọi là Prime Directive (Chỉ thị tối thượng) của Norm Kerth, thường được đọc to ở đầu buổi Retro: "Bất kể chúng ta khám phá ra điều gì, chúng ta tin rằng mọi người đã làm việc tốt nhất có thể trong khả năng, với kiến thức và nguồn lực họ có vào thời điểm đó." Tinh thần của nó là: Retro tập trung vào vấn đề và hệ thống, không truy cứu cá nhân.
Tình huống thực tế
Ví dụ 1: Tiki và buổi Retro "ai cũng nói ổn"
Một nhóm phát triển tính năng thanh toán tại một công ty thương mại điện tử lớn ở TP.HCM (lấy bối cảnh tương tự Tiki) gặp một vấn đề kinh điển. Mỗi cuối Sprint 2 tuần, Scrum Master hỏi: "Sprint vừa rồi mọi người thấy sao?" Cả 7 thành viên lần lượt trả lời "ổn", "bình thường", "cũng được". Buổi họp kết thúc sau 20 phút. Suốt 4 Sprint liền, velocity của team tụt từ 34 điểm xuống còn 22 điểm, nhưng không ai nói gì trong Retro.
Vấn đề nằm ở chỗ team có một bạn senior dev tính khá nóng, và cấp quản lý đôi khi ghé ngồi cuối phòng. Không ai dám nói rằng việc bạn senior tự ý đổi kiến trúc giữa Sprint đã làm cả team phải làm lại nhiều thứ.
Scrum Master sau đó thay đổi cách làm: mời quản lý ra ngoài, đổi sang format viết ẩn danh trên giấy note (mỗi người ghi vấn đề lên giấy, dán lên bảng, rồi cùng nhóm các ý giống nhau). Ngay buổi đầu áp dụng, vấn đề "thay đổi kiến trúc giữa Sprint mà không bàn bạc" hiện rõ trên bảng với 4 phiếu. Team thống nhất một quy tắc: mọi thay đổi kiến trúc lớn phải đưa ra Daily Scrum trước.
Bài học: Format và sự an toàn tâm lý quyết định chất lượng Retro nhiều hơn cả việc team có "giỏi" hay không. Khi mọi người chỉ nói "ổn", đó không phải dấu hiệu mọi thứ ổn — đó là dấu hiệu họ không cảm thấy an toàn để nói thật.
Ví dụ 2: MoMo và Retrospective tạo ra action không bao giờ làm
Một team tại một công ty fintech ở Hà Nội (bối cảnh tương tự MoMo) làm Retro rất sôi nổi. Mỗi buổi họ liệt kê được 8–10 vấn đề và 8–10 hành động cải tiến. Nghe thì tuyệt, nhưng đến Sprint sau, gần như không hành động nào được thực hiện. Tới Retro kế tiếp, những vấn đề cũ lại xuất hiện y nguyên, team lại hăng hái liệt kê tiếp. Họ gọi đùa đó là "Retro ghi nhật ký".
Một thành viên đề xuất thay đổi: thay vì 10 action mơ hồ, mỗi Retro chỉ chọn tối đa 1–2 cải tiến quan trọng nhất, biến chúng thành một item có người chịu trách nhiệm (owner), có tiêu chí "xong" rõ ràng, và đưa thẳng vào Sprint Backlog của Sprint sau như một công việc thực sự chứ không phải lời hứa suông. Ví dụ thay vì "cải thiện việc code review", action trở thành: "Bạn Hùng cấu hình quy tắc: mỗi PR phải có review trong vòng 4 giờ làm việc, hoàn thành trước cuối Sprint."
Sau 3 Sprint áp dụng cách này, tỉ lệ hoàn thành action cải tiến tăng từ khoảng 10% lên trên 80%. Quan trọng hơn, team thực sự cảm thấy Retro "có ích" thay vì tốn thời gian.
Bài học: Một cải tiến được thực hiện có giá trị hơn mười cải tiến được liệt kê. Đưa action vào Sprint Backlog với owner và tiêu chí rõ ràng là cách biến lời nói thành thay đổi.
Ví dụ 3: Startup SaaS và vai trò Product Owner trong Retro
Tại một startup SaaS B2B khoảng 30 người ở Singapore phục vụ thị trường Đông Nam Á, có một PO ban đầu hiểu nhầm rằng "Retro là chuyện của Developers, mình là PO thì ngồi nghe cho phải phép". Anh thường mở laptop trả lời email trong suốt buổi họp.
Một lần, Developers nêu vấn đề: "User Story thường được giao quá trễ, đến giữa Sprint mới rõ yêu cầu, làm chúng tôi không kịp phản hồi." Đây thực ra là một vấn đề mà PO là một phần nguyên nhân — backlog refinement (Bài 23) chưa được PO chuẩn bị tốt. Vì PO không thực sự tham gia, vấn đề này bị bỏ lửng.
Khi PO bắt đầu tham gia nghiêm túc — đóng laptop, lắng nghe, và chủ động nhận phần trách nhiệm của mình — anh phát hiện ra mình có thể cải thiện bằng cách dành 1 buổi refinement cố định mỗi tuần và viết User Story rõ ràng hơn theo format chuẩn. Velocity dự đoán được (predictability) của team tăng lên rõ rệt trong vòng 2 tháng, vì Developers không còn bị "đói" yêu cầu giữa Sprint.
Bài học: PO là thành viên đầy đủ của Retrospective. Nhiều vấn đề về cách làm việc của team bắt nguồn từ phía PO (yêu cầu mơ hồ, ưu tiên thay đổi liên tục, thiếu refinement). Nếu PO không tham gia, một nửa bức tranh bị thiếu.
Hướng dẫn từng bước
Một Retrospective hiệu quả thường đi theo cấu trúc 5 giai đoạn (mô hình kinh điển của Esther Derby và Diana Larsen):
Bước 1 — Set the Stage (Mở màn, ~5–10%). Tạo không khí an toàn. Đọc Prime Directive, nhắc lại đây là không gian không phán xét cá nhân. Dùng một câu hỏi khởi động nhẹ (check-in) như "Một từ mô tả cảm giác của bạn về Sprint vừa rồi?" để mọi người bắt đầu lên tiếng — vì người đã nói một lần sẽ dễ nói tiếp.
Bước 2 — Gather Data (Thu thập dữ liệu, ~25%). Cùng nhìn lại Sprint một cách khách quan. Thu thập sự kiện, dữ liệu, cảm xúc: chuyện gì đã xảy ra, burn-down chart thế nào, có sự cố gì. Đây là lúc dùng các format như "Mad / Sad / Glad", "Start / Stop / Continue", hay "4Ls (Liked / Learned / Lacked / Longed for)".
Bước 3 — Generate Insights (Phân tích, tìm gốc rễ, ~25%). Đừng dừng ở triệu chứng. Hỏi tại sao nhiều lần (kỹ thuật 5 Whys) để tìm nguyên nhân gốc rễ (root cause). Ví dụ: "Giao trễ" → vì sao? → "Review chậm" → vì sao? → "Chỉ 1 người được phép review" → đó mới là gốc rễ.
Bước 4 — Decide What to Do (Quyết định hành động, ~20%). Chọn 1–2 cải tiến quan trọng nhất (đừng tham). Với mỗi cải tiến: ghi rõ owner, tiêu chí hoàn thành, và đưa vào Sprint Backlog của Sprint tới. Có thể bỏ phiếu (dot voting) để chọn vấn đề ưu tiên.
Bước 5 — Close (Khép lại, ~10%). Tóm tắt các action đã chốt, cảm ơn mọi người, và nhanh chóng "retro của retro" — hỏi xem buổi họp này có giá trị không, cần cải thiện gì cho lần sau.
Một lưu ý xuyên suốt: Hãy thay đổi format định kỳ. Dùng đi dùng lại đúng một mẫu (như "Start/Stop/Continue") khiến team chán và trả lời theo quán tính. Đổi format giúp giữ sự tươi mới và khai thác được những góc nhìn khác nhau.
Lỗi thường gặp & mẹo
Lỗi 1 — Bỏ qua Retro khi "bận". Khi sắp đến deadline, Retro là sự kiện đầu tiên bị cắt. Nhưng càng áp lực thì team càng có nhiều vấn đề cần xử lý — đó chính là lúc cần Retro nhất. Mẹo: cố định lịch Retro như một cuộc hẹn bất di bất dịch.
Lỗi 2 — Biến Retro thành phiên đổ lỗi (blame game). Khi không khí trở thành "chỉ tay vào ai làm hỏng", mọi người sẽ phòng thủ và Retro chết. Mẹo: luôn quy chiếu về hệ thống và quy trình, dùng ngôn ngữ "chúng ta" thay vì "anh/chị". Đọc Prime Directive là một liều thuốc tốt.
Lỗi 3 — Liệt kê quá nhiều action. Mười hành động cải tiến đồng nghĩa với không hành động nào được làm tới nơi. Mẹo: kỷ luật chọn tối đa 1–2 cải tiến mỗi Sprint, và hoàn thành dứt điểm trước khi thêm cái mới.
Lỗi 4 — Action không có owner, không có deadline, không vào Backlog. Đây là lý do số một khiến Retro vô dụng. Mẹo: mọi cải tiến phải là một item cụ thể trong Sprint Backlog, có người chịu trách nhiệm.
Lỗi 5 — Gộp Retro vào Sprint Review. Vì cả hai diễn ra cuối Sprint, nhiều team gộp lại. Hệ quả: phần "cách làm việc" bị nuốt chửng bởi phần "demo sản phẩm". Mẹo: tách bạch rõ ràng — Review trước (với stakeholder), Retro sau (chỉ nội bộ team).
Lỗi 6 — Chỉ nói về cái xấu. Retro không phải là buổi than vãn. Việc ghi nhận và duy trì những điều đang làm tốt cũng quan trọng không kém — đó là cách team biết giữ lấy điểm mạnh của mình.
Mẹo cho team remote/phân tán: Dùng công cụ trực tuyến (Miro, EasyRetro, FunRetro) cho phép viết note song song và ẩn danh — điều này thực ra còn tăng độ thẳng thắn so với họp trực tiếp.
Bài tập thực hành
Bài tập 1 — Thiết kế một buổi Retro. Giả sử bạn là Product Owner của một team 6 người chạy Sprint 2 tuần. Hãy phác thảo một agenda Retrospective 75 phút theo 5 giai đoạn (Set the Stage → Gather Data → Generate Insights → Decide → Close), ghi rõ thời lượng từng phần và chọn một format thu thập dữ liệu phù hợp.
Bài tập 2 — Luyện 5 Whys. Lấy một vấn đề thực tế trong công việc của bạn (ví dụ: "Sprint vừa rồi không hoàn thành Sprint Goal"). Đặt câu hỏi "tại sao" liên tiếp 5 lần để truy ra nguyên nhân gốc rễ. Viết ra cả chuỗi.
Bài tập 3 — Viết lại action mơ hồ. Cho hai action sau: (a) "Cải thiện giao tiếp trong team", (b) "Test kỹ hơn". Hãy viết lại mỗi action thành một item có thể đưa vào Sprint Backlog: cụ thể, đo được, có owner, có tiêu chí hoàn thành.
Bài tập 4 — Tự đánh giá. Nhìn lại 3 buổi Retro gần nhất của team bạn (nếu chưa có team, hãy hình dung). Bao nhiêu phần trăm action đã thực sự được hoàn thành? Nếu dưới 50%, hãy liệt kê 2 nguyên nhân và 2 cách khắc phục.
Tóm tắt
Sprint Retrospective là cơ chế tự cải tiến của Scrum: nó kiểm tra CÁCH team làm việc (the HOW) và biến những phát hiện đó thành hành động cải tiến cụ thể cho Sprint sau. Khác với Sprint Review vốn xem xét sản phẩm, Retro hướng nội vào con người, tương tác, quy trình, công cụ và Definition of Done.
Những điểm cần ghi nhớ:
- Time-box: tối đa 3 giờ cho Sprint 1 tháng, khoảng 1,5 giờ cho Sprint 2 tuần.
- Toàn bộ Scrum Team tham gia, gồm cả Product Owner — đừng đứng ngoài cuộc.
- An toàn tâm lý là điều kiện sống còn; không có nó, Retro chỉ là hình thức.
- Tập trung vào hệ thống, không đổ lỗi cá nhân (tinh thần Prime Directive).
- Chọn 1–2 cải tiến, gắn owner và tiêu chí, đưa thẳng vào Sprint Backlog — một cải tiến được làm hơn mười cái chỉ nói.
- Đổi format định kỳ để giữ sự tươi mới và thẳng thắn.