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
