Agile là thứ vô nghĩa

Agile là thứ vô nghĩa

Tôi đã dành lượng thời gian rất đáng kể để biết lý do tại sao các mô hình lấy cảm hứng từ Agile “hoạt động được” – hầu hết là phải tự lao vào làm theo, nhưng tôi cũng tự nghiên cứu thêm, tham gia các nghiên cứu theo nhóm, tới các hội thảo, tham gia vào các cộng đồng, và học để biết điều gì có tính chất quyết định nhất khiến nó không hoạt động.

Nhưng gần đây tôi nhận ra rằng với bất kỳ người bình thường nào – mà không được thực hành nhiều theo mô hình này trong thế giới thực để xem cách nó hoạt động – thì Agile hoàn toàn vô nghĩa. Ghép nối lại ư? Cậu đang đùa tôi đấy à? Một đám đông ư? OK, giờ cậu thực sự điên rồi. Release một phiên bản sản phẩm tệ hại nhưng có thể dùng được chỉ trong vòng 1 tuần ư? Tại sao? Tìm ra một mục tiêu gần và tiến tới – không cần nhiều tài liệu và lập kế hoạch ư? Thật điên rồ. Mời khách hàng tham gia qui trình ư? Họ sẽ hoảng sợ! Để team tự quản lý, tự tổ chức, và quyết định cần tập trung nỗ lực cải tiến liên tục ở đâu ư? Đây là câu chuyện “Lord of the Flies” (Chúa tể của Những Con Ruồi) sao? Mục tiêu nhóm, chứ không phải mục tiêu cá nhân ư? Cậu là nhà xã hội chủ nghĩa đấy à? …

Nếu nó có ý nghĩa, hẳn mọi người đã đang làm theo nó rồi, phải không?

Chúng ta cứ giả sử Agile là hiển nhiên và trực quan. Thực ra thì không phải thế, trừ khi bạn đang nói tới những ý tưởng mơ hồ mức cao hoặc những thứ xứng đáng gật đầu tán thành. Sử dụng các cụm từ như “Các cá nhân và các tương tác theo qui trình và công cụ”, “Biến an toàn thành điều kiện tiên quyết”. Cả hai cụm này nghe có vẻ hợp lý – thậm chí rất tuyệt vời – nhưng một qui trình nhẹ nhàng và một nền “văn hóa mở” của một người có khi lại là thứ quan liêu và “văn hóa sợ hãi/đe dọa” với người khác. Vì thế bạn sẽ gặp thách thức với mấy từ to tát trơn tuồn tuột này.

Agile không hề cho thấy cảm giác trực quan trong nhiều hệ thống vì tôi tin rằng Agile tập trung vào tính bền vững và khả năng tồn tại lâu dài (“các qui trình Agile thúc đẩy phát triển bền vững. Các nhà tài trợ, developers và người dùng đều có khả năng duy trì theo một tốc độ không đổi vô thời hạn.”) Lợi ích sẽ không đến ngay lập tức, và trong ngắn hạn bạn sẽ trải qua một vài khó chịu cùng bất mãn. Chẳng hạn, một dự án tập trung vào chất lượng sẽ thực sự thành công khi sản phẩm trở nên phức tạp một cách điên rồ và bạn có thể tiếp tục đổi mới. Liên tục đưa ra những ý tưởng nhỏ vào sản phẩm sẽ thành công khi khách hàng cực kỳ hài lòng với kết quả cuối cùng (do được học và xoay vòng qui trình), chứ không phải khi khách hàng dùng thử phiên bản ghép nối tối giản sau sprint 1 và đưa ra phản hồi. Nếu chủ nghĩa ngắn hạn là thứ bạn đang thể hiện (và hầu hết mọi người đều thế), thì việc tập trung sâu vào Agile không phải là công cụ tốt nhất cho bạn đâu (nhưng có thể tốt nhất với vài người mù mờ đang chạy nước rút).

Thậm chí khi bạn nói chi tiết, cũng có quá nhiều khoảng trống về những hiểu biết được chia sẻ (và một mớ các bất hòa về mặt nhận thức). Tôi nhớ đã nói với một người bạn rằng tôi từng làm việc trong một công ty mà có lẽ chỉ có một vấn đề nhỏ trong sản xuất hàng quí/6 tháng, VÀ họ có một sản phẩm rất thành công. Điều đó đơn giản chỉ là nó không nhảy nhót và đã thực sự đúng với cả thập kỷ kinh nghiệm của họ. Có thứ phải dùng để giải thích cho điều này: các lĩnh vực khác nhau, các kỹ sư khác nhau, công nghệ khác nhau, một chiến lược sản phẩm thành công chứa các góc cắt hợp lý (đã được điều chỉnh dần dần)… Chúng ta chính xác đã ở ngõ cụt. Với nhiều người, Agile là phải có sprint và phải xài Jira. Vì thế họ đã “làm” như thế. Thể loại này là một dạng sùng bái chỉ hoạt động trong các bài viết trên blogs.

Tiếp theo, bạn có một loạt các thành kiến về mặt nhận thức và chui vào cái bẫy trực giác, kiểu như tác động của việc sử dụng quá nhiều tài nguyên, chi phí hàng đợi, những khác biệt giữa sản suất và công việc đầu óc, v.v… (hãy đọc tác phẩm của Don Reinertsen để biết thêm: The Principles of Product Development Flow for a non-dogmatic summary of traps  - Nguyên tắc PDF (Luồng phát triển sản phẩm) để tóm tắt một cách không giáo điều các cạm bẫy). Gợi ý: ngay cả khi mọi người đã đọc cuốn sách này, họ cũng sẽ biết rằng nó có quá nhiều lý thuyết mà thiếu cả tấn ngữ cảnh.

Cuối cùng, luôn có thách thức về tính nhanh nhạy trong toàn bộ tổ chức. Các nhà quan sát chuyên nghiệp đã nhanh chóng nhận ra rằng tính nhanh nhạy ở cấp độ một đội nhóm (team level) là một phần của bài toán. Ngay cả khi Agile ở cấp độ team có ý nghĩa thì bạn cũng cần các phần khác để làm nó thực sự có giá trị. Phần còn lại của tổ chức có lẽ là những người đã chặn nó ngay từ đầu.

Một khi bạn đã nắm bắt được ý tưởng rằng Agile chẳng có ý nghĩa gì, thì bạn có thể bắt đầu thực hiện một việc tốt hơn: đó là hỗ trợ các thử nghiệm tiến hành với các mô hình Agile nổi tiếng. Bước đầu tiên là bỏ chiếc mũ của Kẻ Thuyết Giảng xuống. Thật vô nghĩa khi bạn cứ tuyên truyền những thứ không có ý nghĩa… bạn sẽ được gọi là một kẻ Dị Giáo (và chúng ta đã biết điều gì sẽ xảy ra cho những kẻ dị giáo). Tương tự, đừng làm Acolyte (người cầm nến phụ giúp cho linh mục). Mọi người không tin tưởng những kẻ theo đuổi những điều vô nghĩa. Đừng đề cập tới các thứ đã làm ở công ty khác… vì “nó sẽ không hoạt động ở đây” (và nó biến bạn trở nên nổi bật và độc tài). Quan trọng nhất: lật ngược quan điểm của bạn từ “Tôi là người đã biết ở đây… còn họ không hiểu gì cả” thành “điều này không có ý nghĩa… điều này chỉ dành cho tôi.”

Bạn có thể làm gì đây?

Thứ nhỏ nhất có thể làm tăng giá trị (và có ý nghĩa) là gì? Standup meeting tốt hơn ư? Retrospective tốt hơn ư? Mời khách hàng tham gia một buổi demo ư? Ghép lại trong một ngày ư? Thống nhất đạt được một cái gì đó về sản phẩm chỉ trong vài ngày ư? Hãy thử xem. Hãy làm một thứ có ý nghĩa kiểu như “wow, tôi có thấy thấy nó đã tạo ra giá trị thế nào.”

Khi bạn thực hiện phương pháp khiêm nhường này – thay vì “cài đặt” một đống các thứ, công cụ, rồi xây dựng một đống các vai trò, và nghi lễ AKA để làm Agile – thì tôi nghĩ bạn đang dần nắm được tinh thần thực sự của Agile.

John Cutler

Ngày 28 tháng 1 năm 2018

Theo https://hackernoon.com