Mở đầu — vì sao bài này quan trọng
Bạn đã đi qua 52 bài học. Bạn biết Scrum 3-5-3, biết velocity, biết retrospective, biết cả SAFe lẫn LeSS. Nhưng đây là sự thật phũ phàng mà ít ai nói thẳng với bạn: phần lớn các đội "làm Agile" ngoài kia thực ra đang làm Waterfall đội lốt Agile. Họ có Sprint, có Daily Scrum, có board Jira đẹp lung linh — nhưng kết quả vẫn chậm, vẫn căng thẳng, vẫn giao trễ. Bề ngoài là Agile, ruột bên trong là cơ chế cũ.
Hiện tượng đó có tên: antipattern (mô hình phản tác dụng) và smell (mùi khó chịu — dấu hiệu cảnh báo có vấn đề tiềm ẩn). Antipattern là một cách giải quyết vấn đề trông có vẻ hợp lý nhưng thực chất gây hại nhiều hơn lợi. Smell — mượn từ khái niệm "code smell" của Kent Beck và Martin Fowler — là một dấu hiệu bề mặt, bản thân nó chưa chắc là lỗi, nhưng thường báo hiệu một vấn đề sâu hơn đang ẩn nấp bên dưới.
Bài này quan trọng vì nó dạy bạn kỹ năng mà không khóa học chứng chỉ nào dạy kỹ: khả năng ngửi mùi. Một Scrum Master giỏi không phải người thuộc lòng Scrum Guide, mà là người bước vào một đội và trong vòng hai tuần nhận ra "đội này đang mini-waterfall", "Product Owner này là proxy chứ không có quyền quyết định", "retrospective này đang diễn kịch". Nhận ra sớm thì cứu được dự án. Nhận ra muộn thì dọn dẹp hậu quả. Đây là bài về chẩn đoán bệnh, không phải về kê đơn thuốc lý thuyết.
Khái niệm cốt lõi
Phân biệt antipattern và smell
Hãy hình dung bạn là bác sĩ. Smell là triệu chứng — sốt, ho, mệt. Bản thân sốt không phải bệnh; nó là dấu hiệu cơ thể đang phản ứng với điều gì đó. Antipattern là chẩn đoán — viêm phổi, cúm. Một antipattern thường biểu hiện qua nhiều smell cùng lúc.
Ví dụ: Daily Scrum kéo dài 35 phút (smell) + ai nói cũng nhìn về phía Scrum Master (smell) + không ai nhắc tới mục tiêu Sprint (smell) → cả ba cộng lại chỉ ra một antipattern: "Daily Scrum thành báo cáo tiến độ cho sếp".
Kỹ năng cần rèn là đi từ smell (dễ thấy) đến antipattern (gốc rễ), rồi mới đến giải pháp. Người mới hay nhảy thẳng từ smell sang giải pháp — "Daily dài quá, rút xuống 15 phút!" — mà không hỏi vì sao nó dài, nên chữa ngọn không chữa gốc.
Top 10 antipattern phổ biến nhất
1. Mini-Waterfall Sprint. Sprint Planning đẻ ra một lịch trình chi tiết từng ngày: thứ Hai design, thứ Ba code, thứ Tư test, thứ Năm fix bug, thứ Sáu demo. Mỗi Sprint trở thành một mini dự án Waterfall hai tuần. Smell: backlog Sprint bị micro-manage tới mức ai làm gì giờ nào đã định sẵn; testing luôn dồn về cuối Sprint; gần như Sprint nào cũng "carry-over" task test sang Sprint sau. Gốc rễ: đội chưa hiểu rằng Sprint là để giao một lát cắt giá trị hoàn chỉnh, không phải để nén quy trình tuần tự vào hai tuần.
2. Scrum Master kiêm sếp (Scrum Master as Boss). Scrum Master giao task, đánh giá nhân sự, quyết định kỹ thuật. Smell: trong Daily, mọi người báo cáo cho Scrum Master; đội không dám phản biện. Đây là Command-and-Control khoác áo Agile.
3. Product Owner bù nhìn (Proxy PO). PO không có quyền quyết định, mọi thứ phải "về xin ý kiến sếp lớn". Smell: backlog liên tục đảo lộn; câu trả lời cho mọi câu hỏi là "để anh hỏi lại". Đội bị nghẽn vì không ai có thẩm quyền nói "không".
4. Velocity làm vũ khí (Weaponized Velocity). Quản lý dùng velocity để so sánh các đội, ép tăng velocity quý sau. Smell: velocity tăng đều đặn một cách đáng ngờ; story point lạm phát (cùng một việc, kỳ này estimate gấp đôi kỳ trước). Đội học cách "chơi với con số" thay vì giao giá trị.
5. Retrospective trình diễn (Theater Retro). Họp retro đều đặn nhưng không có gì thay đổi. Smell: cùng một vấn đề được nêu Sprint này qua Sprint khác; action item không có người chịu trách nhiệm, không có deadline. Retro thành nghi lễ trống rỗng.
6. Definition of Done co giãn. Để "kịp" Sprint, đội âm thầm hạ chuẩn DoD — "lần này chưa viết test cũng được", "tài liệu để sau". Smell: nợ kỹ thuật phình to; bug từ Sprint trước quay lại Sprint sau.
7. Zombie Scrum. Đội làm đủ mọi nghi lễ Scrum nhưng không có nhịp sống: không có mục tiêu Sprint thực sự, không giao được sản phẩm chạy được, không cải tiến. Mọi thứ "đúng quy trình" nhưng vô hồn.
8. Water-Scrum-Fall. Đầu dự án là pha phân tích/thiết kế dài kiểu Waterfall, giữa là vài Sprint Scrum, cuối là pha release/UAT cứng nhắc kiểu Waterfall. Agile chỉ tồn tại ở khúc giữa.
9. Story point thành giờ công. Đội quy ước "1 point = 1 ngày" rồi dùng point để cam kết deadline. Smell: tranh cãi 3 point hay 5 point gay gắt như tranh lương. Point mất hết ý nghĩa tương đối của nó.
10. Backlog là bãi rác. Product Backlog phình tới 800 mục, không ai dọn, item từ hai năm trước vẫn nằm đó. Smell: refinement thành buổi khảo cổ; không ai biết thứ tự ưu tiên thật sự.
Tình huống thực tế
Tình huống 1 — Mini-Waterfall tại một fintech ở TP.HCM
Một công ty fintech khoảng 120 người ở Quận 1, gọi là MoneyGo, chuyển sang Scrum được tám tháng. Họ thuê tư vấn, training đầy đủ, mỗi đội 7 người, Sprint hai tuần. Nhìn bảng Jira thì hoàn hảo.
Nhưng có một mẫu lặp đáng ngờ: Sprint nào cũng có 3-4 task test bị kéo sang Sprint sau. Velocity dao động thất thường: 32, 18, 41, 15. Khi quan sát một buổi Sprint Planning, vấn đề lộ rõ. Đội lập kế hoạch như thế này: "Tuần một dev xong hết, tuần hai QA test". Tester ngồi chơi xơi nước suốt tuần đầu, rồi ngộp thở tuần hai. Tới thứ Năm tuần hai, dev tìm thấy bug, sửa, nhưng tester không kịp test lại — thế là carry-over.
Đây chính là Mini-Waterfall Sprint kinh điển. Họ đã nén quy trình Phân tích → Code → Test → Fix tuần tự vào trong một Sprint, thay vì để testing diễn ra song song với phát triển trên từng user story.
Cách chữa mà Scrum Master áp dụng: thay vì đo tiến độ bằng "code xong bao nhiêu", chuyển sang đo bằng "bao nhiêu story đã Done hoàn toàn". Họ giới hạn số story đang dở dang (work-in-progress) còn 3, ép tester và dev ghép cặp ngay từ ngày đầu Sprint trên cùng một story. Họ cũng đưa "viết test cho story này" vào trong chính story đó, không tách thành task riêng cuối Sprint. Sau bốn Sprint, carry-over về gần 0, velocity ổn định quanh mức 28-30.
Bài học: Sprint không phải là cái hộp để nhồi quy trình tuần tự vào. Nếu testing luôn dồn cuối Sprint, bạn đang làm Waterfall hai tuần một lần. Dấu hiệu sớm nhất luôn là carry-over và tester nhàn rỗi đầu Sprint.
Tình huống 2 — Velocity bị vũ khí hóa ở một công ty outsourcing
Một công ty gia công phần mềm ở Đà Nẵng, tạm gọi DaNangSoft, có 6 đội Scrum làm cho khách hàng Nhật. Giám đốc kỹ thuật treo một dashboard lớn ở sảnh: velocity của cả 6 đội, cập nhật mỗi Sprint, xếp hạng từ cao xuống thấp. Thông điệp ngầm rất rõ: đội nào velocity thấp là đội yếu.
Hậu quả diễn ra đúng như sách giáo khoa. Trong vòng ba tháng, velocity trung bình toàn công ty "tăng" 40%. Giám đốc mừng. Nhưng số bug production cũng tăng, khách hàng Nhật phàn nàn chất lượng giảm, và hai senior dev xin nghỉ.
Điều gì đã xảy ra? Các đội học cách chơi với con số. Một việc trước đây estimate 3 point, giờ estimate 5. Họ chẻ nhỏ story để cộng dồn point nhiều hơn. Họ bỏ qua refactoring và viết test (những thứ không "ra point") để dồn sức cày story. Velocity là chỉ số nội bộ để một đội tự dự báo cho chính mình, nhưng khi bị biến thành công cụ so sánh và KPI, nó lập tức bị bóp méo — đúng theo định luật Goodhart: "Khi một thước đo trở thành mục tiêu, nó thôi là một thước đo tốt."
Cách chữa: gỡ dashboard so sánh. Thay vào đó dùng các chỉ số hướng kết quả mà đội không thể "gian lận" dễ dàng: số bug thoát ra production, lead time từ lúc nhận yêu cầu tới lúc giao, mức độ hài lòng của khách. Velocity được trả về đúng vai trò — chỉ dùng trong nội bộ đội để lập kế hoạch Sprint kế tiếp, không ai ngoài đội nhìn vào.
Bài học: Đừng bao giờ dùng velocity để so sánh các đội hay làm KPI cá nhân. Story point của đội A và đội B không cùng đơn vị, so sánh là vô nghĩa. Khoảnh khắc bạn thấy quản lý treo bảng xếp hạng velocity, bạn đang chứng kiến một antipattern sắp phá nát văn hóa đội.
Tình huống 3 — Zombie Scrum tại một ngân hàng
Một ngân hàng tầm trung ở Hà Nội triển khai Scrum cho khối công nghệ. Sau một năm, một Agile Coach được mời vào đánh giá. Bề ngoài mọi thứ "chuẩn": Daily đúng 15 phút, Sprint hai tuần, có Sprint Review, có Retrospective, board đầy đủ.
Nhưng Coach nhận ra các smell sau khi ngồi quan sát hai Sprint:
- Daily Scrum: ba người lần lượt đọc "hôm qua tôi làm X, hôm nay tôi làm Y" như đọc kinh, không ai phản ứng, không ai nhắc tới mục tiêu Sprint — vì không có mục tiêu Sprint nào được đặt ra.
- Sprint Review: không có sản phẩm chạy được để demo; PO chiếu vài slide, các bên gật gù, không có người dùng thật nào tham gia, không có feedback nào được ghi nhận.
- Retrospective: cùng một vấn đề "môi trường staging hay sập" được nêu năm Sprint liên tiếp, không ai xử lý.
Cách chữa của Coach không phải thêm quy trình mà là bơm lại linh hồn. Bắt đầu từ điều nhỏ nhất: mỗi Sprint phải có đúng một mục tiêu Sprint viết thành một câu, dán lên đầu board. Daily chỉ hỏi đúng một câu: "Chúng ta có đang đi đúng hướng tới mục tiêu này không, nếu không thì điều gì cản trở?" Với Review, ép buộc phải có một thứ chạy được trên môi trường thật để demo, dù nhỏ. Với Retro, mỗi buổi chỉ chọn đúng một action, có tên người, có deadline, và Sprint sau kiểm tra lại đầu tiên.
Bài học: Làm đúng nghi lễ không có nghĩa là Agile. Khi mọi sự kiện vẫn diễn ra đều đặn nhưng không sinh ra mục tiêu, không sinh ra sản phẩm, không sinh ra cải tiến — đó là Zombie Scrum. Chữa nó bằng cách hỏi "vì sao" cho từng nghi lễ, chứ không thêm nghi lễ.
Hướng dẫn từng bước
Đây là quy trình thực dụng để chẩn đoán và xử lý antipattern trong một đội bất kỳ.
Bước 1 — Quan sát im lặng trước khi phán xét. Trong 1-2 Sprint đầu, đừng vội thay đổi gì. Ngồi dự Daily, Planning, Review, Retro như một người quan sát. Ghi lại các smell cụ thể: con số (velocity dao động, Daily kéo dài bao phút), hành vi (ai nhìn ai khi nói), mẫu lặp (carry-over Sprint nào cũng có không).
Bước 2 — Gom smell thành cụm. Một smell đơn lẻ chưa nói lên gì. Hãy nhóm chúng. "Tester rảnh đầu Sprint" + "test dồn cuối" + "carry-over đều đặn" = Mini-Waterfall. Nhìn theo cụm giúp bạn tìm đúng antipattern thay vì chữa từng triệu chứng rời rạc.
Bước 3 — Truy về nguyên nhân gốc. Dùng kỹ thuật 5 Whys (hỏi "tại sao" năm lần). "Tại sao test dồn cuối Sprint?" → "Vì dev code xong mới giao tester." → "Tại sao giao trễ?" → "Vì story quá to, làm cả Sprint mới xong." → "Tại sao story to?" → "Vì không ai biết chẻ nhỏ story." À — gốc rễ là kỹ năng chẻ story, không phải kỷ luật của tester.
Bước 4 — Ưu tiên một antipattern để chữa. Đừng cố sửa hết. Chọn một cái đau nhất, dễ tạo thắng lợi nhanh nhất. Đội nhìn thấy một cải tiến thật sẽ tin và hợp tác cho lần sau.
Bước 5 — Đưa vào Retrospective, để đội tự sở hữu giải pháp. Đừng áp đặt. Trình bày smell bạn quan sát (dữ liệu, không phán xét người), để đội tự nhận ra và tự đề xuất thử nghiệm. Một thay đổi do đội tự chọn sẽ bền hơn nghìn lần một mệnh lệnh.
Bước 6 — Đo lại sau 2-3 Sprint. Smell đã giảm chưa? Carry-over giảm chưa? Nếu chưa, quay lại Bước 3 — có thể bạn chẩn đoán sai gốc rễ.
Lỗi thường gặp & mẹo
Lỗi 1 — Chữa smell thay vì chữa antipattern. Daily dài 35 phút, bạn ra lệnh "cấm nói quá 1 phút mỗi người". Smell biến mất, nhưng nguyên nhân (đội dùng Daily để báo cáo cho sếp vì sợ) vẫn còn, sẽ trồi lên ở chỗ khác. Luôn hỏi "vì sao" trước khi can thiệp.
Lỗi 2 — Săn antipattern như săn phù thủy. Một số Scrum Master mới học bài này xong đi quanh chỉ trỏ "cái này là antipattern, cái kia là smell" với giọng phán xét. Điều này phá hủy lòng tin. Antipattern là vấn đề hệ thống, không phải lỗi của một cá nhân. Hãy nói về dữ liệu và mẫu hành vi, đừng đổ lỗi con người.
Lỗi 3 — Tin rằng "đúng Scrum Guide" là đủ. Bạn có thể tuân thủ 100% Scrum Guide mà vẫn rơi vào Zombie Scrum. Tuân thủ hình thức không bằng đạt được kết quả. Luôn hỏi: nghi lễ này có đang tạo ra giá trị thật không?
Lỗi 4 — Cố sửa tất cả cùng lúc. Một đội đang có 6 antipattern, bạn lao vào sửa cả 6 trong một Sprint. Kết quả: đội rối loạn, kháng cự, không cái nào chữa xong. Mỗi lần một thứ.
Mẹo nhỏ giá trị:
- Lập một "danh sách mùi" của riêng đội bạn — các smell đặc thù bạn từng gặp — và rà soát định kỳ mỗi quý.
- Carry-over và velocity dao động mạnh là hai chỉ báo sớm rẻ tiền nhất, để mắt tới chúng đầu tiên.
- Nếu một action item Retro xuất hiện lần thứ hai mà chưa xong, đó là smell của Theater Retro — xử lý ngay.
- "Chúng ta luôn làm thế này" là câu nói báo hiệu một antipattern đã đóng băng thành văn hóa.
Bài tập thực hành
Bài 1 — Lập bản đồ mùi. Lấy đội hiện tại của bạn (hoặc đội gần nhất bạn từng làm). Viết ra ít nhất 5 smell cụ thể bạn quan sát được, kèm bằng chứng định lượng nếu có (con số phút, số carry-over, tần suất). Quan trọng: chỉ ghi quan sát, chưa kết luận.
Bài 2 — Từ smell tới chẩn đoán. Với 5 smell ở Bài 1, gom chúng thành cụm và đặt tên antipattern cho mỗi cụm (tham chiếu Top 10 ở trên, hoặc tự đặt nếu không khớp). Một đội thường có 2-3 antipattern chủ đạo.
Bài 3 — 5 Whys. Chọn antipattern đau nhất từ Bài 2. Chạy 5 Whys cho tới khi chạm nguyên nhân gốc thực sự (thường là về kỹ năng, cấu trúc tổ chức, hoặc nỗi sợ — hiếm khi là "lười").
Bài 4 — Thiết kế một thử nghiệm. Viết một thử nghiệm cải tiến nhỏ cho antipattern đó, theo định dạng: "Chúng tôi tin rằng nếu làm X, thì chỉ số Y sẽ cải thiện. Chúng tôi sẽ đo sau 2 Sprint." Đây chính là cách bạn sẽ trình bày trong Retrospective thật.
Tóm tắt
Antipattern là một giải pháp trông hợp lý nhưng gây hại; smell là dấu hiệu bề mặt cảnh báo vấn đề sâu hơn. Kỹ năng quan trọng nhất của bài này không phải thuộc danh sách 10 antipattern, mà là khả năng ngửi mùi — đi từ triệu chứng dễ thấy đến chẩn đoán đúng gốc rễ.
Những điểm cốt lõi cần khắc ghi:
- Bề ngoài Agile không bằng bên trong Agile. Mini-Waterfall, Zombie Scrum, Water-Scrum-Fall đều "đúng nghi lễ" mà vẫn hỏng.
- Velocity dao động mạnh và carry-over đều đặn là hai chỉ báo sớm rẻ nhất, hãy để mắt đầu tiên.
- Đừng vũ khí hóa velocity — biến thước đo nội bộ thành KPI so sánh là cách nhanh nhất phá nát chất lượng (định luật Goodhart).
- Chữa gốc, không chữa ngọn — luôn chạy 5 Whys trước khi can thiệp.
- Antipattern là vấn đề hệ thống, không phải lỗi cá nhân — chẩn đoán bằng dữ liệu, không đổ lỗi con người; để đội tự sở hữu giải pháp qua Retrospective.