Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng một đội bóng đá thi đấu 30 trận liên tiếp mà không bao giờ ngồi lại xem lại băng ghi hình, không phân tích tại sao thua, không rút kinh nghiệm. Họ sẽ lặp đi lặp lại cùng một sai lầm cho đến hết mùa giải. Nghe thật vô lý phải không? Vậy mà rất nhiều đội dự án phần mềm và đội vận hành ở Việt Nam đang làm đúng như thế: chạy sprint này qua sprint khác, gặp lại y nguyên những vấn đề cũ — build hỏng vào phút chót, requirement mơ hồ, code review dồn ứ cuối tuần — mà không bao giờ dừng lại để hỏi "tại sao chuyện này cứ tái diễn?".
Retrospective (viết tắt là "retro") chính là buổi "xem lại băng ghi hình" đó. Nó là một trong bốn sự kiện Scrum bắt buộc, nhưng ý nghĩa của nó vượt xa Scrum: đây là cơ chế học hỏi có chủ đích (deliberate learning) của một đội. Nếu Daily Standup trả lời "hôm nay ta làm gì", Sprint Review trả lời "ta đã giao được sản phẩm gì", thì Retrospective trả lời câu hỏi quan trọng nhất về mặt dài hạn: "cách chúng ta làm việc với nhau có tốt hơn được không, và bằng cách nào?".
Với vai trò một Project Manager hoặc Scrum Master, retro là công cụ mạnh nhất bạn có để xây dựng continuous improvement — cải tiến liên tục. Nó không đòi hỏi ngân sách, không cần phê duyệt từ cấp trên, không phụ thuộc công cụ đắt tiền. Chỉ cần 60–90 phút mỗi sprint và một tinh thần cầu thị. Trong bài này, chúng ta sẽ đi sâu vào bản chất của retro, các format phổ biến, cách điều phối một buổi retro thực sự tạo ra thay đổi (chứ không phải một buổi than vãn vô nghĩa), và cách biến các "bài học rút ra" thành hành động cụ thể được theo dõi đến cùng.
Khái niệm cốt lõi
Retrospective là gì và không phải là gì
Retrospective là buổi họp định kỳ, thường diễn ra vào cuối mỗi sprint (chu kỳ 1–2 tuần), nơi cả đội cùng nhìn lại quãng thời gian vừa qua để trả lời ba câu hỏi nền tảng: điều gì đã diễn ra tốt, điều gì chưa tốt, và chúng ta sẽ thay đổi gì ở sprint tới. Cốt lõi triết học của retro nằm ở hai từ trong Scrum: inspect (kiểm tra) + adapt (thích nghi). Đội tự soi chiếu chính quy trình làm việc của mình, rồi chủ động điều chỉnh nó.
Điều quan trọng cần phân biệt ngay từ đầu: retro không phải là Sprint Review. Sprint Review nói về sản phẩm — chúng ta đã build được feature gì, khách hàng phản hồi ra sao. Retro nói về quy trình và con người — cách chúng ta cộng tác, giao tiếp, xử lý công việc. Một buổi hay bị nhầm lẫn hai thứ này, và kết quả là retro biến thành buổi demo lần hai, còn phần cải tiến quy trình bị bỏ quên.
Retro cũng không phải phiên tòa để đổ lỗi. Nguyên tắc vàng của retro là Prime Directive (Chỉ thị Tối cao) do Norman Kerth đề xuất: "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 tốt nhất trong khả năng của họ, dựa trên kiến thức, kỹ năng và nguồn lực có được vào thời điểm đó." Nói cách khác, retro tấn công vấn đề, không tấn công con người. Một khi thành viên cảm thấy bị chỉ trích cá nhân, họ sẽ phòng thủ, không nói thật, và retro chết ngay từ trong trứng.
Tần suất và thời lượng
Retro diễn ra vào cuối mỗi sprint. Với sprint 2 tuần, thời lượng chuẩn là 90 phút; với sprint 1 tuần thì khoảng 45–60 phút. Đừng cắt xén thời gian này để "làm cho nhanh" — một retro làm vội chỉ tạo ra hành động hời hợt. Nhưng cũng đừng để nó lê thê quá 2 tiếng; sự tập trung sẽ tan biến và mọi người chỉ mong về chỗ.
Năm giai đoạn của một retro theo Derby & Larsen
Trong cuốn Agile Retrospectives, Esther Derby và Diana Larsen đề xuất một cấu trúc năm giai đoạn đã trở thành chuẩn mực toàn cầu. Đây là bộ khung xương của mọi buổi retro tốt:
- Set the Stage (Mở màn): tạo không khí an toàn, "check-in" để mọi người sẵn sàng nói thật. Ví dụ mỗi người nói một từ mô tả cảm giác về sprint vừa qua.
- Gather Data (Thu thập dữ liệu): cùng nhìn lại sprint một cách khách quan — sự kiện, số liệu, cảm xúc. Đây là lúc dùng các format như Mad/Sad/Glad hay timeline.
- Generate Insights (Tạo ra hiểu biết): đào sâu "tại sao" đằng sau dữ liệu. Kỹ thuật 5 Whys, nhóm các vấn đề tương tự lại.
- Decide What to Do (Quyết định hành động): chọn ra 1–3 hành động cải tiến cụ thể, có người phụ trách.
- Close the Retrospective (Kết thúc): tổng kết, đánh giá chính buổi retro, cảm ơn nhau.
Các format retro phổ biến
Điều tuyệt vời của retro là bạn có thể thay đổi format để tránh nhàm chán và khai thác các góc nhìn khác nhau. Vài format kinh điển:
- Start / Stop / Continue: đơn giản nhất — chúng ta nên bắt đầu làm gì, ngừng làm gì, tiếp tục làm gì. Rất tốt cho đội mới.
- Mad / Sad / Glad: khai thác cảm xúc — điều gì khiến bạn bực, buồn, vui. Giúp lộ ra những vấn đề "mềm" về tinh thần đội.
- 4 L's: Liked / Learned / Lacked / Longed for (thích / học được / thiếu / mong muốn).
- Sailboat / Speedboat: hình dung đội như một con thuyền — gió (điều thúc đẩy), mỏ neo (điều kìm hãm), đá ngầm (rủi ro phía trước), hòn đảo (mục tiêu). Rất trực quan và tạo cảm hứng.
- Starfish: More of / Less of / Keep doing / Start doing / Stop doing — chi tiết hơn Start/Stop/Continue.
Continuous Improvement — mục tiêu cuối cùng
Điểm cần khắc cốt: retro chỉ có giá trị khi nó dẫn tới thay đổi thực sự. Một retro tạo ra danh sách 10 vấn đề nhưng không có action item nào được thực hiện thì tệ hơn là không họp — vì nó dạy đội rằng "nói cũng vô ích". Đây gọi là retro theater — diễn kịch retro. Continuous improvement nghĩa là mỗi sprint, đội chọn một vài điểm cải tiến, thực thi, đo lường ở sprint sau, rồi lặp lại. Đó chính là vòng lặp Kaizen của người Nhật, áp dụng vào cách một đội làm việc.
Tình huống thực tế
Tình huống 1 — Đội của FPT Software và cái bẫy "retro chỉ than vãn"
Một đội 8 người tại một trung tâm phát triển của FPT Software ở Hà Nội, làm dự án outsource cho khách hàng Nhật, chạy sprint 2 tuần. Ba tháng đầu, họ retro đều đặn nhưng theo cách rất tệ: buổi họp biến thành nơi mọi người xả bức xúc — "requirement của khách mơ hồ quá", "QA test chậm", "build server hay sập". Ai cũng gật gù đồng ý, ghi vào bảng, rồi... không ai làm gì. Sprint sau, y nguyên những lời than đó lặp lại.
Scrum Master mới về nhận ra vấn đề: đội dừng ở giai đoạn "Gather Data" mà không bao giờ tiến tới "Decide What to Do". Anh áp dụng một quy tắc cứng: mỗi retro chỉ được chọn tối đa 2 action item, mỗi item phải có tên người phụ trách và deadline cụ thể, và đầu mỗi retro sau bắt buộc review lại action item kỳ trước.
Kết quả sau hai tháng: vấn đề "build server hay sập" được truy nguyên bằng 5 Whys, hóa ra do thiếu quy trình dọn dẹp môi trường CI — họ giao một dev viết script tự động, deadline một sprint, và vấn đề biến mất hẳn. Tỷ lệ build fail giảm từ khoảng 25% xuống dưới 5%.
Bài học: Retro không phải nơi để than, mà là nơi để biến than vãn thành hành động có người chịu trách nhiệm. Giới hạn số action item để đảm bảo chúng thực sự được làm.
Tình huống 2 — Startup fintech tại TP.HCM và retro "an toàn tâm lý"
Một startup fintech khoảng 20 kỹ sư ở Quận 1, TP.HCM. Đội backend có một vấn đề âm ỉ: các bạn junior không bao giờ dám nói thật trong retro vì tech lead là người rất giỏi nhưng hay ngắt lời và phản bác gay gắt. Retro trở thành buổi độc thoại của tech lead, còn junior chỉ ngồi im. Team lead sản phẩm nhận ra velocity đội cứ giảm dần mà không hiểu vì sao.
Họ thử một thay đổi nhỏ nhưng mạnh: chuyển sang thu thập ý kiến ẩn danh trước buổi họp qua một công cụ (họ dùng một bảng sticky note online), và đặt ra luật "tech lead nói cuối cùng, không ngắt lời khi người khác đang trình bày". Ngay retro đầu tiên áp dụng, một loạt vấn đề thật lộ ra: junior sợ hỏi vì bị chê "câu hỏi ngớ ngẩn", pull request bị block quá lâu vì chỉ tech lead được quyền approve.
Sau khi giải quyết (thêm reviewer thứ hai, lập kênh hỏi đáp không phán xét), trong ba sprint tiếp theo velocity phục hồi và tăng khoảng 20%, còn thời gian một PR nằm chờ giảm từ trung bình 2 ngày xuống nửa ngày.
Bài học: Psychological safety (an toàn tâm lý) là điều kiện tiên quyết của retro. Nếu người ta sợ nói thật, mọi format retro đều vô dụng. Thu thập ẩn danh và quy tắc điều phối rõ ràng là cách gỡ nút thắt này.
Tình huống 3 — Đội vận hành ngân hàng và retro cho công việc không phải phần mềm
Một phòng vận hành thẻ tại một ngân hàng thương mại cổ phần ở Việt Nam áp dụng retro cho công việc không hề "agile" theo nghĩa phần mềm — xử lý khiếu nại khách hàng. Họ vốn nghĩ retro chỉ dành cho dev. Nhưng trưởng phòng quyết định thử: cứ hai tuần một lần, cả đội 12 người ngồi lại 60 phút dùng format Sailboat để nhìn lại các ca khiếu nại khó.
Qua vài buổi, họ phát hiện một "mỏ neo" lớn: 40% các ca xử lý chậm là do phải chờ email xác nhận từ một phòng ban khác, mà email thường bị bỏ sót. Action item: thay email bằng một kênh chat chung với SLA phản hồi 4 giờ. Sau một tháng, thời gian xử lý trung bình một khiếu nại giảm từ 5 ngày xuống 3 ngày.
Bài học: Retro không độc quyền cho đội phần mềm. Bất kỳ đội nào làm việc lặp lại theo chu kỳ đều có thể dùng retro để cải tiến liên tục.
Hướng dẫn từng bước
Đây là quy trình cụ thể để bạn tự điều phối một buổi retro chất lượng:
Bước 1 — Chuẩn bị trước buổi họp (15 phút). Chọn format phù hợp với tâm trạng đội và vấn đề đang nổi cộm. Đội căng thẳng thì dùng Mad/Sad/Glad; đội cần định hướng thì dùng Sailboat. Chuẩn bị công cụ (bảng vật lý với sticky note, hoặc bảng online như Miro/FigJam nếu remote). Gửi lời nhắc và review lại action item của retro trước.
Bước 2 — Set the Stage (5–10 phút). Mở đầu bằng một câu check-in nhẹ nhàng để mọi người "vào cuộc": mỗi người nói một từ về sprint. Nhắc lại Prime Directive để định khung không đổ lỗi.
Bước 3 — Gather Data (15–20 phút). Mỗi người viết ý kiến của mình lên sticky note theo các cột của format đã chọn. Cho mọi người viết trong im lặng trước (để tránh bị chi phối bởi người nói to nhất), rồi lần lượt dán và giải thích.
Bước 4 — Generate Insights (20 phút). Nhóm các note giống nhau lại thành cụm. Với 2–3 cụm quan trọng nhất, đào sâu bằng 5 Whys: hỏi "tại sao" liên tiếp năm lần để chạm tới nguyên nhân gốc rễ thay vì triệu chứng bề mặt. Có thể dùng dot voting — mỗi người có 3 dấu chấm để bỏ phiếu cho vấn đề họ thấy quan trọng nhất.
Bước 5 — Decide What to Do (15 phút). Chọn tối đa 1–3 action item từ các vấn đề được vote cao nhất. Mỗi item phải theo tiêu chí SMART: cụ thể, có người phụ trách (owner), có deadline. Ghi rõ "Ai làm gì, xong khi nào".
Bước 6 — Close (5 phút). Tóm tắt các action item. Làm một vòng "ROTI" (Return on Time Invested) — mỗi người giơ 1–5 ngón tay đánh giá buổi retro có đáng thời gian không. Cảm ơn cả đội.
Bước 7 — Theo dõi giữa sprint. Đưa action item vào backlog hoặc board như một task thật sự, không để nó nằm quên trong biên bản. Đây là bước quyết định retro có tạo ra thay đổi hay không.
Lỗi thường gặp & mẹo
Lỗi 1 — Retro không có action item hoặc quá nhiều action item. Không có gì để làm thì vô nghĩa; mười item thì không cái nào được làm. Mẹo: giới hạn cứng 1–3 action item mỗi sprint.
Lỗi 2 — Không theo dõi action item kỳ trước. Đây là lỗi giết chết retro phổ biến nhất. Mẹo: biến việc review action item cũ thành nghi thức bắt buộc mở đầu mỗi retro.
Lỗi 3 — Biến retro thành phiên đổ lỗi. Khi có ai đó bị chỉ trực tiếp, cả đội đóng cửa. Mẹo: luôn nhắc Prime Directive; điều phối viên phải chuyển câu "anh A làm sai" thành "quy trình của chúng ta thiếu gì khiến việc đó xảy ra".
Lỗi 4 — Dùng mãi một format. Sau 5–6 sprint cùng Start/Stop/Continue, mọi người trả lời như cái máy. Mẹo: luân phiên format để làm mới góc nhìn.
Lỗi 5 — Sếp/tech lead áp đảo buổi họp. Mẹo: thu thập ý kiến ẩn danh và im lặng viết trước, đặt luật người có quyền lực nói sau cùng.
Lỗi 6 — Bỏ qua điều tốt, chỉ soi điều xấu. Ghi nhận thành công cũng quan trọng để biết cái gì nên giữ lại. Mẹo: luôn có một cột dành cho "điều đã tốt".
Lỗi 7 — Retro trở thành hình thức khi làm remote. Camera tắt, ai cũng làm việc riêng. Mẹo: dùng bảng tương tác online buộc mọi người phải gõ, phải vote — không thể ngồi im.
Bài tập thực hành
Bài 1 — Tự điều phối một retro. Với đội của bạn (hoặc một nhóm học tập giả định 5 người), tổ chức một buổi retro 60 phút dùng format Sailboat. Viết ra: gió, mỏ neo, đá ngầm, hòn đảo mà cả nhóm nêu ra. Sau đó chọn đúng 2 action item với owner và deadline.
Bài 2 — Luyện 5 Whys. Lấy một vấn đề thật gần đây (ví dụ "sprint vừa rồi trễ 2 ngày"). Viết ra chuỗi 5 câu hỏi "tại sao" liên tiếp để tìm nguyên nhân gốc. So sánh nguyên nhân gốc bạn tìm được với "triệu chứng" ban đầu — chúng có khác nhau không?
Bài 3 — Thiết kế cơ chế theo dõi. Đề xuất một cách cụ thể để đảm bảo action item từ retro không bị lãng quên (ví dụ: đưa vào board dưới nhãn riêng, review đầu mỗi retro). Mô tả nó thành một quy trình 3 bước.
Bài 4 — Phân tích ROTI. Sau buổi retro gần nhất bạn tham gia, tự chấm ROTI từ 1–5 và viết một đoạn ngắn giải thích: điều gì khiến buổi đó đáng (hoặc không đáng) thời gian, và bạn sẽ thay đổi gì lần sau.
Tóm tắt
Retrospective là cơ chế học hỏi có chủ đích của một đội — buổi "xem lại băng ghi hình" giúp đội tự soi chiếu và cải tiến cách làm việc. Bản chất của nó nằm ở nguyên tắc inspect + adapt: kiểm tra chính quy trình của mình rồi chủ động thích nghi.
Những điểm cần nhớ:
- Retro diễn ra cuối mỗi sprint, kéo dài 45–90 phút tùy độ dài sprint, và tập trung vào quy trình và con người, không phải sản phẩm (đó là việc của Sprint Review).
- Cấu trúc chuẩn năm giai đoạn của Derby & Larsen: Set the Stage → Gather Data → Generate Insights → Decide What to Do → Close.
- Psychological safety và Prime Directive là nền tảng: tấn công vấn đề, không tấn công con người.
- Giá trị thực của retro nằm ở action item được thực thi và theo dõi đến cùng — giới hạn 1–3 item, có owner và deadline, review lại ở retro sau. Không có bước này, retro chỉ là kịch.
- Luân phiên các format (Start/Stop/Continue, Sailboat, Mad/Sad/Glad, Starfish...) để giữ buổi họp tươi mới.