Mở đầu — vì sao bài này quan trọng
Hãy hình dung một buổi sáng thứ Hai điển hình của đội Scrum mà bạn đang phục vụ. Bạn — Scrum Master — ngồi ở Hà Nội, mở máy lúc 8h30. Anh dev backend đang công tác ở Đà Nẵng vừa kết thúc cữ cà phê sáng. Cô designer ở TP.HCM thì theo lịch "hybrid", thường online muộn hơn vì kẹt xe và đưa con đi học. Và bạn còn một bạn tester người Philippines vừa gia nhập, lệch một múi giờ. Khi bạn cố xếp một buổi Retrospective chung 60 phút, bạn nhận ra: không có khung giờ nào mà tất cả mọi người vừa tỉnh táo, vừa rảnh, vừa muốn nói chuyện cùng lúc.
Đây không phải là tình huống hiếm gặp nữa. Sau giai đoạn 2020–2021, làm việc phân tán (distributed) và làm việc từ xa (remote) đã trở thành mặc định ở rất nhiều công ty công nghệ Việt Nam, từ các product company như MoMo, VNG, Tiki cho tới các công ty outsourcing phục vụ khách Mỹ, Úc, Nhật. Khi đội ngũ trải dài qua nhiều thành phố, nhiều múi giờ, và nhiều phong cách làm việc, buổi Retrospective đồng bộ (synchronous — tất cả cùng họp một lúc) bắt đầu rạn nứt. Người thì ngái ngủ, người thì đang phải đa nhiệm, người hướng nội thì im lặng để người nói nhiều "chiếm sóng".
Bài học này tập trung vào một câu trả lời cụ thể cho vấn đề đó: Async Retro — Retrospective bất đồng bộ. Đây là cách tổ chức buổi nhìn lại Sprint mà các thành viên không cần (hoặc gần như không cần) có mặt cùng một lúc. Họ đóng góp suy nghĩ theo nhịp riêng, trong khung giờ phù hợp với mình, rồi cả đội tổng hợp và quyết định. Bạn sẽ hiểu khi nào nên dùng async, các công cụ phù hợp với đội phân tán, quy trình triển khai từng bước, và những cái bẫy thường gặp. Ở bài này, ta nói riêng về cách vận hành Retrospective ở chế độ async cho đội phân tán — không lan sang việc thiết kế từng định dạng retro cụ thể (Sailboat, Starfish, Mad/Sad/Glad… đã có bài riêng) hay công cụ Daily Scrum phân tán (bài 42).
Khái niệm cốt lõi
Async retro là gì, và khác gì với retro truyền thống?
Retrospective truyền thống là synchronous: cả đội vào một phòng (vật lý hoặc Zoom), cùng nhau brainstorm, thảo luận, biểu quyết, chốt action item — tất cả gói gọn trong một buổi 60–90 phút.
Async retro tách quá trình đó ra theo thời gian. Thay vì một buổi liền mạch, nó thường gồm các giai đoạn được "kéo giãn" ra trong 1–2 ngày:
- Giai đoạn thu thập (gather): mỗi người tự viết quan sát, cảm nhận của mình vào một bảng chung (board), bất cứ lúc nào trong cửa sổ thời gian quy định.
- Giai đoạn nhóm và bình chọn (group & vote): mọi người đọc của nhau, gom ý trùng, dồn phiếu cho chủ đề quan trọng nhất.
- Giai đoạn quyết định (decide): chốt action item — phần này có thể vẫn cần một cuộc họp ngắn đồng bộ, hoặc tiếp tục async qua bình luận.
Vì sao đội phân tán cần async retro?
Thứ nhất, vấn đề múi giờ và giờ làm việc. Khi đội trải dài Việt Nam – Đông Nam Á – hoặc xa hơn là Mỹ/Âu, không tồn tại khung giờ vàng chung. Ngay cả trong nội bộ Việt Nam, nhịp làm việc cũng lệch: nhiều bạn ở Hà Nội quen bắt đầu sớm (8h), trong khi đội ở TP.HCM theo mô hình hybrid hay vào việc muộn hơn và làm tới tối. Async tôn trọng nhịp sinh học và lịch cá nhân của từng người.
Thứ hai, thời gian để suy ngẫm (reflection time). Retro đồng bộ thưởng cho người phản xạ nhanh và nói to. Người hướng nội (introvert) — vốn cần thời gian xử lý suy nghĩ trước khi phát biểu — thường thiệt thòi. Trong văn hóa Việt Nam, yếu tố thứ bậc và "ngại nói trước mặt sếp" càng khuếch đại điều này. Async cho mọi người vài giờ, thậm chí cả ngày, để gõ ra suy nghĩ chín chắn thay vì buột miệng.
Thứ ba, giảm sự thiên lệch theo nhóm (anchoring & groupthink). Trong retro đồng bộ, người nói đầu tiên thường "neo" cả cuộc thảo luận theo hướng của mình. Nếu thu thập ý kiến async và ẩn danh trước khi mở ra, mỗi người viết độc lập, nên bức tranh đa chiều hơn.
Thứ tư, để lại dấu vết (artifact). Đóng góp async được viết ra, lưu lại — dễ tra cứu, dễ chia sẻ cho người vắng mặt, dễ theo dõi action item qua các Sprint.
Đánh đổi: async được gì, mất gì?
Không có bữa trưa miễn phí. Async đánh mất năng lượng tức thời và sự kết nối cảm xúc của việc ngồi cùng nhau. Một câu nói đùa, một ánh mắt, một khoảnh khắc "à, hóa ra bạn cũng nghĩ vậy" — những thứ tạo nên gắn kết đội — khó tái hiện qua văn bản. Vì vậy, lựa chọn khôn ngoan thường là hybrid: thu thập async, rồi gặp nhau ngắn để chốt. Là Scrum Master, việc của bạn là chọn liều lượng async phù hợp với từng đội, chứ không áp một công thức cứng.
Bộ công cụ phổ biến cho async retro
- Công cụ retro chuyên dụng: EasyRetro, Retrium, TeamRetro, Parabol, Metro Retro. Ưu điểm: có sẵn cột, timer, bình chọn, ẩn danh, xuất action item.
- Bảng cộng tác đa năng: Miro, FigJam, Mural. Linh hoạt, nhưng bạn phải tự dựng cấu trúc.
- Công cụ "nhẹ" sẵn có trong công ty: một thread trên Slack/Microsoft Teams với các emoji phản hồi, một bảng Notion, hay thậm chí Google Forms + Google Sheet. Phù hợp đội nhỏ, ngân sách hạn chế — rất thực tế ở nhiều startup Việt Nam.
Tình huống thực tế
Tình huống 1: Công ty outsourcing ở TP.HCM phục vụ khách Mỹ
Một công ty phần mềm gia công khoảng 200 người ở TP.HCM có một đội Scrum 7 người làm dự án cho khách hàng ở California. Lệch múi giờ giữa TP.HCM và California là 14–15 tiếng. Đội Việt Nam làm giờ hành chính, còn Product Owner phía khách thì chỉ online buổi tối (giờ VN). Trước đây họ cố tổ chức retro đồng bộ lúc 21h giờ VN để PO tham gia — kết quả là cả đội mệt mỏi, chất lượng thảo luận tệ, và sau ba Sprint thì nửa đội bắt đầu "cáo bận".
Scrum Master chuyển sang mô hình async trên EasyRetro. Cô mở board vào sáng thứ Năm (ngày cuối Sprint), với ba cột quen thuộc, đặt cửa sổ thu thập kéo dài đến hết chiều thứ Sáu. Đội Việt Nam viết trong giờ làm; PO Mỹ viết vào "buổi tối" của họ — tức sáng thứ Sáu giờ VN. Đến chiều thứ Sáu, mọi thẻ đã sẵn sàng. Cô gom nhóm, mở bình chọn online (mỗi người 3 phiếu, hạn 2 tiếng), rồi tổ chức một cuộc họp đồng bộ ngắn 30 phút chỉ để bàn 3 chủ đề được phiếu cao nhất và chốt action item.
Bài học rút ra: async không thay thế hoàn toàn cuộc họp — nó nén cuộc họp lại. Từ buổi 21h đầy uể oải kéo 75 phút, họ còn một cuộc 30 phút sắc bén, đặt vào khung giờ mà cả hai bên đều tỉnh táo (sáng VN / tối hôm trước bên Mỹ). Sự tham gia của PO tăng rõ rệt vì anh được đọc trước và chỉ vào đúng phần cần quyết định.
Tình huống 2: Startup fintech với đội phân tán nội địa Hà Nội – Đà Nẵng – TP.HCM
Một startup fintech Việt khoảng 40 người có một đội sản phẩm 6 người nằm rải ba thành phố. Không lệch múi giờ, nhưng lệch nhịp: hai bạn Hà Nội bắt đầu lúc 8h, ba bạn TP.HCM theo hybrid vào việc khoảng 9h30–10h và làm tới muộn, một bạn Đà Nẵng làm full-remote. Mỗi lần xếp retro đồng bộ là một cuộc đàm phán lịch mệt mỏi, và thường có người vào trễ 15 phút làm cả buổi trôi tuột.
Scrum Master quyết định làm async hoàn toàn trên Miro vì đội đã dùng Miro để vẽ flow. Anh dựng một template Sailboat (định dạng đã quen), mở thu thập từ chiều cuối Sprint đến 11h trưa hôm sau. Có một quy ước rõ ràng: ai viết xong thì thả emoji 👍 vào ô "Tôi đã đóng góp xong" để mọi người biết tiến độ. Phần thảo luận diễn ra ngay trên Miro bằng comment threads — ai có ý kiến cứ reply vào sticky note đó. Cuối cùng anh tổng hợp action item vào một bảng Notion liên kết với Jira.
Có một trục trặc ở Sprint đầu: hai bạn hướng nội ở Đà Nẵng và TP.HCM viết rất nhiều, sâu sắc; còn một bạn senior hay nói trong họp trực tiếp thì… chỉ viết hai dòng cụt lủn. Scrum Master nhận ra async đảo ngược động lực: người vốn "ăn nói" lại lười viết. Anh khắc phục bằng cách nhắn riêng, đặt câu hỏi mở để gợi bạn senior viết kỹ hơn, và đưa "đóng góp retro" thành một thói quen được cả đội cùng tôn trọng.
Bài học rút ra: ngay trong nội địa Việt Nam, không lệch múi giờ, async vẫn cực kỳ giá trị nếu đội lệch nhịp làm việc. Và đừng cho rằng người nói nhiều sẽ tự động viết nhiều — async cần được "nuôi" bằng kỳ vọng rõ ràng và sự thúc đẩy nhẹ nhàng của Scrum Master.
Tình huống 3: Đội Đông Nam Á dùng Slack vì không có ngân sách tool
Một đội 5 người của một agency, gồm thành viên ở Hà Nội, Bangkok và Jakarta, không được duyệt ngân sách mua tool retro riêng. Họ chỉ có Slack. Scrum Master tận dụng một kênh Slack riêng cho retro. Mỗi cuối Sprint, cô đăng một message mở thread với ba câu hỏi (điều tốt, điều cản trở, điều muốn thử). Mỗi người trả lời trong thread, dùng 🧵 reply và emoji để "vote" cho ý kiến của đồng đội. Cửa sổ mở 24 tiếng để Bangkok và Jakarta (lệch 1 tiếng so với VN) đều kịp.
Vấn đề: trên Slack mọi đóng góp đều hiện tên, không ẩn danh được — nên các vấn đề nhạy cảm (ví dụ về một thành viên cụ thể) ít được nêu ra. Scrum Master xử lý bằng cách bổ sung một Google Form ẩn danh chạy song song cho những điều "khó nói", rồi cô tự đọc và đưa lên thread dưới dạng tổng hợp không nêu tên.
Bài học rút ra: bạn không cần tool xịn để bắt đầu async — Slack/Teams + Form là quá đủ cho đội nhỏ. Nhưng hãy ý thức giới hạn về ẩn danh và an toàn tâm lý, và bù đắp bằng một kênh phụ khi cần.
Hướng dẫn từng bước
Bước 1 — Quyết định liều lượng async. Hỏi: đội lệch múi giờ bao nhiêu? Có ai hướng nội bị lép vế không? Vấn đề Sprint này có nhạy cảm cần ẩn danh không? Từ đó chọn: async hoàn toàn, hay hybrid (thu thập async + họp chốt ngắn). Với đội mới làm quen, hybrid thường an toàn hơn.
Bước 2 — Chọn công cụ và dựng cấu trúc trước. Đừng để đội vào một board trống. Tạo sẵn cột/câu hỏi theo định dạng đã quen, đặt tiêu đề rõ ràng, viết hướng dẫn ngắn ngay trên board. Bật ẩn danh nếu công cụ hỗ trợ và chủ đề cần.
Bước 3 — Công bố cửa sổ thời gian rõ ràng. Ví dụ: "Mở thu thập từ 16h thứ Năm đến 11h thứ Sáu". Nêu rõ múi giờ ("16h giờ VN, GMT+7") để tránh nhầm lẫn với thành viên nước ngoài. Cửa sổ nên đủ dài để mọi múi giờ kịp tham gia, nhưng đừng quá dài kẻo trôi vào quên lãng — 18 đến 36 tiếng là hợp lý.
Bước 4 — Nhắc nhở nhẹ nhàng. Đặt một reminder tự động (Slack reminder, lịch) trước khi cửa sổ đóng vài tiếng. Theo dõi ai chưa đóng góp và nhắn riêng — không "bêu tên" công khai.
Bước 5 — Gom nhóm và mở bình chọn. Sau khi đóng thu thập, gom các thẻ trùng ý, đặt nhãn nhóm. Mở bình chọn (thường 3 phiếu/người) trong một cửa sổ ngắn hơn (1–2 tiếng) để hội tụ vào vài chủ đề quan trọng nhất.
Bước 6 — Quyết định action item. Đây là phần dễ "hụt" nhất ở async. Hai lựa chọn: (a) họp đồng bộ 20–30 phút chỉ bàn top 2–3 chủ đề và chốt action; hoặc (b) tiếp tục async qua comment, nhưng bạn phải chủ động đề xuất action cụ thể để mọi người duyệt, thay vì để treo lơ lửng. Mỗi action cần có người chịu trách nhiệm và mốc thời gian.
Bước 7 — Ghi lại và đóng vòng lặp. Lưu action item vào nơi đội nhìn thấy hằng ngày (Jira, Notion, board). Đầu retro Sprint sau, mở lại các action cũ để kiểm tra — đây là điều khiến retro async không trở thành "viết cho có rồi quên".
Lỗi thường gặp & mẹo
Lỗi 1 — Bỏ luôn phần quyết định. Đội thu thập rất hăng nhưng không ai chốt action, vì không có cuộc họp ép buộc điều đó. Mẹo: luôn có một bước decide rõ ràng, dù chỉ là cuộc họp 20 phút hay một message tổng hợp action mà Scrum Master chủ động viết và xin duyệt.
Lỗi 2 — Cửa sổ thời gian mơ hồ hoặc nêu sai múi giờ. "Để đó cuối tuần làm" = không ai làm. Mẹo: deadline cụ thể, kèm múi giờ, kèm reminder.
Lỗi 3 — Giả định mọi người đều thoải mái viết. Người nói giỏi chưa chắc viết giỏi, và người ngại tiếng Anh trong đội đa quốc gia có thể tự kiểm duyệt. Mẹo: cho phép viết bằng tiếng Việt nếu đội nội địa; đặt câu hỏi mở gợi mở; làm mẫu bằng cách tự viết một thẻ chất lượng.
Lỗi 4 — Đánh mất kết nối con người. Toàn async lâu ngày khiến đội thấy "lạnh". Mẹo: xen kẽ — vài Sprint async thì có một Sprint retro đồng bộ trực tiếp (hoặc video) để hâm nóng tình cảm. Thêm một câu check-in cảm xúc nhẹ ở đầu board.
Lỗi 5 — Ẩn danh giả tạo. Dùng Slack hiện tên rồi tự nhủ "vẫn an toàn" — nhưng vấn đề nhạy cảm sẽ bị giấu. Mẹo: thêm kênh ẩn danh (Google Form) cho những điều khó nói.
Lỗi 6 — Scrum Master biến mất trong async. Async không có nghĩa là bạn rảnh tay. Mẹo: bạn vẫn phải facilitate — dựng board, nhắc nhở, gom nhóm, đặt câu hỏi đào sâu trong comment, và đảm bảo action được chốt.
Bài tập thực hành
- Tự đánh giá đội của bạn: Viết ra (a) đội bạn lệch múi giờ/nhịp làm việc thế nào, (b) có bao nhiêu người hướng nội thường ít nói trong retro đồng bộ, (c) Sprint gần nhất có chủ đề nào nhạy cảm cần ẩn danh không. Từ ba câu trả lời, quyết định liều lượng async phù hợp: hoàn toàn hay hybrid.
- Dựng một board mẫu: Chọn một công cụ đội đã có sẵn (EasyRetro, Miro, hoặc chỉ Slack + Google Form). Tạo cấu trúc retro với câu hỏi rõ ràng, viết hướng dẫn ngắn và công bố một cửa sổ thời gian cụ thể kèm múi giờ. Mời đội thử ở Sprint tới.
- Thiết kế kịch bản nhắc nhở: Soạn sẵn nội dung 2 message: một message mở cửa sổ thu thập, một message nhắc trước khi đóng 3 tiếng. Đặt reminder tự động.
- Luyện bước decide: Sau khi thu thập và bình chọn xong, hãy tự viết bản nháp 3 action item cho top 3 chủ đề — mỗi action có người phụ trách và deadline — rồi đưa đội duyệt. So sánh chất lượng action so với retro đồng bộ trước đó của bạn.
- Phản tư sau 2 Sprint: Sau khi chạy async 2 lần, hỏi đội (qua một mini-survey ẩn danh): chế độ async giúp ích hay gây phiền? Ai cảm thấy được lắng nghe hơn? Điều chỉnh liều lượng cho phù hợp.
Tóm tắt
Async retro là công cụ thiết yếu khi đội Scrum trở nên phân tán — qua nhiều múi giờ, nhiều thành phố, nhiều nhịp làm việc, như thực tế rất phổ biến ở các công ty công nghệ Việt Nam và Đông Nam Á hiện nay. Cốt lõi của nó là kéo giãn quá trình retro ra theo thời gian: thu thập async để tôn trọng nhịp riêng của mỗi người, cho người hướng nội thời gian suy ngẫm, và giảm thiên lệch nhóm; rồi hội tụ về quyết định, thường qua một cuộc họp ngắn gọn hoặc một bước chốt action có chủ đích.
Ba bài học xuyên suốt: (1) async không xóa bỏ tương tác trực tiếp mà nén nó lại, nên hybrid thường là lựa chọn khôn ngoan; (2) bạn không cần tool đắt tiền — Slack/Teams + Google Form đủ để bắt đầu, miễn là quan tâm đến ẩn danh và an toàn tâm lý; (3) Scrum Master không hề "nhàn" hơn — bạn vẫn phải dựng cấu trúc, nhắc nhở, đào sâu và đảm bảo action được chốt và đóng vòng lặp. Làm tốt những điều này, buổi nhìn lại Sprint của đội phân tán sẽ không còn là cuộc đàm phán lịch mệt mỏi, mà thành một thói quen học hỏi đều đặn, công bằng và để lại dấu vết rõ ràng qua từng Sprint.