Mở đầu — vì sao bài này quan trọng
Có một câu nói trong giới Agile mà tôi rất tâm đắc: "Bạn không thực sự biết một quy trình có vững chắc hay không cho đến khi nó bị đặt dưới áp lực." Suốt nhiều năm, Agile được thử nghiệm trong những điều kiện tương đối ổn định: team ngồi cùng phòng, sprint diễn ra đều đặn, retro mỗi hai tuần một lần. Rồi đại dịch COVID-19 ập đến vào đầu năm 2020, và toàn bộ ngành phần mềm — cùng vô số ngành khác — bị đẩy vào một bài kiểm tra căng thẳng (stress test) lớn nhất trong lịch sử hiện đại.
Đây không phải bài học về lý thuyết. Đây là bài học về cách Agile hành xử khi thế giới sụp đổ xung quanh nó. Tại sao điều này quan trọng với bạn — một Project Manager hoặc Scrum Master tại Việt Nam? Bởi vì khủng hoảng không phải ngoại lệ, nó là quy luật. Sau COVID là lạm phát toàn cầu, sa thải hàng loạt trong ngành tech 2022-2023, đứt gãy chuỗi cung ứng, biến động tỷ giá. Một PM giỏi không chỉ điều hành team khi mọi thứ êm đẹp, mà phải biết giữ team đứng vững khi mọi giả định nền tảng bị xóa bỏ chỉ sau một đêm.
Trong bài này, chúng ta sẽ mổ xẻ những bài học cụ thể mà COVID dạy cho Agile, vì sao một số giả định "bất di bất dịch" của Scrum bị phá vỡ, và quan trọng nhất: cách xây dựng một team Agile đủ kiên cường (resilient) để vượt qua bất kỳ cuộc khủng hoảng nào tiếp theo. Bởi sẽ luôn có một cuộc khủng hoảng tiếp theo.
Khái niệm cốt lõi
Khủng hoảng phơi bày sự thật về tổ chức của bạn
Khủng hoảng không tạo ra vấn đề mới — nó phơi bày những vấn đề vốn đã âm ỉ. Một team mà giao tiếp phụ thuộc hoàn toàn vào việc "quay sang hỏi nhau" sẽ tê liệt khi chuyển sang làm việc từ xa. Một tổ chức mà mọi quyết định phải leo lên cấp giám đốc sẽ chết đứng khi giám đốc bận chống dịch. Ngược lại, team nào có văn hóa tài liệu hóa tốt, trao quyền (empowerment) rõ ràng, và niềm tin lẫn nhau sẽ thích nghi gần như tức thì.
Agile, về bản chất, là một bộ công cụ để xử lý sự bất định (uncertainty). Khủng hoảng đơn giản chỉ là sự bất định ở cường độ cực đại. Nên nghịch lý là: nếu Agile của bạn được làm "thật", khủng hoảng sẽ là lúc nó tỏa sáng nhất.
Giả định "phải ngồi cùng phòng" (co-location) bị phá vỡ
Agile Manifesto năm 2001 có một nguyên tắc nổi tiếng: "Cách hiệu quả và hiệu suất nhất để truyền đạt thông tin tới và trong nội bộ team phát triển là trò chuyện trực tiếp mặt đối mặt." Suốt gần 20 năm, dòng chữ này được nhiều người diễn dịch thành "team Agile bắt buộc phải ngồi cùng một chỗ."
COVID xóa sổ giả định đó chỉ trong vài tuần. Hàng triệu team trên thế giới buộc phải làm việc từ xa 100%. Và điều bất ngờ là: phần lớn vẫn ship được sản phẩm. Năng suất ở nhiều nơi không giảm, thậm chí tăng. Hóa ra điều cốt lõi không phải là khoảng cách vật lý, mà là chất lượng giao tiếp và độ tin cậy của thông tin. "Mặt đối mặt" có thể thay bằng "có mặt và tập trung qua video", miễn là team biết cách làm.
Async vs. Sync — sự trưởng thành của công cụ và tư duy
Trước COVID, công cụ async (bất đồng bộ) như Slack, Notion, Miro, Loom đã tồn tại nhưng bị xem là phụ trợ. Khủng hoảng đẩy chúng vào trung tâm. Team học được rằng không phải mọi giao tiếp đều cần diễn ra cùng lúc (real-time).
Phân biệt quan trọng:
- Sync (đồng bộ): mọi người có mặt cùng lúc — họp video, Daily Scrum, pair programming. Tốn thời gian chung nhưng tạo kết nối và giải quyết vấn đề phức tạp nhanh.
- Async (bất đồng bộ): mỗi người xử lý theo nhịp riêng — comment trên tài liệu, video Loom giải thích, cập nhật trạng thái bằng văn bản. Tôn trọng "deep work", phù hợp team lệch múi giờ.
Resilience (sức bền) thay vì chỉ Efficiency (hiệu suất)
Trước khủng hoảng, nhiều team tối ưu cho hiệu suất tối đa — chạy hết công suất, không có khoảng đệm (slack), velocity cao nhất có thể. COVID dạy một bài học đắt giá: một hệ thống tối ưu hiệu suất tuyệt đối là một hệ thống giòn (brittle). Chỉ cần một biến cố là gãy.
Tư duy mới đặt resilience ngang hàng với efficiency: dự phòng kiến thức (không để một người ôm hết hiểu biết về một module — tránh "bus factor = 1"), có khoảng đệm trong kế hoạch, đa dạng kênh giao tiếp, và khả năng ra quyết định phân tán.
Tình huống thực tế
Ví dụ 1 — Công ty fintech tại TP.HCM: từ hoảng loạn đến async-first
Một công ty fintech tầm trung ở Quận 1, khoảng 80 kỹ sư chia thành 9 squad, trước tháng 3/2020 vận hành Scrum khá "sách giáo khoa": Daily Scrum 9h sáng đứng quanh bảng vật lý, Sprint Planning trong phòng họp lớn, dán giấy sticky note khắp tường.
Khi TP.HCM giãn cách, tuần đầu tiên là thảm họa. Daily kéo dài 45 phút vì đường truyền chập chờn, ai cũng nói chen nhau. Velocity hai sprint đầu tụt khoảng 40%. Backlog trên tường thì... vẫn nằm trên tường, không ai truy cập được.
Điều họ làm đúng: thay vì cố "bê y nguyên" quy trình cũ lên online, họ thiết kế lại. Daily Scrum chuyển một phần sang async — mỗi người viết ba dòng cập nhật (hôm qua, hôm nay, blocker) vào kênh Slack trước 9h, chỉ những ai có blocker mới nhảy vào call ngắn 10 phút. Backlog và board chuyển hết lên Jira. Các buổi brainstorm và Story Mapping dùng Miro. Mọi quyết định kiến trúc quan trọng được ghi lại bằng tài liệu ADR (Architecture Decision Record) thay vì "đã thống nhất miệng trong phòng họp".
Kết quả sau hai tháng: velocity hồi phục về mức cũ rồi vượt khoảng 15%, vì kỹ sư có nhiều khoảng deep work hơn, ít bị ngắt quãng hơn. Sau dịch, công ty giữ luôn mô hình hybrid: lên văn phòng 2 ngày/tuần cho Planning và Review, còn lại làm từ xa.
Bài học rút ra: Đừng số hóa quy trình cũ một cách máy móc. Khủng hoảng là cơ hội để thiết kế lại cách làm việc dựa trên nguyên lý Agile, chứ không phải sao chép thói quen.
Ví dụ 2 — Team outsourcing Đà Nẵng phục vụ khách Bắc Mỹ: lợi thế bất ngờ từ async
Một công ty gia công phần mềm ở Đà Nẵng, khoảng 25 người, làm cho một khách hàng startup ở San Francisco — lệch múi giờ khoảng 14-15 tiếng. Trước COVID, họ "ép" sync bằng cách bắt vài kỹ sư trực đêm để họp với khách. Mệt mỏi, kiệt sức, nghỉ việc nhiều.
Khi cả hai phía cùng làm từ xa, paradoxically (nghịch lý thay) tình hình lại tốt hơn. Khách hàng SF, vốn cũng buộc phải async hóa nội bộ, trở nên cởi mở với cách làm việc ghi-lại-bằng-văn-bản. Team Đà Nẵng chuyển sang quy trình "handoff": cuối ngày làm việc Việt Nam, họ quay một video Loom 5-7 phút demo tiến độ và nêu câu hỏi; khách xem vào sáng SF và trả lời bằng văn bản; sáng hôm sau Đà Nẵng đọc và tiếp tục. Sprint Review được ghi hình thay vì họp trực tiếp.
Số liệu đáng chú ý: số giờ họp đêm giảm từ trung bình 6 buổi/tuần xuống còn 1 buổi/tuần (chỉ giữ một buổi sync cho những vấn đề thật sự cần va chạm). Tỷ lệ nghỉ việc giảm rõ rệt trong năm tiếp theo. Khách hàng còn khen chất lượng tài liệu tốt hơn hẳn.
Bài học rút ra: Với team phân tán và lệch múi giờ — cực kỳ phổ biến ở Việt Nam khi làm outsourcing — khủng hoảng đã chứng minh async không phải "giải pháp tạm bợ" mà là một mô hình vận hành ưu việt. Điều này kết nối thẳng tới chủ đề team phân tán mà các bài khác bàn sâu hơn.
Ví dụ 3 — Một ngân hàng đa quốc gia tại Singapore: khủng hoảng làm lộ sự "Agile giả"
Một ngân hàng lớn có chi nhánh công nghệ ở Singapore tự hào đã "chuyển đổi Agile" trước COVID — có Scrum Master, có sprint, có standup. Nhưng khi đại dịch ập đến, mọi thứ đông cứng. Lý do: mọi quyết định, dù nhỏ, đều phải qua một chuỗi phê duyệt nhiều tầng. Khi các sếp bận xử lý khủng hoảng kinh doanh, các team kỹ thuật ngồi chờ. Sprint vẫn chạy hình thức nhưng chẳng ai dám quyết gì.
Đây là biểu hiện kinh điển của "Agile giả" (cargo cult Agile): có nghi thức nhưng không có tinh thần. Khủng hoảng phơi bày sự thật rằng họ chưa bao giờ thực sự trao quyền cho team. Phải mất gần một năm và sự can thiệp của lãnh đạo cấp cao để thực sự đẩy quyền quyết định xuống Product Owner và team, lập "ngưỡng quyết định" (decision threshold) rõ ràng: dưới một mức ảnh hưởng nhất định, team tự quyết, không cần leo cấp.
Bài học rút ra: Khủng hoảng không làm hỏng tổ chức của bạn — nó cho bạn thấy chỗ vốn đã hỏng. Một tổ chức Agile thật sự được kiểm chứng bằng việc nó vận hành thế nào khi lãnh đạo... vắng mặt.
Hướng dẫn từng bước
Nếu bạn muốn chuẩn bị team của mình cho cuộc khủng hoảng tiếp theo — và sẽ có một cuộc tiếp theo — đây là lộ trình thực tế:
- Kiểm tra "bus factor" của từng vùng kiến thức. Liệt kê các module, hệ thống, quy trình quan trọng và đánh dấu xem nếu một người duy nhất biến mất thì có ai thay thế được không. Mỗi chỗ "bus factor = 1" là một điểm gãy tiềm tàng. Lên kế hoạch pair/mob hoặc tài liệu hóa để san sẻ kiến thức.
- Tài liệu hóa các quyết định, không chỉ trao đổi miệng. Thiết lập thói quen ghi lại quyết định quan trọng (ADR cho kiến trúc, biên bản ngắn cho quyết định sản phẩm). Mục tiêu: bất kỳ ai vào sau đều hiểu được "vì sao" mà không cần hỏi ai.
- Phân loại giao tiếp thành sync và async một cách có chủ đích. Lập danh sách: việc nào bắt buộc sync (giải quyết xung đột, brainstorm phức tạp, retro), việc nào nên async mặc định (cập nhật trạng thái, review tài liệu, demo tiến độ). Viết ra thành thỏa thuận làm việc (working agreement) của team.
- Xây "kịch bản chuyển trạng thái" (continuity playbook). Trả lời trước các câu hỏi: Nếu mai không ai lên được văn phòng, team họp ở đâu? Board ở đâu? Ai có quyền quyết khi sếp vắng? Công cụ dự phòng là gì? Viết thành một trang giấy, ai cũng biết.
- Đưa khoảng đệm (slack) vào kế hoạch. Đừng lập kế hoạch sprint ở 100% công suất. Để lại 15-20% đệm cho biến cố. Team kín lịch là team không có khả năng hấp thụ cú sốc.
- Thiết lập "ngưỡng quyết định" rõ ràng. Xác định mức độ ảnh hưởng nào team tự quyết, mức nào cần leo cấp. Trao quyền trước khi khủng hoảng xảy ra, chứ không phải trong lúc đang cháy.
- Chăm sóc yếu tố con người. Khủng hoảng bào mòn tinh thần. Lên lịch check-in 1:1 thường xuyên, để ý dấu hiệu kiệt sức (burnout), và bình thường hóa việc nói ra khi ai đó đang quá tải.
Lỗi thường gặp & mẹo
Lỗi 1 — Số hóa quy trình cũ thay vì thiết kế lại. Nhiều team khi chuyển remote chỉ đơn giản chuyển standup vào Zoom mà giữ nguyên mọi thứ. Kết quả là họp video 45 phút mệt mỏi. Mẹo: hỏi "mục đích thật của nghi thức này là gì?" rồi thiết kế lại cách đạt mục đích đó trong bối cảnh mới.
Lỗi 2 — Lạm dụng sync, sợ async. Đặt lịch họp cho mọi thứ vì sợ "mất kiểm soát". Hệ quả là lịch kín mít, không ai có thời gian làm việc thật. Mẹo: mặc định async, chỉ họp khi đã thử mà không giải quyết được bằng văn bản.
Lỗi 3 — Bỏ quên retro trong khủng hoảng. Khi cháy nhà, người ta thường cắt bỏ retro vì "không có thời gian". Đây chính là lúc cần retro nhất, vì tốc độ thay đổi cao nhất. Mẹo: giữ retro ngắn gọn nhưng đều đặn, tập trung vào một cải tiến mỗi sprint.
Lỗi 4 — Nhầm "bận rộn" với "tiến triển". Trong khủng hoảng, ai cũng tỏ ra bận. Nhưng bận không có nghĩa đang tạo giá trị. Mẹo: bám chặt vào "Done" và giá trị giao cho khách hàng, đừng đo bằng số giờ online.
Lỗi 5 — Quên rằng con người không phải tài nguyên. Ép team chạy hết công suất giữa khủng hoảng dẫn tới burnout và nghỉ việc hàng loạt — đúng lúc bạn cần họ nhất. Mẹo: bảo vệ sức khỏe tinh thần của team như một ưu tiên chiến lược, không phải việc "tốt thì làm".
Mẹo vàng: Hãy coi mỗi cuộc khủng hoảng như một "retro bắt buộc" của cả tổ chức. Sau khi sóng gió qua đi, dành một buổi nghiêm túc hỏi: "Điều gì đã gãy? Điều gì giữ vững? Chúng ta giữ lại gì cho thời bình?" Nhiều thực hành tốt nhất hậu-COVID — như hybrid work, async-first — ra đời chính từ những buổi như vậy.
Bài tập thực hành
- Lập bản đồ bus factor (30 phút). Liệt kê 5 vùng kiến thức quan trọng nhất trong team/dự án hiện tại của bạn. Với mỗi vùng, ghi rõ có bao nhiêu người thực sự nắm vững. Đánh dấu đỏ những chỗ chỉ có 1 người. Đề xuất một hành động cụ thể cho từng điểm đỏ.
- Thiết kế lại một nghi thức (20 phút). Chọn một sự kiện Scrum (Daily, Planning, hoặc Review) và viết lại cách tổ chức nó nếu ngày mai team buộc phải làm việc từ xa 100%. Chỉ rõ phần nào sync, phần nào async, dùng công cụ gì.
- Viết Continuity Playbook một trang. Soạn một trang trả lời 5 câu hỏi: (a) team họp ở đâu nếu mất văn phòng? (b) Source of truth của backlog ở đâu? (c) Ai quyết khi lãnh đạo vắng mặt? (d) Công cụ giao tiếp dự phòng? (e) Cách báo blocker khẩn? Chia sẻ với team để cùng góp ý.
- Phân tích tình huống cá nhân. Nhớ lại một giai đoạn khủng hoảng bạn từng trải (COVID, một đợt sa thải, một sự cố production lớn). Viết ngắn: điều gì trong cách làm việc của team đã gãy, điều gì giữ vững, và bạn rút ra bài học gì để áp dụng từ giờ.
Tóm tắt
Khủng hoảng không phải là kẻ thù của Agile — nó là phép thử khắc nghiệt nhất và cũng là người thầy chân thật nhất. COVID-19 đã dạy ngành phần mềm vài bài học mà chúng ta cần khắc cốt:
- Giả định "phải ngồi cùng phòng" đã bị phá vỡ. Điều cốt lõi không phải khoảng cách vật lý, mà là chất lượng giao tiếp và độ tin cậy của thông tin.
- Async trưởng thành và trở thành chiến lược, không phải giải pháp tạm. Team mạnh nhất thiết kế có chủ đích khi nào sync, khi nào async — đặc biệt quan trọng với team phân tán, lệch múi giờ rất phổ biến ở Việt Nam.
- Khủng hoảng phơi bày sự thật. Tổ chức nào "Agile giả" sẽ đông cứng; tổ chức nào trao quyền và tài liệu hóa thật sẽ thích nghi tức thì.
- Resilience quan trọng ngang efficiency. Một hệ thống tối ưu hiệu suất tuyệt đối là một hệ thống giòn. Hãy để dành khoảng đệm, san sẻ kiến thức, phân tán quyền quyết định.
- Con người là trung tâm. Trong khủng hoảng, bảo vệ sức khỏe tinh thần của team là quyết định chiến lược, không phải việc làm khi rảnh.