The Reality Check #5: Agile Theater Khi Scrum biến thành nhà hát kịch
Team bạn standup 30 phút mỗi sáng, retro cuối sprint ai cũng khen nhau, velocity tăng đều nhưng sản phẩm vẫn ship trễ 3 tháng. Chào mừng bạn đến với Agile Cosplay,luôn nói Agile nhưng chạy Waterfall
Chúng tôi chạy Agile! Câu nói có sức hủy diệt ngang ngửa “Chúng tôi lấy khách hàng làm trung tâm!” trong giới Tech Việt Nam. Nói thì dễ, làm thì... sấp mặt.
9 giờ sáng thứ Hai. Phòng họp của một công ty công nghệ tại Quận 1.
Mười hai người ngồi quanh một cái bàn dài. Scrum Master một bạn trẻ cầm chứng chỉ PSM I mới thi tuần trước mở Jira lên máy chiếu và bắt đầu gọi tên từng người: “Anh Nam, hôm qua anh làm gì, hôm nay anh làm gì, có blocker gì không?” Anh Nam — một Senior Dev 8 năm kinh nghiệm thở dài, đọc y nguyên cái status đã ghi sẵn trong Jira từ tối hôm trước. Mười một người còn lại ngồi lướt điện thoại chờ đến lượt.
Ba mươi hai phút sau, buổi standup kết thúc. Không ai đứng. Không ai giải quyết được gì. Mọi người túa ra khỏi phòng họp và bắt đầu... làm việc thật.
Và nếu bạn đọc The Reality Check từ đầu, bạn sẽ thấy một pattern: Chúng ta cứ mang sách Tây về, bê nguyên xi quy trình vào, rồi tự hỏi tại sao nó gãy. Tập #3 đã nói về chuyện Empowered Teams thành ảo tưởng vì văn hóa sếp. Hôm nay, chúng ta sẽ đào sâu hơn một tầng nữa: không chỉ cách quản lý sai, mà cả quy trình cũng sai. Sai từ đầu.
Bài này sẽ phân tích một hiện tượng mà mình gọi là “Agile Cosplay” team mặc đồ Agile ra trận nhưng bên trong vẫn chạy Waterfall, và cái giá phải trả cho vở kịch này đắt hơn bạn tưởng.
The Theory: Agile Manifesto và giấc mơ đẹp năm 2001
Năm 2001, 17 ông lớn ngành phần mềm ngồi lại ở một khu trượt tuyết tại Utah và viết ra Agile Manifesto với 4 giá trị cốt lõi và 12 nguyên tắc. Nói gọn lại thì thế này:
Coi trọng con người và tương tác hơn quy trình và công cụ.
Coi trọng phần mềm chạy được hơn tài liệu đầy đủ.
Coi trọng cộng tác với khách hàng hơn đàm phán hợp đồng.
Coi trọng phản ứng với thay đổi hơn bám theo kế hoạch.
Đẹp. Thông minh. Rất đúng.
Rồi từ cái Manifesto thanh lịch đó, người ta đẻ ra cả một đế chế: Scrum, Kanban, SAFe, LeSS, Nexus, Disciplined Agile... mỗi framework đi kèm một hệ sinh thái chứng chỉ, khóa học, và consultant có giá từ $2,000 đến $50,000 một đầu người. Agile không còn là một triết lý. Nó trở thành một ngành công nghiệp.
Scrum framework phổ biến nhất quy định rõ ràng: Sprint 2 tuần, Daily Standup 15 phút, Sprint Review, Sprint Retro, Sprint Planning. Ba vai trò: Product Owner, Scrum Master, Development Team. Mọi thứ được đóng gói gọn gàng, dễ triển khai.
Ở Mỹ, với văn hóa flat hierarchy rõ ràng, quyền tự quyết cao, và team đã quen với việc challenge ý kiến sếp Scrum chạy ngon lành. Nhưng khi cái framework đó bay 16,000 km từ San Francisco về Sài Gòn hay Hà Nội thì sao?
The Breaking Point: “Water-Scrum-Fall” và vở kịch 15 tiếng/tuần
Mình sẽ không vòng vo. Thực tế ở phần lớn các công ty tech Việt Nam là thế này: họ không chạy Agile. Họ chạy một thứ mà dân trong nghề gọi là Water-Scrum-Fall viết spec kiểu Waterfall (trên xuống, không thay đổi), meeting kiểu Scrum (ceremony đủ cả), và trễ deadline y hệt Waterfall truyền thống.
Nhưng trên LinkedIn và trong JD tuyển dụng, vẫn viết rất mạnh mẽ: “We are an Agile organization.”
Mình hay gọi đó là Agile Cosplay dân giả hơn là Agile Giả Cầy
Và đây là 3 triệu chứng bệnh nặng nhất:
Triệu chứng 1: Standup biến thành buổi báo cáo.
Theo Scrum Guide, Daily Standup là buổi đồng bộ ngắn do team tự tổ chức. 15 phút, đứng, chỉ nói blocker. Nhưng ở nhiều nơi, standup biến thành buổi trình diễn cho Scrum Master hoặc tệ hơn cho Engineering Manager ngồi ghi chép ai có vẻ làm ít.
Khảo sát của một công ty tư vấn Agile cho thấy hơn 60% developer coi standup là waste of time đặc biệt với team remote. Họ phải dậy sớm join Zoom, đọc lại cái đã viết sẵn trên Jira, rồi tắt camera đi uống cà phê. Cái buổi họp 15 phút đó, cộng thêm thời gian chuẩn bị và context switching, thực tế ngốn 30-45 phút mỗi ngày. Nhân lên 5 ngày. Nhân lên 10 người. Mỗi tuần bay mất 37-75 giờ làm việc của cả team chỉ để mọi người đọc to cái Jira ticket cho nhau nghe.
Bạn có thấy cái sự cà chớn ở đây không?
Triệu chứng 2: Retro thành buổi team building cho xong.
Sprint Retrospective đáng lẽ là buổi tự soi gương tàn nhẫn nhất: cái gì sai, tại sao sai, và sửa ra sao. Nhưng ở nơi văn hóa dĩ hòa vi quý thấm vào xương retro biến thành buổi khen nhau.
“Sprint này team làm tốt lắm!”, “Ừ, cải tiến thêm chút nữa là ngon!”
Không ai dám nói rằng cái tính năng vừa ship ra là vớ vẫn đầy lỗi vì sếp chỉ đạo. Không ai dám chỉ ra rằng Scrum Master chẳng giải quyết được blocker nào suốt 2 tuần. Và chắc chắn không ai dám đề xuất cắt bớt ceremony vì sợ bị quy kết là không Agile.
Kết quả? Mỗi sprint retro đẻ ra 5-7 action items mà không ai follow up. Sprint sau lặp lại y chang. Cái vòng lặp cải tiến liên tục (Continuous Improvement) linh hồn của Agile chết từ trong trứng nước.
Triệu chứng 3: Scrum Master trở thành Jira Admin sang chảnh.
Đây là vấn đề nhạy cảm nhất mà ít ai dám nói. Trong nhiều công ty , Scrum Master thực chất chỉ làm mấy việc này: tạo sprint trên Jira, nhắc mọi người update ticket, book phòng họp, và facilitate (dẫn dắt) các ceremony.
Nghe quen không? Đó là mô tả công việc của một Project Coordinator với mức lương thấp hơn 2-3 lần.
Năm 2026, khi AI đã có thể tự generate sprint report, tự tổng hợp blocker từ Slack, thậm chí tự suggest story point — thì câu hỏi đặt ra là: Scrum Master còn tạo ra giá trị gì? Thị trường đang trả lời câu hỏi đó bằng cách sáp nhập vai trò Scrum Master vào các title rộng hơn: Delivery Manager, Product Operations, hoặc đơn giản là... trả lại cho PM.
(Mình biết viết đoạn này ra sẽ bị một đống người có chứng chỉ SAFe chửi. Nhưng kệ. Sự thật thì vẫn là sự thật.)
Rồi, nói xong 3 triệu chứng, bây giờ zoom out một chút để nhìn cái hệ thống đang tạo ra vấn đề này ?
Tại sao Agile Cosplay tồn tại được? Vì nó phục vụ lợi ích của rất nhiều người:
Sếp: Có ceremony để kiểm soát team mà vẫn được tiếng dân chủ. Standup hàng ngày = báo cáo hàng ngày nhưng gọi tên hay hơn.
HR: Có framework oai để viết vào trang tuyển dụng: Chúng tôi áp dụng Agile/Scrum.
Consultant: Bán khóa đào tạo Agile Transformation với giá trên trời. Xong quất vài cái ceremony vào, ship cho khách cái PowerPoint đẹp, rồi biến mất.
Scrum Master: Có job title ngon lành, lương ổn, và công việc hàng ngày chủ yếu là... book phòng họp.
PM: Có người Scrum Master gánh mấy cái ceremony lặt vặt để mình rảnh tay làm việc khác.
Ai cũng được lợi. Trừ sản phẩm và khách hàng.
Mình từng hỏi một anh CTO startup ở Quận 7: “Cycle time trung bình của team anh là bao lâu từ lúc idea quan trọng tới lúc lên production?” Anh ấy trả lời tự tin: “2 sprint, tầm 4 tuần.”
Mình bảo: “Anh đo lại đi. Đo từ lúc idea xuất hiện lần đầu trong cuộc họp, chứ không phải từ lúc nó được ghi vào Jira.”
Anh ấy đo lại. Kết quả: 11 tuần. Vì idea phải qua 3 tầng duyệt trước khi vào backlog. Rồi nằm trong backlog 4 tuần chờ ưu tiên. Rồi mới vào sprint.
Bốn tuần sprint, nhưng 11 tuần cycle time. Agile ở chỗ nào?
The Patch: Flow-First Hãy tập trung đo Flow của team.
Mình không có ý bảo Agile là sai. Triết lý Agile thích ứng nhanh, phản hồi sớm, giảm lãng phí là đúng. Cái sai là cách chúng ta triển khai nó. Chúng ta đã biến một triết lý linh hoạt thành một tôn giáo cứng nhắc, rồi thắc mắc tại sao thần không phù hộ nó đi nhanh.
Theo mình đây là Bản vá cho Agile Cosplay. Mình gọi nó là “Flow-First” ưu tiên dòng chảy công việc thực tế, không ưu tiên ceremony.
1. Đo Cycle Time, đốt bỏ Velocity
Velocity (số story point hoàn thành mỗi sprint) là chỉ số dễ game nhất trên đời. Team cứ inflate story point lên là velocity tự tăng. Sếp vui. Biểu đồ đẹp. Nhưng sản phẩm vẫn ship trễ.
Thay vào đó, hãy đo Cycle Time thời gian thực từ lúc task bắt đầu được làm đến lúc nó lên production. Con số này không nói dối. Nếu cycle time trung bình của team bạn là 3 tuần mà sprint chỉ có 2 tuần, thì bạn biết ngay: sprint boundary (ranh giới sprint) đang trở thành nút thắt cổ chai thay vì cái mốc để ship sản phẩm nhanh.
Hỏi team bạn: “Tốc độ delivery thực sự có nhanh hơn sau khi chạy Scrum không?” Nếu câu trả lời là ấp úng bạn đang cosplay.
2. Standup → Async Check-in, chỉ sync khi có lửa
Ý tưởng gốc của standup là tốt: mọi người đồng bộ nhanh, phát hiện blocker sớm. Nhưng trong thời đại remote work và AI và ngồi gần nhau vì nhiều cty đã bỏ wfh, cách thực hiện cần thay đổi hoàn toàn.
Cách làm: Mỗi sáng, mỗi người dành 3 phút gõ update vào một channel Slack/Teams … chuyên biệt (hoặc dùng bot tự hỏi). Format siêu gọn:
🟢 Đang làm: [task]
🔴 Stuck: [blocker cụ thể + tag người cần giúp]
Chỉ khi có 🔴 blocker thật sự mới cần sync call và chỉ những người liên quan mới cần tham gia. Không có blocker? Không có meeting. Đơn giản vậy thôi.
Kết quả? Team mình thử cách này và giải phóng được trung bình 4.5 giờ/tuần/người — tương đương hơn nửa ngày làm việc. Nửa ngày đó dev dùng để code. PM dùng để research. Không ai dùng để ngồi lướt điện thoại trong phòng họp.
3. Kill the ceremony bloat Giữ lại 2, đốt bỏ phần còn lại
Scrum có 5 event: Sprint Planning, Daily Standup, Sprint Review, Sprint Retro, Backlog Refinement. Ở team 8 người, tổng thời gian ceremony mỗi sprint (2 tuần) là khoảng 15-20 tiếng.
Mười lăm tiếng. Cho ceremony. Trong 80 tiếng làm việc. Gần 20% thời gian của team bay vào phòng họp.
Cách làm: Giữ lại 2 event quan trọng nhất, gộp và tinh gọn phần còn lại:
Weekly Planning + Refinement (gộp 2 thành 1, tối đa 60 phút/tuần): Chốt tuần này làm gì, clarify task nào chưa rõ.
Bi-weekly Demo + Retro (gộp 2 thành 1, tối đa 45 phút): Show hàng cho stakeholder + 15 phút retro nhanh theo format “1 thing to keep, 1 thing to kill.”
Standup đã chuyển sang async rồi. Tổng cộng: ~2.5 tiếng ceremony/2 tuần thay vì 15-20 tiếng. Team nhẹ nhõm. Sản phẩm chạy nhanh hơn.
4. Rebundle Scrum Master hoặc nâng cấp, hoặc loại bỏ
Đây là cái đau mà nhiều người không muốn nghe. Nếu Scrum Master của bạn chỉ đang làm việc của Jira Admin thì bạn có hai lựa chọn:
Nâng cấp thành Delivery Manager thực thụ: Người này phải biết đọc Cycle Time, biết phân tích bottleneck trong value stream, biết negotiate deadline với stakeholder. Đây không phải là người facilitate meeting đây là người tối ưu hóa dòng chảy delivery của cả team.
Loại bỏ và trả trách nhiệm về cho PM + Tech Lead: PM lo priority và stakeholder, Tech Lead lo technical decisions và unblock. Hai người này phối hợp là đủ. Không cần người thứ ba ngồi giữa chỉ để hỏi có blocker gì không?
Lựa chọn nào cũng đau. Nhưng cứ để Scrum Master ngồi book phòng họp với mức lương 25-40 triệu/tháng thì đau hơn đau ở ngân sách.
Mình nhớ hồi 2020, có một startup mà mình mentor ở Thủ Đức. Team 12 người, thuê consultant về triển khai Scrum đúng bài. Sau 3 tháng, CEO gọi mình bảo: “Anh Đạt ơi, sao tụi em chạy Agile mà ship còn chậm hơn lúc trước?”
Mình qua nhìn cái board Jira của team, thấy mỗi sprint có 45-50 ticket, grooming session kéo dài 2 tiếng vì Product Owner ngồi giải thích từng cái ticket một, retro thì ai cũng viết sticky note khen nhau. Mình hỏi: “Trong 3 tháng qua, retro đã tạo ra bao nhiêu thay đổi thực sự?”
Im lặng.
“Vậy thì retro của các em đang phục vụ ai? Phục vụ team hay phục vụ quy trình?”
CEO im thêm 5 giây rồi nói: “Phục vụ cái chứng chỉ Agile của ông nội consultant.”
Đó là lúc mình biết: Agile Cosplay không chỉ là vấn đề quy trình. Nó là vấn đề incentive. Khi incentive của tổ chức là trông giống Agile thay vì ship nhanh và chất lượng, thì mọi ceremony đều trở thành diễn kịch.
Bốn tập trước, chúng ta đã đập PMF ảo, Retention giả, Empowered Teams trong mơ, và Growth bằng mọi giá. Bài hôm nay thêm một viên gạch nữa vào bức tường hiện thực: ngay cả cách chúng ta tổ chức công việc hàng ngày cũng đang là một vở kịch.
Nhưng tin tốt là: khác với PMF hay Growth những thứ phụ thuộc vào thị trường và tiền bạc quy trình là thứ bạn có thể thay đổi ngay trong sprint tới. Không cần xin sếp. Không cần thêm budget. Chỉ cần đủ can đảm để hỏi một câu:
Nếu ngày mai xóa hết ceremony, chỉ giữ lại một, team sẽ giữ lại cái nào?
Câu trả lời sẽ cho bạn biết team thật sự cần gì. Phần còn lại? Kịch.
Tuần tới, Reality Check #6 sẽ xé toạc một “tôn giáo” khác mà mọi công ty tech đều thờ phụng: OKR. Khi nào OKR là la bàn thật, khi nào nó chỉ là KPI đội mũ sang chảnh? Chờ xem.
T.D, T6.2026
P/s: Làm gọn, nhanh và thay đổi quy trình không đồng nghĩa với việc bạn vô kỹ luật, thiếu tôn trọng team, không update các thông tin để team hiểu bạn làm gì. Lean # Vô kỹ luật.