Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn đang lái một con tàu vượt biển. Bạn có bản đồ (Product Backlog), có người cầm lái (Developers), có thuyền trưởng định hướng (Product Owner). Nhưng nếu sau mỗi chặng đi, không ai dừng lại để hỏi "Chặng vừa rồi chúng ta đi nhanh hay chậm? Có chỗ nào suýt va đá ngầm? Lần tới ta nên buộc dây thừng kiểu khác không?" — thì con tàu ấy chỉ đang lặp đi lặp lại cùng những sai lầm, chuyến này qua chuyến khác.
Sprint Retrospective chính là khoảnh khắc dừng lại ấy. Trong toàn bộ bộ máy Scrum, đây là sự kiện duy nhất mà đối tượng được "soi" không phải là sản phẩm, mà là chính cách nhóm làm việc cùng nhau. Nếu Sprint Review (Bài 13) trả lời câu hỏi "Chúng ta đã xây ĐÚNG thứ cần xây chưa?", thì Retrospective trả lời "Chúng ta đang làm việc với nhau ĐỦ TỐT chưa, và làm sao để tốt hơn?".
Tôi gọi Retrospective là "động cơ cải tiến" (improvement engine) vì một lý do rất thực tế: trong Scrum, không có cấp trên nào ngồi viết quy trình mới rồi áp xuống cho nhóm. Sự cải tiến phải đến từ bên trong, từ chính những người làm việc. Và Retrospective là cơ chế thể chế hóa điều đó — biến việc "tự sửa mình" từ một mong muốn mơ hồ thành một cam kết có lịch, có người tham gia, có kết quả đầu ra cụ thể. Nhóm nào bỏ qua Retrospective, hoặc làm cho có lệ, thường sau 6 tháng vẫn vấp đúng những hòn đá cũ. Đó là lý do bài này quan trọng với bất kỳ Project Manager nào muốn nhóm của mình thật sự giỏi lên theo thời gian.
Khái niệm cốt lõi
Định nghĩa và mục đích
Sprint Retrospective là sự kiện cuối cùng trong một Sprint, diễn ra sau Sprint Review và trước Sprint Planning của Sprint kế tiếp. Mục đích của nó, theo đúng tinh thần Scrum Guide, là để Scrum Team thanh tra (inspect) chính mình trên bốn phương diện:
- Con người (individuals) — chúng ta giao tiếp, hỗ trợ nhau thế nào?
- Tương tác (interactions) — các cuộc họp, cách trao đổi, sự phối hợp ra sao?
- Quy trình (process) — cách chúng ta làm việc, từ refinement đến review, có chỗ nào nghẽn?
- Công cụ (tools) — Jira, Slack, CI/CD, bảng Kanban... có giúp hay đang cản trở?
Timebox
Theo Scrum Guide, Retrospective có timebox tối đa 3 giờ cho một Sprint dài 4 tuần. Với Sprint ngắn hơn, thời lượng thường ngắn hơn tương ứng:
- Sprint 1 tuần: khoảng 45 phút.
- Sprint 2 tuần: khoảng 1.5 giờ.
- Sprint 4 tuần: tối đa 3 giờ.
Ai tham gia?
Toàn bộ Scrum Team: Developers, Product Owner và Scrum Master. Đây là điểm nhiều người Việt Nam làm sai — họ nghĩ Retro chỉ dành cho "team dev". Không. Product Owner cũng là một phần của cách nhóm vận hành; nếu PO viết user story mơ hồ khiến dev mất thời gian đoán, đó là vấn đề cần đưa ra Retro. Scrum Master thường đóng vai facilitator (người điều phối), nhưng cũng là thành viên có quyền nêu vấn đề.
Một nguyên tắc vàng: không mời sếp lớn hay người ngoài nhóm vào Retro, trừ khi có lý do đặc biệt và cả nhóm đồng ý. Sự hiện diện của cấp trên thường khiến mọi người không dám nói thật.
Năm giai đoạn của một Retrospective tốt
Cuốn sách kinh điển Agile Retrospectives của Esther Derby và Diana Larsen đề xuất cấu trúc 5 bước mà tôi khuyên bạn nên dùng làm xương sống:
- Set the Stage (Mở màn) — tạo không khí an toàn, để mọi người sẵn sàng nói.
- Gather Data (Thu thập dữ liệu) — nhìn lại những gì đã xảy ra: sự kiện, số liệu, cảm xúc.
- Generate Insights (Tìm hiểu sâu) — hỏi "tại sao", tìm nguyên nhân gốc rễ.
- Decide What to Do (Quyết định hành động) — chọn 1–2 cải tiến cụ thể.
- Close the Retrospective (Kết thúc) — chốt lại, phân công, đánh giá chính buổi họp.
Tâm lý an toàn (Psychological Safety)
Đây là nền móng. Nếu thành viên sợ bị đổ lỗi, họ sẽ giấu vấn đề, và Retro trở thành buổi diễn kịch. Norm Kerth — cha đẻ của Retrospective hiện đại — đặt ra "Nguyên tắc tối thượng" (Prime Directive) mà tôi khuyên mỗi buổi nên đọc to: "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 họ có thể, với những gì họ biết, kỹ năng họ có và nguồn lực sẵn có lúc đó." Câu này dịch sang ngôn ngữ thực tế: chúng ta soi VẤN ĐỀ, không soi CON NGƯỜI.
Tình huống thực tế
Tình huống 1: Tiki và "buổi Retro đổ lỗi"
Một nhóm phát triển tại một công ty thương mại điện tử lớn ở TP.HCM (gọi là nhóm Checkout) gặp sự cố nghiêm trọng: tính năng thanh toán mới bị lỗi trên production, gây gián đoạn 40 phút vào giờ cao điểm. Buổi Retro tiếp theo, không khí căng như dây đàn. Scrum Master mở đầu bằng câu hỏi "Ai đẩy cái commit gây lỗi?" — và thế là cả buổi biến thành phiên truy tìm thủ phạm. Bạn dev tên Minh ngồi co rúm, cả nhóm im lặng, không ai dám nói thêm điều gì.
Diễn giải: Sai lầm ở đây không nằm ở Minh, mà ở cách dẫn dắt. Khi câu hỏi đầu tiên là "ai", mọi cánh cửa tâm lý đóng sập. Sprint sau, sự cố tương tự lặp lại vì gốc rễ thật — không có quy trình review code và không có staging environment đúng nghĩa — chưa bao giờ được nói ra.
Bài học: Sau khi được một Agile Coach góp ý, nhóm đổi cách làm. Họ áp dụng kỹ thuật 5 Whys (hỏi "tại sao" 5 lần): Tại sao lỗi ra production? Vì không ai phát hiện. Tại sao không phát hiện? Vì không có review. Tại sao không có review? Vì deadline gấp. Tại sao gấp? Vì PO cam kết với sếp mà không hỏi team... Đến đây nguyên nhân gốc lộ ra, và cải tiến trở nên rõ ràng: bắt buộc pull-request review + thiết lập staging. Vấn đề con người biến thành vấn đề hệ thống — và hệ thống thì sửa được.
Tình huống 2: Startup fintech ở Hà Nội và "danh sách 15 cải tiến"
Một startup fintech khoảng 12 người ở Hà Nội rất nhiệt tình với Agile. Mỗi buổi Retro, nhóm liệt kê được tới 12–15 điều cần cải thiện, ghi đầy lên bảng Miro, ai nấy gật gù hài lòng rồi ra về. Nhưng ba tháng trôi qua, khi Scrum Master mở lại các bảng cũ, anh phát hiện gần như không cải tiến nào được thực thi. Cùng những vấn đề ("daily scrum lê thê", "ước lượng sai", "thiếu test") cứ xuất hiện lặp lại Sprint này qua Sprint khác.
Diễn giải: Đây là cái bẫy "danh sách mơ ước". Khi nhóm cố sửa 15 thứ cùng lúc, họ thực chất không sửa được thứ nào — vì không có ai chịu trách nhiệm, không có thời gian, không có sự tập trung.
Bài học: Scrum Master đặt ra một luật mới: mỗi Retro chỉ chọn TỐI ĐA 2 cải tiến, và mỗi cải tiến phải có chủ sở hữu (owner) cùng một bước hành động cụ thể đưa vào Sprint Backlog như một công việc thật sự. Họ còn đưa cải tiến lớn nhất lên đầu bảng task của Sprint kế tiếp. Kết quả sau hai tháng: vấn đề "daily scrum lê thê" được giải quyết dứt điểm bằng cách dời các cuộc thảo luận kỹ thuật sang sau Daily. Bài học cốt lõi: ít mà làm được còn hơn nhiều mà bỏ ngỏ.
Tình huống 3: Nhóm remote tại một công ty outsourcing Đà Nẵng
Một công ty gia công phần mềm ở Đà Nẵng có nhóm làm cho khách Nhật, sau COVID chuyển sang làm việc từ xa hoàn toàn. Retro của họ rơi vào trạng thái "chết lâm sàng": ai cũng tắt camera, Scrum Master hỏi "Sprint vừa rồi thế nào?", và cả nhóm trả lời "Ổn anh, không có gì". Buổi họp 15 phút là xong, không cải tiến nào ra đời.
Diễn giải: Khi làm remote, sự im lặng không có nghĩa là mọi thứ tốt — nó thường có nghĩa là mọi người ngại nói thành tiếng. Câu hỏi mở chung chung ("thế nào") trong môi trường online gần như luôn dẫn đến câu trả lời rỗng.
Bài học: Nhóm chuyển sang dùng công cụ tương tác như EasyRetro (trước đây là FunRetro), nơi mỗi người viết ẩn danh vào ba cột "Mad / Sad / Glad" trong 5 phút đầu, sau đó cùng gom nhóm và bỏ phiếu (dot voting) chọn vấn đề nóng nhất. Việc viết trước, viết ẩn danh, đã phá vỡ sự im lặng — vì giờ đây không ai phải là người đầu tiên dám mở lời. Số lượng vấn đề được nêu tăng từ gần 0 lên trung bình 8–10 mỗi Sprint, và chất lượng cải tiến tăng rõ rệt.
Hướng dẫn từng bước
Dưới đây là quy trình chạy một Retrospective hiệu quả cho Sprint 2 tuần (khoảng 75 phút):
Bước 1 — Chuẩn bị trước (Scrum Master, 10 phút trước buổi họp). Chọn một định dạng (format) phù hợp với hoàn cảnh. Đừng dùng mãi một format — nhóm sẽ chán. Vài lựa chọn phổ biến: Start–Stop–Continue (bắt đầu làm gì, ngừng làm gì, tiếp tục làm gì), Mad–Sad–Glad (tập trung cảm xúc), 4Ls (Liked–Learned–Lacked–Longed for), hoặc Sailboat (thuyền buồm: gió đẩy đi, mỏ neo kéo lại, đá ngầm rủi ro).
Bước 2 — Set the Stage (5 phút). Mở màn bằng việc đọc Prime Directive. Có thể dùng một câu check-in nhanh: "Hãy mô tả Sprint vừa rồi bằng một từ." Mục tiêu là làm cho mọi người cất tiếng nói ngay từ đầu — người đã nói một lần sẽ dễ nói tiếp.
Bước 3 — Gather Data (15 phút). Cho mọi người viết (giấy dán hoặc bảng online) trong im lặng. Đưa cả dữ liệu khách quan vào: velocity Sprint này so với trước, số bug, số story bị carry-over. Cảm xúc và số liệu, cả hai đều quan trọng.
Bước 4 — Generate Insights (20 phút). Gom nhóm các thẻ giống nhau, rồi đào sâu vào 2–3 chủ đề nóng nhất bằng 5 Whys hoặc Fishbone diagram. Đây là phần dễ bị bỏ qua nhất nhưng lại giá trị nhất — đừng vội nhảy sang giải pháp.
Bước 5 — Decide What to Do (15 phút). Dùng dot voting để chọn 1–2 cải tiến. Với mỗi cải tiến, viết theo công thức SMART: ai làm, làm gì, đến khi nào. Ví dụ: "Nam sẽ thiết lập rule bắt buộc 1 reviewer cho mỗi PR, hoàn thành trong tuần đầu Sprint tới." Đưa nó vào Sprint Backlog như một item thật.
Bước 6 — Close (5 phút). Tóm tắt cải tiến đã chốt, phân công rõ ràng, và làm một vòng ROTI (Return on Time Invested) — mỗi người giơ 1 đến 5 ngón tay đánh giá buổi họp có đáng thời gian không. Đây là cách bạn cải tiến chính buổi Retro của mình.
Bước 7 — Theo dõi (Sprint kế tiếp). Đầu Retro lần sau, việc đầu tiên là kiểm tra: cải tiến lần trước đã làm chưa? Nếu không kiểm tra, mọi cam kết sẽ bốc hơi.
Lỗi thường gặp & mẹo
Lỗi 1 — Bỏ Retro khi bận. "Sprint này gấp quá, bỏ Retro nhé." Đây là sai lầm nguy hiểm nhất. Bạn càng bận, càng có nhiều thứ trục trặc, thì càng cần Retro. Bỏ Retro là bỏ luôn cơ hội để hết bận.
Lỗi 2 — Retro biến thành buổi than. Nói về vấn đề mà không ra hành động. Mẹo: luôn dành ít nhất 1/3 thời gian cho phần "Decide What to Do".
Lỗi 3 — Cùng một format mỗi lần. Nhóm chạy Start–Stop–Continue tuần này qua tuần khác sẽ trả lời một cách máy móc. Mẹo: luân phiên format, thi thoảng đổi cả người facilitate (cho một dev điều phối).
Lỗi 4 — Không theo dõi cải tiến. Cải tiến được chốt rồi để đó. Mẹo: biến nó thành một task có trong Sprint Backlog, có người chịu trách nhiệm, hiện trên bảng như mọi công việc khác.
Lỗi 5 — Đổ lỗi cá nhân. Mẹo: luôn quy chiếu về Prime Directive và chuyển hướng từ "ai làm" sang "điều gì trong hệ thống cho phép việc đó xảy ra".
Lỗi 6 — Mời cấp trên dự để "cho thấy nghiêm túc". Mẹo: giữ Retro là không gian riêng của nhóm. Báo cáo kết quả cải tiến cho cấp trên thì được, nhưng để họ ngồi nghe trực tiếp thì đừng.
Mẹo vàng: Một Retro mà không tạo ra bất kỳ thay đổi nào trong cách làm việc của Sprint sau, thì về bản chất đã thất bại — dù mọi người ra về vui vẻ. Hãy đo lường Retro bằng sự thay đổi, không bằng cảm giác.
Bài tập thực hành
- Thiết kế một buổi Retro. Giả sử bạn là Scrum Master của một nhóm 6 người vừa kết thúc Sprint 2 tuần với velocity giảm 30% so với trung bình. Hãy chọn một format phù hợp, viết ra agenda chi tiết theo 5 giai đoạn kèm timebox cho từng phần (tổng 75 phút). Giải thích vì sao bạn chọn format đó.
- Luyện 5 Whys. Lấy một vấn đề có thật ở nhóm bạn (ví dụ: "story hay bị carry-over sang Sprint sau"). Viết ra chuỗi 5 câu hỏi "tại sao" để truy về nguyên nhân gốc. Sau đó đề xuất một cải tiến SMART giải quyết đúng nguyên nhân đó.
- Phân biệt đúng/sai. Với mỗi phát biểu sau, xác định nó vi phạm nguyên tắc Retro nào và sửa lại: (a) "Lần sau cố gắng làm tốt hơn nhé cả nhà." (b) "Bug này là tại bạn QA không test kỹ." (c) "Chúng ta sẽ cải thiện 10 thứ trong Sprint tới."
- Tự đánh giá (phản tư). Nếu nhóm bạn đang chạy Scrum: trong 3 Retro gần nhất, có bao nhiêu cải tiến được chốt và bao nhiêu thực sự được thực thi? Tỷ lệ đó nói lên điều gì về "động cơ cải tiến" của nhóm bạn?
Tóm tắt
Sprint Retrospective là sự kiện cuối Sprint, nơi cả Scrum Team — gồm Developers, Product Owner và Scrum Master — cùng dừng lại để thanh tra con người, tương tác, quy trình và công cụ, rồi cam kết ít nhất một cải tiến cụ thể để thực thi ngay Sprint kế tiếp. Timebox tối đa là 3 giờ cho Sprint 4 tuần, thường ngắn hơn nhiều với Sprint ngắn.
Điều làm nên một Retro tốt không phải là format đẹp hay không khí vui, mà là ba thứ: tâm lý an toàn (soi vấn đề chứ không soi người, nhờ Prime Directive), đào đến nguyên nhân gốc (5 Whys thay vì dừng ở triệu chứng), và ít cải tiến nhưng làm tới nơi (1–2 cải tiến SMART có chủ sở hữu, đưa vào Sprint Backlog, theo dõi ở Retro sau).
Ba tình huống ở Tiki, startup fintech Hà Nội và nhóm remote Đà Nẵng cho thấy cùng một sự thật: Retrospective thất bại không vì nhóm thiếu thiện chí, mà vì thiếu kỹ thuật điều phối đúng. Khi bạn dẫn dắt đúng, Retro trở thành động cơ giúp nhóm giỏi lên đều đặn — Sprint này qua Sprint khác, đó chính là tinh thần cốt lõi của empirical process control mà toàn bộ Scrum xoay quanh. Hãy nhớ: nhóm không tự nhiên giỏi lên; họ giỏi lên vì có một cơ chế buộc họ dừng lại, nhìn lại và sửa mình. Cơ chế đó là Retrospective.