Mở đầu — vì sao bài này quan trọng
Nếu Sprint Review (Bài 16) là buổi bạn cho thế giới bên ngoài xem cái team đã làm ra, thì Sprint Retrospective (retro) là buổi team đóng cửa lại, ngồi với nhau và nói về cách mình đã làm việc cùng nhau. Đây là cơ chế duy nhất trong Scrum mà mục tiêu thẳng thắn là: cải tiến chính bản thân team — con người, quy trình, công cụ, cách giao tiếp.
Nghe thì hay, nhưng thực tế đau lòng là phần lớn retro ở các công ty tech Việt Nam chết dần theo một trong hai kiểu. Kiểu thứ nhất: retro biến thành buổi than vãn — mọi người xả cho hết bực, rồi ai về chỗ nấy, tuần sau lặp lại y hệt. Kiểu thứ hai: retro biến thành buổi im lặng lịch sự — không ai dám nói thật vì sếp ngồi đó, hoặc vì "nói ra cũng chẳng thay đổi được gì". Cả hai kiểu đều dẫn đến cùng một kết cục: team ngừng đến retro với tinh thần nghiêm túc, và một công cụ cải tiến mạnh mẽ trở thành thủ tục hành chính 30 phút cuối sprint.
Điểm mấu chốt mà bài này muốn bạn nắm: retro không phải là một cuộc họp, nó là một bài toán giao tiếp. Chất lượng của retro không nằm ở template bạn dùng, mà nằm ở việc mọi người có dám nói thật, có nói theo cách xây dựng thay vì đổ lỗi, và có biến lời nói thành hành động hay không. Bài này tập trung riêng vào khía cạnh giao tiếp của retro — điều làm nên khác biệt giữa một team học được và một team dậm chân tại chỗ. (Lưu ý: các cuộc họp khác như standup ở Bài 15, sprint review ở Bài 16, hay blameless postmortem ở Bài 24 có bài riêng — retro có mục đích và nhịp riêng, đừng nhầm lẫn.)
Khái niệm cốt lõi
Mục đích thật của retro: continuous improvement, không phải blame
Retro tồn tại để phục vụ một mục tiêu duy nhất: cải tiến liên tục (continuous improvement) — làm sao để quy trình và cách làm việc của team tốt hơn một chút sau mỗi sprint. Từ khóa là "một chút". Retro không phải nơi giải quyết mọi vấn đề của vũ trụ, mà là nơi team chọn ra một vài điểm để chỉnh, thử trong sprint tới, rồi đánh giá lại.
Điều quan trọng nhất về mặt giao tiếp: retro không phải blame session (buổi truy trách nhiệm). Nếu retro trở thành nơi tìm xem "ai làm hỏng", mọi người sẽ lập tức chuyển sang chế độ phòng thủ. Và khi người ta phòng thủ, họ ngừng nói thật. Retro không có tâm lý an toàn (psychological safety) thì chỉ còn là cái vỏ.
Ba trụ cột giao tiếp làm nên retro tốt
1. An toàn tâm lý (psychological safety). Đây là nền móng. Team phải tin rằng nói ra một sai sót, một bất đồng, hay một lời chê quy trình sẽ không bị trừng phạt. Nhà nghiên cứu Amy Edmondson (Harvard) đưa ra khái niệm này, và Google trong dự án Project Aristotle đã kết luận đây là yếu tố số một tạo nên team hiệu quả. Không có nó, retro chỉ toàn lời sáo rỗng.
2. Ngôn ngữ tập trung vào hệ thống, không vào con người. Cùng một vấn đề có thể được nói theo hai cách. "Anh Tú toàn merge code khi chưa ai review" — đây là công kích cá nhân, người nghe sẽ chống lại. "Chúng ta chưa có quy ước về việc bắt buộc bao nhiêu approval trước khi merge, nên đôi khi code vào main mà chưa được review" — đây là mô tả hệ thống, cả team cùng nhìn vào vấn đề chứ không nhìn vào một người. Kỹ năng viết lại câu từ "con người" sang "hệ thống" là kỹ năng giao tiếp cốt lõi của retro.
3. Từ nói sang làm (action items). Retro mà không đẻ ra action item cụ thể, có người chịu trách nhiệm (owner) và có thời hạn, thì chỉ là buổi trò chuyện. Cách bạn đóng gói kết luận thành hành động — rõ ràng, đo được, ít nhưng chất — quyết định retro có giá trị thật hay không.
Các format phổ biến
Không có format "đúng" tuyệt đối; mỗi format là một cấu trúc câu hỏi để dẫn dắt cuộc trò chuyện. Chọn format tùy tâm trạng team và vấn đề cần soi.
Start / Stop / Continue. Format kinh điển, dễ nhất cho team mới. Ba câu hỏi: chúng ta nên bắt đầu làm gì (Start), nên ngừng làm gì (Stop), nên tiếp tục làm gì (Continue). Ưu điểm: đơn giản, hướng thẳng đến hành động. Nhược điểm: dễ bỏ sót cảm xúc, chuyện tốt-xấu.
Mad / Sad / Glad. Tập trung vào cảm xúc: điều gì khiến bạn bực (Mad), buồn/thất vọng (Sad), vui/hài lòng (Glad). Hợp khi team vừa trải qua sprint nhiều căng thẳng và cần xả cảm xúc trước khi phân tích lý trí.
4Ls: Liked / Learned / Lacked / Longed for. Cân bằng giữa trải nghiệm tích cực (Liked), bài học (Learned), thứ còn thiếu (Lacked) và thứ mình ao ước có (Longed for). Tốt cho team đã chín, muốn phản tư sâu hơn.
Sailboat (Thuyền buồm). Một ẩn dụ trực quan: gió (điều đẩy ta tiến), mỏ neo (điều kéo ta chậm lại), đá ngầm (rủi ro phía trước), hòn đảo (mục tiêu). Hợp cho retro cuối quý hoặc khi team cần nhìn xa hơn một sprint.
Mẹo quan trọng: đừng dùng mãi một format. Team dùng Start/Stop/Continue suốt 10 sprint sẽ trả lời theo quán tính, câu trả lời nhạt dần. Thay đổi format định kỳ giữ cho não team tỉnh táo và soi vấn đề từ góc mới.
Vai trò của người điều phối (facilitator)
Retro cần một người dẫn — thường là Scrum Master, nhưng có thể luân phiên. Nhiệm vụ facilitator không phải là nói nhiều nhất, mà là tạo không gian để người khác nói: đặt câu hỏi mở, kéo người im lặng vào cuộc, chặn người nói lấn át, giữ cuộc họp đúng giờ, và đảm bảo kết thúc bằng action item. Một facilitator giỏi nói ít nhưng cuộc họp lại đầy tiếng nói của mọi người.
Tình huống thực tế
Tình huống 1 — Team ở Tiki: khi retro thành buổi than vãn không lối thoát
Một squad backend gồm 7 người tại một công ty thương mại điện tử lớn ở TP.HCM (bối cảnh giả định dựa trên môi trường kiểu Tiki/Shopee) chạy retro mỗi hai tuần. Trong ba sprint liên tiếp, cùng một câu than xuất hiện: "QA trả bug quá trễ, gần cuối sprint mới báo, dev không kịp fix." Mọi người gật gù đồng ý, ai cũng bực, buổi retro sôi nổi. Nhưng rồi kết thúc mà không ai ghi lại thành hành động cụ thể. Sprint sau, đúng vấn đề đó quay lại.
Diễn giải: Đây là "retro than vãn" điển hình. Việc nói ra vấn đề tạo cảm giác nhẹ nhõm giả tạo — team tưởng mình đã giải quyết vì đã nói. Nhưng nói không phải làm. Không có owner, không có thay đổi quy trình, nên hệ thống đứng yên. Facilitator (một bạn Scrum Master mới) mắc lỗi: để cuộc họp trôi theo cảm xúc mà không lái về hành động.
Ở sprint thứ tư, một bạn senior đề nghị đổi cách: sau khi than xong, mỗi vấn đề phải biến thành một thử nghiệm cụ thể. Kết quả retro đó: "Thử nghiệm sprint tới — QA bắt đầu test từng feature ngay khi dev báo 'done' thay vì đợi cuối sprint; anh Minh (QA lead) là owner; đánh giá lại vào retro sau." Chỉ một action item, có owner, có tiêu chí. Sprint sau đó, số bug phát hiện muộn giảm rõ, và quan trọng hơn, team tin lại vào retro.
Bài học: Than vãn có giá trị như bước chẩn đoán, nhưng phải kết thúc bằng đúng một điều — hành động cụ thể, có người chịu trách nhiệm. Retro không đẻ ra action thì retro thất bại, dù buổi họp có sôi nổi đến đâu.
Tình huống 2 — Startup fintech ở Singapore: khi sếp ngồi trong phòng làm mọi người câm
Một startup fintech giai đoạn Series A ở Singapore có team engineering 12 người. Retro luôn có mặt Engineering Manager và đôi khi cả CTO. Facilitator hỏi "Sprint này có gì chưa ổn?" — im lặng vài giây, rồi vài lời chung chung kiểu "chắc estimate hơi lạc quan". Không ai đụng đến vấn đề thật: EM liên tục nhảy vào giữa sprint thêm task gấp, phá vỡ kế hoạch. Nhưng nói điều đó trước mặt chính EM? Không ai dám.
Diễn giải: Đây là vấn đề an toàn tâm lý. Sự hiện diện của người có quyền lực (manager, sếp) và cấu trúc báo cáo khiến IC (individual contributor) tự kiểm duyệt. Vấn đề gốc — chính EM đang phá vỡ sprint — lại là thứ không thể nói ra khi EM ngồi đó.
Team đã thử hai cách chữa. Thứ nhất, dùng công cụ ẩn danh (họ dùng EasyRetro, một web app cho phép đóng góp ẩn danh) để mọi người viết ra vấn đề trước, rồi thảo luận trên các note đã gom nhóm mà không lộ ai viết. Vấn đề "task gấp chen ngang" xuất hiện ngay lập tức với nhiều phiếu đồng tình. Thứ hai, họ thỏa thuận một quy tắc mới: một tháng một lần, retro chỉ có IC, không có manager; Scrum Master tổng hợp và trình bày lại các điểm với EM sau, ở dạng phi cá nhân.
Nhờ đó, EM lần đầu nhận ra tác động của việc chen task, và team thống nhất một "budget" cho việc chen ngang: tối đa 20% capacity mỗi sprint dành cho việc gấp, quá thì phải đánh đổi bằng scope đã cam kết.
Bài học: Khi cấu trúc quyền lực chặn lời nói thật, đừng ép người ta "dũng cảm hơn" — hãy thiết kế lại không gian giao tiếp: ẩn danh, tách nhóm, hoặc để facilitator làm trung gian. An toàn tâm lý là thứ phải được thiết kế, không phải chỉ hô hào.
Tình huống 3 — Team remote xuyên múi giờ: retro bất đồng bộ
Một công ty product có team phân tán: 5 dev ở Hà Nội, 2 ở Đà Nẵng, và 1 tech lead ở Berlin (lệch 5–6 tiếng). Retro sync qua video cứ rơi vào cảnh: người ở Berlin thì đang giữa buổi sáng tỉnh táo, người Việt Nam thì cuối ngày mệt, và chênh múi giờ khiến việc tìm khung giờ chung đã khó. Chất lượng thảo luận kém, vài người tắt camera và im lặng.
Diễn giải: Retro vốn cần sự hiện diện và cảm xúc, nhưng bối cảnh remote xuyên múi giờ làm suy yếu điều đó. Team quyết định tách retro thành hai pha. Pha bất đồng bộ (async): 24 giờ trước buổi họp, mọi người viết note vào một board Miro chung theo format 4Ls, tùy giờ giấc của mình, kèm bình luận vào note của người khác. Pha đồng bộ (sync) ngắn 30 phút: chỉ dùng để thảo luận các cụm note nóng nhất và chốt action item — không tốn thời gian gõ note tại chỗ.
Kết quả: buổi sync ngắn hơn, tập trung hơn, và người viết chậm hoặc ngại nói trực tiếp lại đóng góp tốt hơn qua văn bản. Số action item chốt được mỗi retro tăng, và không ai phải thức khuya viết note trong lúc đầu óc mụ mị.
Bài học: Định dạng retro phải thích nghi với bối cảnh giao tiếp của team. Với team phân tán, tách "thu thập ý kiến" (async) khỏi "ra quyết định" (sync ngắn) là một mô hình cực kỳ hiệu quả.
Hướng dẫn từng bước
Một retro tốt có nhịp năm bước. Aaron & Diana Larsen trong sách Agile Retrospectives gọi đây là khung năm pha; dưới đây là phiên bản thực dụng cho một retro 60 phút.
Bước 1 — Set the stage (2–5 phút): mở màn, tạo an toàn. Facilitator mở đầu bằng cách nhắc lại mục đích: đây là buổi cải tiến, không phải truy trách nhiệm. Một câu "prime directive" kinh điển đáng đọc to: "Bất kể ta khám phá được gì, ta tin rằng mọi người đã làm tốt nhất có thể với thông tin, kỹ năng và nguồn lực họ có lúc đó." Câu này đặt tông không đổ lỗi cho cả buổi. Có thể mở bằng một câu hỏi khởi động nhẹ để mọi người "lên tiếng" sớm — người đã nói một lần dễ nói tiếp.
Bước 2 — Gather data (10–15 phút): thu thập dữ liệu. Dùng format đã chọn (Start/Stop/Continue, Mad/Sad/Glad, 4Ls...). Cho mọi người viết trước rồi mới chia sẻ (kỹ thuật silent writing) — điều này ngăn người nói to lấn át và giúp người hướng nội đóng góp. Với team remote, đây là lúc dùng board async.
Bước 3 — Generate insights (15–20 phút): tìm hiểu gốc rễ. Gom nhóm các note giống nhau, chọn ra vài chủ đề nóng nhất bằng cách bỏ phiếu (dot voting). Với chủ đề được chọn, đào sâu: hỏi "tại sao" nhiều lần (kỹ thuật 5 Whys) để xuống tận nguyên nhân gốc thay vì dừng ở triệu chứng. Đây là pha ngôn ngữ dễ trượt sang đổ lỗi nhất — facilitator phải liên tục lái từ "ai" sang "cái gì trong hệ thống".
Bước 4 — Decide what to do (10 phút): chốt hành động. Chọn 1–3 action item, không hơn. Mỗi item phải có: mô tả cụ thể, một owner đích danh, và cách biết là xong. Ít mà làm được tốt hơn nhiều mà bỏ đó. Đây là bước nhiều team bỏ quên và là lý do lớn nhất khiến retro vô dụng.
Bước 5 — Close (5 phút): đóng buổi. Đọc lại action item cho mọi người xác nhận. Có thể xin phản hồi nhanh về chính buổi retro ("retro hôm nay thế nào?") — bản thân retro cũng cần được cải tiến. Ghi action item vào nơi ai cũng thấy (đầu board sprint tới) và mở đầu retro kế tiếp bằng việc review các action item cũ — đây là vòng lặp khép kín biến retro thành cơ chế cải tiến thật.
Lỗi thường gặp & mẹo
Lỗi: retro không đẻ ra action item. Nói cho sướng rồi thôi. Mẹo: quy định cứng — không rời phòng khi chưa có ít nhất một action item với owner và tiêu chí hoàn thành.
Lỗi: nhồi 10 action item mỗi sprint. Team không có capacity thực hiện, tuần sau chẳng cái nào xong, mất niềm tin. Mẹo: giới hạn 1–3, ưu tiên cái tác động lớn nhất. Cải tiến là marathon, không phải sprint dọn dẹp.
Lỗi: ngôn ngữ đổ lỗi. "Tại anh X", "team QA yếu". Mẹo: luyện phản xạ viết lại sang hệ thống. Cứ nghe thấy một cái tên đi kèm lời chê, facilitator hỏi lại: "Vậy trong quy trình của mình, cái gì đã khiến điều đó xảy ra?"
Lỗi: sếp hoặc người nói to át cả phòng. Mẹo: silent writing trước, dot voting để chọn chủ đề (dân chủ hơn), và cân nhắc công cụ ẩn danh khi vấn đề nhạy cảm. Facilitator chủ động mời người im lặng: "Chị Lan, chị nhìn vấn đề này thế nào?"
Lỗi: dùng một format đến chán. Mẹo: đổi format 3–4 sprint một lần để giữ sự tươi mới.
Lỗi: không review action item cũ. Mẹo: luôn bắt đầu retro bằng "kỳ trước ta cam kết gì, đã làm được chưa?". Không có bước này, action item chỉ là lời hứa suông.
Lỗi: bỏ retro khi bận. "Sprint này gấp quá, bỏ retro nhé." Mẹo: chính sprint căng thẳng mới cần retro nhất. Rút ngắn thì được, bỏ hẳn thì không.
Bài tập thực hành
Bài 1 — Viết lại sang ngôn ngữ hệ thống. Lấy ba câu phàn nàn kiểu đổ lỗi cá nhân dưới đây và viết lại thành mô tả hệ thống, không nhắm vào ai:
- "Ông Nam toàn deploy thứ Sáu chiều rồi cuối tuần cả team phải fix."
- "Con QA không bao giờ test hết case."
- "Design giao mockup trễ nên tụi dev không kịp."
Bài 3 — Từ than vãn sang action. Trong retro gần nhất của bạn (hoặc tự dựng một tình huống), chọn một vấn đề được nêu. Viết nó thành action item chuẩn: mô tả cụ thể + owner + tiêu chí "biết là xong". Tự kiểm: nếu ai đó đọc item này 2 tuần sau, họ có biết chính xác cần làm gì và đã xong hay chưa không?
Bài 4 — Tự soi vai trò. Trong retro gần nhất, bạn nói nhiều hay ít? Bạn có từng công kích một cái tên thay vì mô tả hệ thống không? Viết ra một điều bạn sẽ làm khác trong retro tới để nâng chất lượng giao tiếp của cả nhóm.
Tóm tắt
Sprint Retrospective là cơ chế cải tiến liên tục của team — và về bản chất, nó là một bài toán giao tiếp chứ không phải một thủ tục. Ba trụ cột quyết định thành bại: an toàn tâm lý để người ta dám nói thật, ngôn ngữ hướng hệ thống thay vì đổ lỗi con người để cả nhóm cùng nhìn vào vấn đề, và hành động cụ thể có owner để lời nói biến thành thay đổi thật.
Chọn format (Start/Stop/Continue, Mad/Sad/Glad, 4Ls, Sailboat) tùy bối cảnh và đổi định kỳ để tránh nhàm chán. Chạy retro theo năm pha: mở màn tạo an toàn, thu thập dữ liệu, tìm gốc rễ, chốt 1–3 action item, và đóng buổi bằng cách ghi lại — rồi review chúng ở retro sau. Ba tình huống thực tế cho thấy: retro chết vì than vãn không action, vì quyền lực bịt miệng, hoặc vì bối cảnh remote không được thiết kế lại. Tránh những cái bẫy đó, và retro sẽ làm đúng việc của nó: giúp team giỏi hơn một chút sau mỗi sprint — cộng dồn lại thành một team học được thật sự.