Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng đội của bạn vừa hoàn thành một sprint hai tuần đầy mệt mỏi. Deadline suýt trễ, có hai bug nghiêm trọng lọt ra production, và một bạn dev phải thức đến nửa đêm để cứu vãn. Sprint kết thúc, mọi người thở phào, rồi... lao ngay vào sprint tiếp theo. Y hệt như cũ. Rồi tháng sau lại lặp lại đúng những sai lầm đó.
Đây là bi kịch phổ biến nhất của các đội chưa trưởng thành: họ làm việc rất chăm chỉ nhưng không bao giờ dừng lại để học từ chính công việc của mình. Họ chạy nhanh nhưng chạy vòng tròn.
Retrospective — hay còn gọi tắt là "retro" — chính là cơ chế giúp đội thoát khỏi vòng lặp đó. Đây là buổi họp định kỳ nơi cả đội cùng nhìn lại một giai đoạn làm việc, thành thật hỏi: "Điều gì tốt? Điều gì chưa ổn? Chúng ta sẽ thay đổi cái gì?" — rồi cam kết hành động cụ thể.
Với bạn — một manager lần đầu — retro là một trong những công cụ đòn bẩy mạnh nhất bạn có. Nó không đòi hỏi ngân sách, không cần công nghệ, không cần ai phê duyệt. Nhưng nếu làm đúng, nó biến đội của bạn thành một cỗ máy tự cải tiến (continuous improvement) — mỗi chu kỳ lại tốt hơn chu kỳ trước một chút. Sau một năm, sự khác biệt giữa một đội chạy retro nghiêm túc và một đội không có là khoảng cách một trời một vực.
Trong bài này, chúng ta sẽ đi sâu vào ba nhịp độ (cadence) retro khác nhau, cách chạy một buổi retro thực sự tạo ra thay đổi, và những cái bẫy khiến retro biến thành buổi "than thở tập thể" vô nghĩa.
Khái niệm cốt lõi
Retro không phải là báo cáo tiến độ, cũng không phải là buổi trách móc
Điều đầu tiên bạn cần khắc cốt ghi tâm: retro nhìn về quá trình làm việc, không phải về kết quả công việc. Nó không phải là chỗ để bạn hỏi "Task X xong chưa?" (đó là standup — Bài 36) hay đánh giá cá nhân ai làm tốt ai làm dở (đó là performance review — Bài 23). Retro hỏi: "Cách chúng ta làm việc với nhau đang vận hành thế nào, và làm sao để tốt hơn?"
Nguyên tắc nền tảng là Prime Directive (chỉ thị tối thượng) của Norm Kerth, được đọc gần như một lời tuyên thệ ở đầu nhiề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 trong khả năng của họ, với thông tin họ có, kỹ năng họ có, nguồn lực sẵn có và hoàn cảnh lúc đó."
Câu này rất quan trọng vì nó tách vấn đề khỏi con người. Khi một bug lọt ra production, ta không hỏi "Ai gây ra?" mà hỏi "Quy trình nào của chúng ta đã cho phép bug này lọt qua?". Đây là tinh thần "blameless" (không đổ lỗi) — điều kiện tiên quyết để mọi người dám nói thật.
Ba nhịp độ retro
Không phải retro nào cũng giống nhau. Tùy theo tầm nhìn và mức độ, bạn sẽ chạy ba loại với ba nhịp độ khác nhau:
1. Sprint retro — hai tuần một lần, ngay sau mỗi sprint. Đây là loại phổ biến và quan trọng nhất với một team. Phạm vi hẹp: nhìn lại đúng hai tuần vừa qua. Câu hỏi xoay quanh quy trình vận hành hàng ngày: giao tiếp, công cụ, ước lượng thời gian, cách chia task, các cản trở nhỏ. Buổi này nên gọn — 60 đến 90 phút — và cho ra một vài hành động cải tiến nhỏ, có thể thực hiện ngay trong sprint sau.
2. Project retro — sau mỗi lần ra mắt lớn (major launch). Khi đội vừa hoàn thành một dự án lớn kéo dài nhiều tuần hoặc nhiều tháng — ra mắt một tính năng lớn, một sản phẩm mới, một chiến dịch — bạn cần một retro có tầm nhìn rộng hơn. Phạm vi ở đây là toàn bộ vòng đời dự án: từ lúc lên kế hoạch, phân bổ nguồn lực, các quyết định kiến trúc, phối hợp liên phòng ban, cho tới lúc go-live. Buổi này thường dài hơn (nửa ngày), có nhiều bên tham gia hơn (không chỉ engineering mà cả product, design, đôi khi cả marketing/sales), và tập trung vào những bài học ở tầm chiến lược.
3. Quarterly retro — mỗi quý một lần, ở tầm tổ chức/nhóm lớn. Đây là retro ở độ cao nhất (high-level). Nó không soi vào từng task mà nhìn vào các xu hướng (trends) trong cả quý: Đội có đang bị burnout không? Nhịp độ ship có ổn định không? Có vấn đề nào lặp đi lặp lại qua nhiều sprint mà chưa được giải quyết tận gốc? Văn hóa đội đang tiến hay lùi? Quarterly retro là nơi bạn với tư cách manager phát hiện các vấn đề mang tính hệ thống mà một sprint retro đơn lẻ không nhìn thấy được.
Một cách hình dung dễ nhớ: sprint retro là kính hiển vi, project retro là kính lúp, quarterly retro là kính viễn vọng. Bạn cần cả ba để nhìn rõ ở mọi tầm.
Cấu trúc chung của một buổi retro
Dù ở nhịp độ nào, một buổi retro tốt đều đi qua năm giai đoạn kinh điển (theo cuốn Agile Retrospectives của Esther Derby và Diana Larsen):
- Set the stage — mở màn, tạo không khí an toàn, đọc Prime Directive.
- Gather data — thu thập dữ liệu và cảm nhận: điều gì đã xảy ra?
- Generate insights — đào sâu tìm nguyên nhân gốc: vì sao lại như vậy?
- Decide what to do — chọn ra 1–3 hành động cụ thể để thay đổi.
- Close — chốt lại, giao chủ trách nhiệm, và... làm retro về chính buổi retro.
Tình huống thực tế
Tình huống 1 — Đội startup fintech ở TP.HCM và cái bẫy "than thở"
Một startup ví điện tử tại Quận 1, TP.HCM, có đội engineering 8 người. Manager mới — anh Tuấn, vừa lên từ senior dev — bắt đầu chạy sprint retro hai tuần một lần vì "sách bảo phải làm". Nhưng ba tháng trôi qua, không khí buổi retro ngày càng nặng nề. Mỗi buổi biến thành nơi mọi người kể lể: "QA chậm quá", "Yêu cầu từ product thay đổi liên tục", "Server dev hay sập". Ai cũng gật gù đồng cảm, rồi... về. Sprint sau lặp lại y hệt.
Đến quý thứ hai, một bạn dev thẳng thắn nói: "Em thấy retro chỉ tổ mất một tiếng rưỡi, chả giải quyết được gì." Anh Tuấn giật mình nhận ra vấn đề: đội của anh gather data rất giỏi (kể khổ), nhưng bỏ hoàn toàn bước decide what to do. Không có hành động nào được ghi ra, không ai chịu trách nhiệm, không ai theo dõi.
Anh thay đổi một điều duy nhất: mỗi buổi retro phải kết thúc bằng tối đa 3 hành động, mỗi hành động có tên một người chịu trách nhiệm và một hạn hoàn thành. Và buổi retro tiếp theo luôn bắt đầu bằng việc kiểm tra 3 hành động của lần trước. Ví dụ, từ than phiền "server dev hay sập", họ chốt hành động: "Nam viết script tự động restart và cảnh báo Telegram, xong trước thứ Sáu." Ba sprint sau, server không còn là chủ đề than thở nữa.
Bài học: Retro mà không đẻ ra hành động cụ thể có người chịu trách nhiệm thì chỉ là buổi trút giận tập thể. Chính việc theo dõi hành động ở đầu buổi sau mới tạo ra vòng lặp cải tiến thật sự.
Tình huống 2 — Project retro sau một lần ra mắt vấp ngã tại một công ty e-commerce
Một công ty thương mại điện tử ở Hà Nội (tạm gọi là ShopViet) vừa ra mắt tính năng "mua trước trả sau" sau ba tháng phát triển. Ngày go-live, hệ thống quá tải, tỷ lệ giao dịch lỗi lên tới 18% trong 4 giờ đầu, và đội phải rollback. Một thất bại đau đớn.
Chị Hà — engineering manager — biết rằng nếu tổ chức retro sai cách, buổi họp sẽ biến thành phiên tòa và người ta sẽ chỉ tay vào bạn dev đã viết phần xử lý thanh toán. Chị mở đầu bằng Prime Directive và đặt luật rõ: "Hôm nay chúng ta tìm lỗ hổng trong quy trình, không tìm người có lỗi."
Đội dùng kỹ thuật 5 Whys (hỏi "tại sao" năm lần) để đào tới gốc:
- Vì sao giao dịch lỗi? Vì database quá tải.
- Vì sao quá tải? Vì lượng truy cập cao gấp 5 lần dự tính.
- Vì sao dự tính sai? Vì marketing đẩy chiến dịch quảng cáo mà engineering không biết.
- Vì sao engineering không biết? Vì không có kênh trao đổi giữa hai đội trước launch.
- Vì sao không có kênh đó? Vì công ty chưa bao giờ định nghĩa quy trình "launch readiness" liên phòng ban.
Bài học: Project retro có sức mạnh phát hiện vấn đề hệ thống mà sprint retro không thấy được. Và 5 Whys giúp bạn đi từ triệu chứng bề mặt xuống tận nguyên nhân gốc.
Tình huống 3 — Quarterly retro phát hiện dấu hiệu burnout ẩn
Một đội sản phẩm 12 người tại chi nhánh Đông Nam Á của một công ty SaaS (đặt tại Singapore, có team ở Việt Nam) chạy sprint retro đều đặn và mọi thứ nhìn bề ngoài đều ổn. Velocity cao, ship đều. Nhưng khi manager — anh Đức — chạy quarterly retro, anh vẽ ra một biểu đồ đơn giản: số lần "overtime" và số ngày nghỉ phép của cả đội qua từng sprint trong quý.
Bức tranh gây sốc: velocity cao là nhờ đội liên tục làm thêm giờ, và không ai dám nghỉ phép. Từng sprint retro riêng lẻ không lộ ra điều này, vì mỗi sprint chỉ hơi mệt một chút — nhưng cộng dồn cả quý thì đó là con đường thẳng tới burnout (chủ đề Bài 39). Quarterly retro với tầm nhìn xu hướng đã bắt được tín hiệu mà kính hiển vi sprint bỏ lỡ.
Hành động ở tầm này cũng mang tính hệ thống: đội cam kết giảm 20% khối lượng cam kết mỗi sprint để tạo đệm, và anh Đức đặt ra "no-overtime week" mỗi tháng.
Bài học: Ba nhịp độ retro nhìn thấy những thứ khác nhau. Đừng bỏ quarterly retro chỉ vì sprint retro đang "chạy tốt" — một số vấn đề chỉ hiện ra ở tầm cao.
Hướng dẫn từng bước
Dưới đây là quy trình chạy một buổi sprint retro 75 phút. Bạn có thể mở rộng cho project/quarterly retro bằng cách kéo dài từng bước.
Bước 1 — Chuẩn bị trước buổi họp (15 phút của riêng bạn). Gom sẵn dữ liệu: velocity của sprint, số bug, các sự cố, các hành động từ retro trước. Chọn định dạng (format) cho buổi họp — đừng dùng mãi một format vì đội sẽ chán. Vài format kinh điển: Start / Stop / Continue (nên bắt đầu / nên dừng / nên tiếp tục làm gì); Mad / Sad / Glad (thiên về cảm xúc); 4Ls — Liked / Learned / Lacked / Longed for; hoặc Sailboat (điều gì là gió đẩy ta đi, điều gì là mỏ neo kéo lại).
Bước 2 — Set the stage (5 phút). Đọc Prime Directive. Nhắc lại rằng đây là không gian an toàn, không đổ lỗi. Với đội Việt Nam vốn ngại nói thẳng trước sếp, bạn có thể mở đầu bằng một câu hỏi nhẹ để mọi người "khởi động miệng", ví dụ: "Một từ mô tả sprint vừa rồi của bạn?".
Bước 3 — Gather data (15 phút). Cho mọi người viết ý kiến vào note (giấy dán hoặc công cụ như Miro, FigJam) theo format đã chọn — viết im lặng, riêng lẻ trước, để tránh việc người nói to lấn át người rụt rè. Sau đó dán lên và nhóm các note giống nhau lại.
Bước 4 — Generate insights (20 phút). Chọn 2–3 chủ đề nổi cộm nhất (dùng bỏ phiếu chấm điểm — mỗi người 3 phiếu). Đào sâu bằng 5 Whys cho từng chủ đề để tìm nguyên nhân gốc, thay vì dừng ở triệu chứng.
Bước 5 — Decide what to do (15 phút). Đây là bước quan trọng nhất, đừng bỏ. Với mỗi nguyên nhân gốc, chốt tối đa 3 hành động cho toàn buổi. Mỗi hành động phải theo tinh thần SMART: cụ thể, có người chịu trách nhiệm (owner), có deadline. Viết ra chỗ ai cũng thấy.
Bước 6 — Close (5 phút). Tóm tắt các hành động và người chịu trách nhiệm. Hỏi nhanh: "Buổi retro hôm nay có gì mình nên làm khác lần sau không?" (retro về retro). Cảm ơn mọi người.
Bước 7 — Theo dõi (giữa các sprint). Đưa các hành động vào backlog/board như task thật. Và luôn mở đầu retro sau bằng việc kiểm tra kết quả các hành động lần trước. Đây là mắt xích khép kín vòng lặp cải tiến liên tục.
Lỗi thường gặp & mẹo
Lỗi 1 — Biến retro thành buổi than thở không lối thoát. Đã phân tích ở Tình huống 1. Cách chữa: luôn kết thúc bằng hành động cụ thể có owner và deadline.
Lỗi 2 — Ra quá nhiều hành động. Một đội hào hứng đẻ ra 12 hành động sau một buổi retro. Kết quả: không cái nào được làm. Mẹo: giới hạn cứng tối đa 3. Thà làm xong 2 việc còn hơn bỏ dở 12.
Lỗi 3 — Manager nói nhiều nhất. Nếu bạn — người có quyền lực trong phòng — nói trước và nói nhiều, mọi người sẽ chỉ phụ họa. Mẹo: bạn nói sau cùng, hoặc tốt hơn, giao vai trò điều phối (facilitator) luân phiên cho các thành viên. Trong văn hóa Việt Nam vốn tôn trọng cấp bậc (Bài 59), điều này càng quan trọng — sự im lặng của bạn tạo khoảng trống cho người khác lên tiếng.
Lỗi 4 — Đổ lỗi cá nhân. Một khi ai đó bị chỉ mặt, tất cả những người còn lại sẽ đóng cửa lòng và retro chết ngay lập tức. Mẹo: khi thảo luận trượt sang "tại bạn X", hãy nhẹ nhàng lái lại: "Ta hãy hỏi quy trình nào cho phép điều đó xảy ra."
Lỗi 5 — Dùng mãi một format. Đội sẽ chán và trả lời cho có. Mẹo: luân phiên Start/Stop/Continue, Sailboat, 4Ls, Mad/Sad/Glad.
Lỗi 6 — Bỏ retro khi bận. Nghịch lý: sprint càng hỗn loạn, đội càng cần retro, nhưng đó lại là lúc người ta hay hủy nó nhất. Mẹo: coi retro là bất khả xâm phạm — chính những sprint tệ mới có nhiều bài học nhất.
Mẹo cho remote team: Với đội làm việc từ xa hoặc hybrid (Bài 42), dùng công cụ như Miro/FigJam, bật cả video, và cho viết note im lặng đồng thời để mọi người đều có tiếng nói bình đẳng.
Bài tập thực hành
- Thiết kế retro đầu tiên của bạn. Chọn một format (gợi ý: Start/Stop/Continue cho lần đầu vì dễ nhất). Viết ra lịch trình 75 phút theo 6 bước ở trên, kèm thời lượng từng phần.
- Luyện 5 Whys. Lấy một vấn đề có thật của đội bạn trong tháng qua (ví dụ: "một task ước lượng 2 ngày nhưng làm mất 6 ngày"). Tự hỏi "tại sao" năm lần liên tiếp cho tới khi chạm nguyên nhân gốc. Bạn có bất ngờ với gốc rễ tìm được không?
- Chọn cadence phù hợp. Nhìn vào lịch làm việc quý tới của đội. Đánh dấu: khi nào chạy sprint retro (các mốc hai tuần), có major launch nào cần project retro không, và đặt lịch một quarterly retro cuối quý.
- Audit hành động cũ. Nếu đội bạn đã từng chạy retro, hãy lục lại các hành động của 3 buổi gần nhất. Bao nhiêu phần trăm thực sự được hoàn thành? Con số này cho bạn biết vòng lặp cải tiến của đội đang khỏe hay yếu.
Tóm tắt
- Retro là cơ chế cải tiến liên tục (continuous improvement): dừng lại, nhìn lại quá trình làm việc, và cam kết thay đổi cụ thể — để đội mỗi chu kỳ lại tốt hơn thay vì lặp lại sai lầm.
- Ba nhịp độ, ba tầm nhìn: sprint retro (hai tuần/lần, quy trình hàng ngày), project retro (sau mỗi major launch, bài học chiến lược), quarterly retro (mỗi quý, xu hướng ở tầm tổ chức). Mỗi loại nhìn thấy thứ mà loại khác bỏ lỡ.
- Nền tảng là tinh thần blameless — Prime Directive tách vấn đề khỏi con người, để mọi người dám nói thật.
- Năm giai đoạn: set the stage, gather data, generate insights, decide what to do, close. Bước quan trọng nhất, hay bị bỏ nhất, là decide what to do.
- Quy tắc vàng: mỗi retro đẻ ra tối đa 3 hành động, mỗi hành động có owner và deadline, và luôn kiểm tra chúng ở đầu buổi sau. Đó là mắt xích khép kín vòng lặp.
- Là manager mới, hãy nói ít, điều phối khéo, và bảo vệ buổi retro như một nghi thức bất khả xâm phạm — đặc biệt trong những sprint tệ nhất, vì đó là lúc bài học nhiều nhất.