Nguyen Le PhongNguyen Le Phong

Agile đã chết, Agile muôn năm

Agile thường bị tuyên bố là đã chết vì nhiều team đã trải qua quá nhiều ceremony mà không có học hỏi, quá nhiều board mà không có feedback, và quá nhiều cuộc họp mà thiếu trust. Một bài reflection bình tĩnh về vì sao phiên bản Agile mang tính hình thức đáng bị phê bình, trong khi thói quen thích nghi qua những vòng feedback nhỏ và trung thực vẫn rất đáng giữ.

Máy pha cà phê lại chậm, và ba người trong team đang đứng chờ bên cạnh với laptop mở hờ. Một người nhìn vào sprint board trên màn hình, thở ra, rồi nói câu tôi đã nghe ở nhiều văn phòng: Agile chết rồi. Không ai phản đối. Chúng tôi vừa bước ra khỏi một daily standup giống báo cáo trạng thái, một buổi planning nơi estimate được lặng lẽ chỉnh để vừa với một ngày đã chốt, và một buổi retro nơi ai cũng biết vấn đề thật nhưng không ai thấy đủ an toàn để nói thẳng.

Tôi hiểu vì sao câu đó nghe có lý. Nhiều người không gặp Agile như một bộ giá trị về feedback, collaboration và working software. Họ gặp Agile như một lịch đầy ceremony, một Jira board phải luôn sạch, một velocity chart dần biến thành tín hiệu đánh giá hiệu suất, và một bộ từ vựng làm những điều rất đời nghe như chứng chỉ quy trình. Nếu đó là Agile mà ai đó đã sống trong, thì nói nó chết không phải là cay nghiệt. Đó là sự mệt mỏi đang tìm một câu nói thật.

Nhưng tôi cẩn thận với đám tang này. Thứ nhiều team muốn chôn không phải lúc nào cũng là Agile. Thường đó là lớp áo nặng đặt lên trên nó: Scrum trình diễn, sự chắc chắn giả, story point bị đối xử như giờ, retro không có quyền lực, và một văn hoá nơi responding to change được khen trên slide nhưng bị phạt trong buổi review roadmap. Phiên bản đó đáng bị phê bình. Đôi khi nó đáng biến mất.

Ý tưởng lặng hơn ở bên dưới vẫn còn hữu ích. Một team xây một thứ, đặt nó trước thực tế, lắng nghe kỹ, rồi điều chỉnh. Đó không phải một trào lưu. Đó là cách việc học diễn ra. Đó là cách một codebase tốt hơn qua review và refactor. Đó là cách một sản phẩm bớt sai sau khi gặp người dùng thật. Đó là cách một team nhận ra một quy trình đang làm con người mệt và đổi một thói quen nhỏ trước khi tổn hại trở thành bình thường. Một ngày nào đó ta có thể ngừng gọi điều đó là Agile, nhưng nên cẩn thận đừng vứt luôn vòng feedback cùng với cái nhãn.

Điều đã lệch, theo tôi, là Agile trở nên dễ đo từ bên ngoài hơn là dễ thực hành từ bên trong. Rất dễ kiểm tra một team có sprint planning, daily standup, review và retro hay không. Khó hơn nhiều để kiểm tra người trong team có thể bất đồng một cách an toàn không, Product Owner có thật sự hiện diện không, trade-off kỹ thuật có được nghe sớm không, feedback có làm priority thay đổi không, và team có được phép nói rằng điều mình học tuần này làm kế hoạch cũ kém khôn ngoan hơn hay không. Bề mặt thì thấy được. Phần cốt lõi nằm trong quan hệ giữa người với người.

Vì vậy, một vài team lành mạnh nhất tôi từng thấy lại trông ít Agile trên giấy hơn những team quảng cáo điều đó rất lớn. Họ không xem framework là bất khả xâm phạm. Họ bảo vệ ý định phía sau. Planning của họ thực tế, không diễn. Daily của họ ngắn vì board vốn đã trung thực. Retro của họ tạo ra một thay đổi nhỏ có người thật sự chịu trách nhiệm. Estimate là cuộc trò chuyện, không phải hợp đồng. Khi thực tế đổi, họ không xem đó là thất bại của kỷ luật. Họ xem đó là thông tin mới.

Điều ngược lại cũng xảy ra. Một team có thể làm đủ mọi ceremony và vẫn rất waterfall trong tinh thần. Requirement bị đóng băng quá sớm. Quyết định chỉ đi từ trên xuống. Team ship trễ vì không ai muốn đưa rủi ro lên mặt bàn. Mỗi sprint chỉ trở thành một chiếc hộp nhỏ hơn để chứa cùng một nỗi sợ cũ. Ngôn ngữ Agile có thể che nỗi sợ đó một thời gian, nhưng không thể xoá nó. Đến một lúc người ta cảm thấy khoảng cách giữa lời nói và công việc, và câu đùa bắt đầu xuất hiện: Agile chết rồi.

Có lẽ câu tốt hơn là: Agile như một thương hiệu đã mệt, nhưng sự linh hoạt vẫn sống ở bất cứ nơi nào con người được phép học. Nó sống khi một developer nói thiết kế hiện tại sẽ tạo technical debt và căn phòng chậm lại để lắng nghe. Nó sống khi QA được mời vào trước khi story được build, không phải sau khi build đã thành cam kết chính trị. Nó sống khi Product Owner đổi priority vì bằng chứng từ khách hàng đã đổi, và không ai xem đó là yếu đuối. Nó sống khi một manager bảo vệ team khỏi việc giả vờ chắc chắn chỉ để report nhìn sạch hơn.

Kiểu linh hoạt đó không kịch tính. Nó lớn lên bằng tích luỹ âm thầm. Một acceptance criterion rõ hơn. Một lát cắt công việc nhỏ hơn. Một blocker được nói sớm hơn. Một action từ retro thật sự xảy ra. Một cuộc nói chuyện với stakeholder trước khi sprint đã bị nhồi đầy. Không khoảnh khắc nào trong số đó trông như transformation. Cộng lại, chúng tạo ra một team có thể di chuyển mà không tự làm mình gãy.

Vì vậy khi ai đó nói Agile chết rồi, tôi thường không vội bảo vệ chữ Agile. Đôi khi chữ đó đã xứng đáng với phần bực bội gắn vào nó. Tôi muốn hỏi hơn: chính xác thì điều gì đã chết? Nếu thứ chết là ceremony không có trust, tốt. Nếu thứ chết là estimate dùng làm áp lực, tốt. Nếu thứ chết là niềm tin rằng một framework có thể thay thế judgment, càng tốt. Nhưng nếu thứ chết cùng nó là thói quen khiêm tốn kiểm tra thực tế thường xuyên và đổi hướng một cách có trách nhiệm, thì ta đã mất một thứ mình vẫn cần.

Agile có lẽ không cần thêm những người bảo vệ nó thật ồn ào. Nó cần những người thực hành bình tĩnh hơn, sẵn sàng giữ phần hữu ích còn sống mà không biến cái tên thành một căn tính. Công việc không phải là chứng minh Agile vẫn đúng trong mọi căn phòng. Công việc là xây những team nơi feedback đủ an toàn, kế hoạch đủ trung thực, và điều học được có thể thay đổi chuyện xảy ra tiếp theo. Nếu bạn từng ở trong một team nơi Agile có vẻ đã chết, tôi thật sự tò mò điều gì đã giết nó ở đó, và thói quen nhỏ nào, nếu có, đã mang lại một chút sức sống.

Bạn thấy bài viết thế nào?

Câu hỏi thường gặp

Agile có thật sự đã chết không?
Phiên bản Agile nặng hình thức, đầy ceremony và thiếu trust rất đáng bị phê bình, nhất là khi nó biến thành họp báo cáo, sự chắc chắn giả và estimate dùng để gây áp lực. Nhưng thói quen sâu hơn của Agile, như làm từng bước nhỏ, nghe feedback và đổi hướng khi thực tế thay đổi, vẫn rất hữu ích.
Vì sao nhiều team chán Agile?
Nhiều team trải nghiệm Agile như process theater: ceremony không có trust, story point bị xem như giờ, retro không có hành động tiếp theo, và roadmap phạt mọi điều học được sau đó. Sự chán nản thường nhắm vào cách triển khai bề mặt này, không phải các giá trị ban đầu.
Agile và agility khác nhau thế nào?
Agile thường chỉ framework, ceremony và bộ từ vựng có tên gọi. Agility là thói quen làm việc bên dưới: lấy feedback sớm, giữ kế hoạch trung thực, chia công việc đủ nhỏ để học, và thích nghi khi bằng chứng thay đổi.
Làm sao khôi phục agility mà không thêm quy trình?
Bắt đầu bằng những việc nhỏ và lặp lại được: giữ board trung thực, để retro tạo ra một hành động có owner, mời QA và product feedback sớm hơn, xem estimate là cuộc trò chuyện, và tạo đủ an toàn để mọi người nói rủi ro trước khi nó trở nên đắt.