Badgile — Những câu chuyện kinh hoàng khi Agile bị áp dụng sai
Last updated: August 01, 2025 Xem trên toàn màn hình
Recommended for you
- 06 Feb 2024
Bài toán Trolley Problem: Hi sinh thiểu số để cứu đa số? 20/144 - 11 May 2021 Khác nhau giữa Padding và Buffer trong quản lý rủi ro dự án 14/829
- 15 Apr 2023 Nghịch lý từ câu chuyện “một chén gạo dưỡng ơn, một đấu gạo gây thù” 11/695
- 09 Aug 2022 Hiệu ứng “rắn hổ mang” (Cobra effect): Khi giải pháp trở thành vấn đề, tưởng vui lại hóa xui 5/493
- 09 Jan 2025 10 Nghịch Lý Cuộc Sống Từ Phim Upstream (nghịch hành nhân sinh): Đối Mặt Rủi Ro Trong Thời Đại VUCA 4/174
- 03 Jul 2025 20 "NGHỊCH LÝ" NHƯNG "THUẬN LÝ" TRONG CUỘC SỐNG 4/46
- 15 Aug 2025 Dự án phần mềm bị trì hoãn và vấn đề "akrasia" 4/34
- 02 Oct 2023 Ngôi Chùa Trăm Năm và Viên Gạch Vỡ: Bài Học Thấm Thía Về Lỗi Nhỏ Trong Bức Tranh Lớn 3/241
- 01 Apr 2025 CTO ra quyết định như thế nào? 3/30
- 06 Dec 2025 Sức mạnh của phương pháp 30-for-30: Bạn đã bao giờ cam kết 30 ngày liên tục cho một mục tiêu? 3/38
- 15 Mar 2024 Tê liệt vì suy nghĩ quá nhiều (Analysis Paralysis) là gì? 3/218
- 01 Aug 2021 Hiện tượng Gold plating (mạ vàng) là gì? Tại sao có ảnh hưởng quyết định đến chất lượng dự án? 3/345
- 22 May 2022 Tư duy ngoài hộp (Thinking out of box) là gì? Tại sao quan trọng với sự phát triển của doanh nghiệp? 3/420
- 08 Aug 2023 Mất kiểm soát phạm vi dự án (Scope Creep) và hiệu ứng quả cầu tuyết (snowball) 2/222
- 12 Jan 2024 Tư duy hệ thống trong Quản Lý Dự Án diễn ra như thế nào? 2/216
- 26 Sep 2024 Đội quân dán nhãn AI của tỷ phú 27 tuổi 2/212
- 01 Jan 2024 Tổng hợp 25 quy luật quan trọng trong quản lý dự án 2/489
- 02 Apr 2025 Anti-Hiring Là Gì? Tại sao các doanh nhân tinh gọn lại nói “KHÔNG” với tuyển dụng? 2/44
- 11 Mar 2025 Thiên hướng Hành động (Bias for Action) và Thiên hướng Quy trình (Bias for Process) tác động tiêu cực tới "đổi mới và sáng tạo" như thế nào? 2/56
- 05 Sep 2025 “Lời Khuyên”: Thuận lý thì ít, nghịch lý thì nhiều. Suy nghĩ không giống nhau thì không nên khuyên nhau. 2/27
- 04 May 2025 Bí quyết nói tiếng Anh lưu loát không cần giỏi 4 kỹ năng văn vở 1/25
- 16 Apr 2025 Lãnh đạo linh hoạt: Hành động (Bias for Action) hay không hành động (Non-Action)? 1/34
- 01 May 2025 Vì Sao Các Cửa Hàng Trung Quốc Không Vội Vã Phục Vụ Khách Hàng? 1/79
- 03 Jul 2025 “Đo ni đóng giày” trong xã hội hiện đại: Xu hướng hay ngược hướng? 1/50
- 11 Sep 2020 Nghịch lý kinh doanh tại Mỹ: Chăm sóc khách hàng không tốt, nhưng công ty lại lãi lớn 1/140
- 10 Sep 2024 Tại sao những thứ chúng ta muốn lại ít khi có được? 1/196
- 03 Sep 2020 Hiệu ứng rắn hổ mang, Luật Goodhart, Campbell & Chuyện thi cử 1/193
- 15 Apr 2025 YouTube đang ủng hộ "Đạo luật No Fakes" nhắm vào các bản sao AI trái phép. 1/153
- 18 Jul 2020 Lợi ích cận biên (Marginal Utility) là gì? Qui luật lợi ích cận biên giảm dần /609
- 16 Feb 2024 Nghịch lý của sự hoàn hảo: AI có thể quá tốt để sử dụng? /167
- 01 Sep 2023 Định luật Goodhart và định luật Campbell - Nghịch lý về thành tích /192
- 10 Aug 2020 Bạn có biết quy tắc thất bại nhanh: Fail early, fail often, fail cheap, but always fail forward /105
Badgile là gì?
Badgile là một từ tôi dùng để mô tả một quy trình Agile "tệ". Tôi để dấu ngoặc kép quanh chữ "tệ" vì đó là một từ khá mạnh — các quy trình vốn dĩ sẽ khác nhau tùy theo từng nhóm và từng hoàn cảnh. Chúng luôn cần được đánh giá và cải tiến, và tôi không có ý cho rằng mình có “công thức thần kỳ” cho Agile. Tôi và nhóm của mình đã cùng xây dựng nên một quy trình mà tôi nghĩ là khá tuyệt, nhưng tôi không bao giờ nghĩ đến việc áp đặt nó nguyên xi lên các nhóm khác trong tổ chức khác.
Một quy trình tốt là việc áp dụng các nguyên tắc lên từng hoàn cảnh cụ thể — kết quả là có thể xuất hiện nhiều biến thể khác nhau ngay cả trong cùng một tổ chức. Khi tôi nói "tệ" hay "sai", ý tôi là nó rõ ràng tệ, là một mớ hỗn độn “bốc mùi”.
Bất cứ ai cũng có thể đặt câu hỏi về tính hiệu quả của ứng dụng quy trình Agile vào doanh nghiệp như:
- Ai cũng nói mình làm Agile – nhưng có bao nhiêu người hiểu đúng?
- Sprint thì có, nhưng backlog không rõ ràng – đó có còn là Agile?
- Hay tất cả chỉ là màn trình diễn để đối phó với cấp trên?
- Vậy bạn đang quản lý dự án hay đang đóng một vở kịch có tên “Giả Agile”?
“Kể cho tôi nghe về quy trình phát triển phần mềm của bạn”
Một trong những câu hỏi tôi luôn hỏi khi phỏng vấn là ứng viên hãy mô tả quy trình phát triển phần mềm của họ. Câu hỏi này thường tiết lộ rất nhiều điều thú vị. Mặc dù ứng viên thường không có nhiều ảnh hưởng đến quy trình (điều này thật đáng tiếc, nhưng sẽ nói sau), câu hỏi này vẫn hé lộ nhiều chỉ dấu quan trọng:
- Ứng viên có mô tả rõ ràng được quy trình (hoặc sự thiếu quy trình) không, ngay cả khi quy trình ấy bản thân nó chưa rõ?
- Cảm xúc của họ về quy trình hiện tại thế nào?
- Họ có tiếng nói gì trong việc thay đổi nó không?
- Họ có thấy bức xúc không?
- Họ đã từng cố gắng cải thiện nó chưa?
- Họ có đang đóng vai “nạn nhân” không?
- Nếu có quyền thay đổi, họ sẽ làm gì?
Một phần lý do tôi hỏi cũng là vì tôi thích nghe về quy trình của các công ty khác — tôi là một "mọt quy trình" (process geek) mà. Và thú thật là có lúc tôi đào quá sâu vào các quy trình thú vị hơn mức cần thiết.
Tôi không đánh giá thấp một ứng viên chỉ vì họ đang làm việc trong một quy trình tệ — tôi hiểu và thường nói với họ rằng họ không cô đơn. Đó cũng là cơ hội để tôi cho họ thấy một tổ chức thực sự áp dụng Agile có thể trông như thế nào.
“Chúng tôi làm Agile!”
Tôi: “Hãy kể cho tôi về quy trình phát triển phần mềm của bạn.”
Ứng viên: “Chúng tôi theo Agile!”
Tôi: “Tuyệt! Hãy nói kỹ hơn, dẫn tôi qua từng bước trong quy trình.”
Ứng viên: “Chúng tôi có họp đứng hàng ngày (daily stand-ups), làm theo chu kỳ sprint.”
Tôi: “Vậy có thể nói là các bạn theo Scrum?”
Ứng viên: “Đúng, chúng tôi theo Scrum.”
Tôi: “OK, vậy Scrum này là theo sách giáo khoa (by the book) hay đã được tùy biến? Bạn hãy nói rõ thêm xem điều gì hiệu quả và điều gì không.”
Ứng viên: [Ngập ngừng] “Scrum… Stand-up… Sprints…”
Tôi: “Sprint của bạn dài bao lâu chẳng hạn?”
Ứng viên: “3 tuần.” — Thường thì là 3 tuần, nhưng cũng có lúc là 8 tuần, thậm chí có nơi là 4–6 tháng!
Và đây là lúc câu chuyện bắt đầu trật bánh. Quy trình chỉ gói gọn trong sprint và stand-up, hoặc bạn bắt đầu nghe đến những thực hành đầy nghi vấn như: việc test thì để đến sau cùng, nhóm thì 45 người (!), sprint thì do quản lý dự án (Project Manager) chọn nhiệm vụ, hoặc buổi stand-up mỗi ngày kéo dài cả tiếng đồng hồ (nhưng “rất hiệu quả”).
Có rất nhiều cờ đỏ (red flags) kiểu đó mà tôi sẽ đề cập trong những bài sau.
Tôi thường rời khỏi cuộc phỏng vấn với cảm giác hụt hẫng. Không phải vì ứng viên, mà vì thực tế đáng buồn là rất nhiều nhóm phát triển phần mềm chẳng tiến bộ là bao trong 10 năm qua. Họ đã rời khỏi mô hình Waterfall với tiến độ giả tạo và các giai đoạn rời rạc, nhưng rồi lại thay thế bằng một thứ Agile tồi tệ — không hiểu, không vận dụng đúng, thậm chí không thể gọi là quy trình.
Kết quả: nhà quản lý căng thẳng, vò đầu bứt tóc, hét vào mặt nhóm để "tăng velocity".
Đây là những câu chuyện có thật
Thật lòng mà nói, tôi không muốn làm việc trong phần lớn những môi trường như vậy. Kỹ sư phần mềm là những người được đào tạo, sáng tạo và chuyên nghiệp — nhốt họ trong “lồng sắt” thì thật vô lý. Họ cần một quy trình giúp họ giang cánh, không phải bị giam cầm. Chúng ta cần kiểu làm việc "nuôi thả tự do" (free-range) chứ không phải "nuôi nhốt công nghiệp" (battery).
Buồn thay, nhiều lập trình viên thậm chí không biết là mình đang sống kiểu đó — họ nghĩ làm việc quá giờ và dự án thất bại là chuyện… đương nhiên.
Stand-ups và Sprints không tạo nên Agile
Tôi đang mượn lời của Aristotle (chứ không phải Yoda), ý tôi là: quá nhiều nhóm chỉ dựng lên một cái vỏ bọc Agile để che giấu thực tế bên trong, nhưng ngay cả cái vỏ đó cũng tệ. Việc thực hiện daily stand-up thiếu hiệu quả và quản lý sprint một cách hời hợt không biến bạn thành Agile, mà biến bạn thành Badgile.
Có rất nhiều lý do khiến các nhóm không thể thiết lập quy trình Agile hiệu quả:
- Thiếu hiểu biết (Lack of understanding)
- Ban lãnh đạo không ủng hộ (No buy-in from executives)
- Nhóm không ủng hộ (No buy-in from the team)
- Thiếu lòng tin vào nhóm (Lack of trust)
- Sợ thay đổi (Fear of change)
- Thờ ơ (Apathy)
Và còn hàng triệu lý do khác. Nhưng điều tồi tệ hơn cả thất bại khi cố áp dụng Agile, là giả vờ áp dụng bằng cách nhét stand-up và sprint vào một nhóm, rồi tuyên bố “chúng tôi đã đạt đến đỉnh cao Agile”, và không bao giờ nhìn lại quy trình đó nữa.
Trong nhiều trường hợp, bạn sẽ làm tốt hơn nếu áp dụng đúng Waterfall thay vì theo kiểu Franken-Agile (một quy trình “quái vật” chắp vá), nơi quy trình đáng lẽ giúp bạn xây dựng phần mềm tốt hơn lại trở thành nghi thức hình thức không mang lại giá trị.
Nếu bạn không đánh giá và cải tiến quy trình, bạn đang sống như “xác sống” (walking dead)
Nếu bạn may mắn, một ngày nào đó bạn sẽ “tỉnh giấc” và tự hỏi: “Mình đang làm cái quái gì vậy?”. Hãy chất vấn và phân tích tất cả, đặc biệt là các bước của Scrum. Scrum là điểm xuất phát — là nơi tốt để bắt đầu hành trình Agile. Nó cung cấp những “lan can an toàn” (guardrails), nhưng nếu sau một năm quy trình của bạn vẫn y nguyên, thì rất có thể bạn không phải đang làm Agile.
Nếu mọi nhóm đều làm y hệt nhau, bạn không Agile. Ưu tiên thay đổi, tổ chức thay đổi, công nghệ thay đổi — và vì vậy quy trình cũng phải thay đổi.
Không có quy trình hoàn hảo
Tôi không nói mình là “thiên tài quy trình” (để người khác đánh giá), nhưng nếu bạn muốn thành công, bạn phải cố gắng thật sự. Nhiều người thích nói mình theo Agile vì nghe “ngầu” hơn nói mình thích Waterfall. Nhưng bạn không thể trở thành The Fonz chỉ vì mặc áo khoác da — trong phép ẩn dụ này, stand-up và sprint là áo khoác da, còn Agile là The Fonz.
Nếu bạn thấy mình đang làm Badgile, dù lý do là gì, bạn có thể thay đổi. Sẽ khó, sẽ có nhiều thử thách, nhưng hãy cố gắng — vì chính bạn, vì tổ chức của bạn, vì cả nhóm của bạn.
Hãy học hỏi, bắt đầu từ Scrum, nhưng phải thực sự bắt đầu từ nó — hiểu triết lý đằng sau, đừng chỉ làm theo nghi lễ (ceremonies). Nếu gặp phản đối, hãy giáo dục người xung quanh. Bạn không phải là kẻ lập dị đang cố áp đặt một quy trình “hippy” — bạn đang đi theo bước chân của những công ty phần mềm hàng đầu thế giới.
Và nếu bạn cố hết sức mà vẫn không thể thay đổi môi trường đó, hãy tìm nơi nào cho phép bạn vươn cánh và thể hiện năng lực thật sự — một nơi có văn hóa tin tưởng và tự do.
Tôi hứa, nó sẽ tốt hơn nhiều!
Khám phá thêm các chủ đề sau
Đọc thêm: Hướng dẫn hợp tác viết bài (guest blogging)
Các chủ đề được quan tâm nhiều nhất
CHIA SẺ BÀI VIẾT
Link copied!
Mới cập nhật