Những ngộ nhận khi làm Agile hay tôi đã thất bại với Agile như thế nào?
Cho đến thời điểm này, team của mình đã áp dụng Agile hơn 1 năm. Với những bạn đã từng triển khai ở nhiều tổ chức, chắc đồng ý với mình rằng áp dụng Agile là một quá trình và cần thời gian để chứng minh hiệu quả. Mình đã có rất nhiều ngộ nhận về Agile, đây vừa là những trở lực vừa là những bài học thú vị mà mình xin chia sẻ trong bài viết này.
Áp dụng Agile không chỉ là câu chuyện nội bộ của team Phát triển, nó là của tổ chức.
Mình biết và hứng thú với Agile khoảng 7 năm trước, khi đang chán ngán mô hình waterfall với sự thiếu linh hoạt của nó khi làm sản phẩm. Bởi vậy mình đã không ít lần áp dụng Agile ở các công ty cũ là VCCorp và Alimama. Bản chất Agile không phải là một phương pháp, Agile là tư tưởng và quy tụ các phương pháp phát triển cùng tư tưởng. Bởi vậy áp dụng Agile, không chỉ dừng lại việc áp dụng một phương pháp trong Agile Family, mà bạn đang áp dụng một tư tưởng mới. Chấp nhận tư tưởng của Agile là câu chuyện của cả tổ chức chứ không chỉ giới hạn trong một team làm Phát triển sản phẩm của mình.
Khi triển khai Agile gần đây nhất, mình rút ra điều đầu tiên khiến mình thất bại trước đây bởi mình đã đóng khung việc áp dụng Agile chỉ trong nội bộ đội Phát Triển Sản Phẩm của mình (hay team phát triển ứng dụng, team phần mềm… ở các công ty khác). Tại sao vậy?
Tư tưởng Agile đề cao sự chủ động của các cá nhân và tính cộng tác của các đối tượng tham gia phát triển, sự cộng tác là điểm quan trọng tạo nên hiệu quả khác biệt của team Agile — điều này ghi trong mọi tài liệu về Agile. Thoạt nghe, nó rất phi lý trí mà mình nói đùa là Chủ Nghĩa Xã Hội trong phát triển phầm mềm. Bởi vậy nếu các lãnh đạo của tổ chức không đặt lòng tin vào Agile, Agile không thể thực hiện được chứ chưa nói nó có thể mang tới hiệu quả. Trước đây khi mình áp dụng Agile, vì điều kiện tổ chức đã có hoặc vì bản thân không nhìn nhận vấn đề này, cách đánh giá nhân sự của mình vẫn theo lối tư duy cũ. Việc đề cao vai trò cá nhân hơn nhiều lần kết quả của cả team cùng với thiếu ghi nhận sự trưởng thành của team dẫn tới hiển nhiên các thành viên không quá coi trọng teamwork. Thực tế cho thấy, các sprint thất bại có rất nhiều yếu tố mà mình gọi là hiện tượng “Swimming lane” — mỗi thành viên bơi một làn hoàn thành công việc của cá nhân mình nhưng không hoàn thành công việc chung. Tư duy này phải mất rất nhiều thời gian team mình mới khắc phục được.
Sự cộng tác không chỉ giới hạn trong nội bộ đội PTSP mà tất yếu cả các phòng ban khác trong công ty. Điều này khá dễ hiểu bởi đơn giản đây là các khách hàng của đội PTSP. Phần lớn quãng thời gian trước tháng 3/2016 đổ về trước, đội PTSP Alimama luôn phải đối mặt với các yêu cầu gấp và không có sự lựa chọn. Nó phá vỡ hoàn toàn cấu trúc sprint, việc áp dụng Kanban cũng không cải thiện được quá nhiều và thực tế sự lãng phí là rất lớn, cả yêu tố vật chất lẫn tinh thần. Điều này là kết quả của việc thiếu minh bạch hay nói giảm nhẹ hơn là sự cung cấp thông tin không liên tục, tư duy yêu cầu — thực thi đến từ chính ban lãnh đạo Alimama mà mình là một phần trong đó. Nếu không thay đổi điều này, các phòng ban và các lãnh đạo khác không có hiểu biết về Agile cũng như cam kết với nó, Agile thất bại từ trong trứng nước.
Agile không nhanh chóng mang đến sự thay đổi như kỳ vọng. Đây là một vấn đề lớn, thay đổi bao gồm đánh đổi, vậy sự kiên nhẫn của ban lãnh đạo với thay đổi này là bao lâu? Những lần áp dụng trước, mình đặt thời hạn cho điều này trong 2–4 sprint, tương đương với 1–2 tháng. Nó quá nhanh và thực tế chẳng bao giờ team có các sprint thành công trong thời gian trên. Thời gian là thứ sa sỉ với các công ty nhỏ như Alimama (trước đây) và Shippo (hiện tại).
Scrum Master không cần chuyên biệt, team nhỏ giải pháp kiêm nghiệm là tối ưu.
Đây là một sai lầm dạng cố chấp. Mặc dù nhận được không ít lời khuyên hoặc dẫn chứng về vị trí Scrum Master (SM) cần độc lập và không kiêm nghiệm. Tuy nhiên với mong muốn tối ưu nguồn lực, mình bố trí vị trí SM kiêm nghiệm một vai trò trong dev team. Đó có thể là tester hoặc developer. Với các “sư phụ” Scrum/Agile khi đọc điều này chắc chẳng cần giải thích thêm về những “thiệt hại” của cách làm này mang lại. Vô hình chung, SM phần lớn dành thời gian trong sprint làm việc như dev team. Khi không đứng ngoài guồng quay, dễ hiểu rằng các SM gần như chẳng quan sát hay đánh giá được tình hình của team. Chức năng facilitator trong các events mờ nhạt, thay vào đó SM thực hiện vai trò dev team trong các events này. Tệ hơn nữa khi không có được vị trí SM chuyên tâm và chuyên nghiệp khiến mình phạm một sai lầm lớn hơn khi can thiệp vào việc cải tiến. Nó dẫn tới xuất hiện các cải tiến mà team không cần thiết hoặc không hiểu được mục đích dẫn tới mất động lực, action hời hợt, không mang lại hiệu quả.
Đối với các bạn ở vị trí kiêm nghiệm, có lẽ với các bạn sẽ quan niệm SM không phải là một con đường sự nghiệp mà các bạn sẽ cần đặt lộ trình để phát triển. Bản thân sự kiêm nghiệm cũng thể hiện sự thiếu cam kết của tổ chức đối với vị trí này. Vai trò SM sẽ càng mờ nhạt, và nó càng khiến tổ chức thiếu tin tưởng hơn ở một vị trí quản lý đặc biệt.
Áp dụng Agile chỉ đơn giản áp dụng Scrum
Sai lầm này không biết có phổ biến không, tuy nhiên các lần áp dụng Agile thất bại đều với Scrum. Bởi bản thân việc đóng khung công việc trong một sprint dẫn tới chính Scrum trở nên thiếu linh hoạt với các thay đổi của thị trường và vấn đề phát sinh từ sản phẩm. Scrum quá phổ biến tới nỗi cá nhân mình quên luôn việc xem xét các phương pháp khác trong Agile Family. Hiện giờ bên mình đang áp dụng Scrumban, tuy nhiên giữ đủ các event của Scrum và hạn chế thay đổi sprint backlog ở mức < 20%, các bạn có thể gọi nó là một dạng Scrumbut.
Tiếp đến, cá nhân mình nghĩ áp dụng Scrumban chỉ đơn giản tuân thủ framework. Khá khó để đảm bảo sprint hoàn thành mục tiêu (thành công), vấn đề team mình gặp nặng nề nhất là lỗi. Lỗi gây xáo trộn và gần như khó ước lượng được thời gian thực hiện trong sprint. Đối với công ty làm và duy trì sản phẩm như Alimama và Shippo, lỗi luôn đòi hỏi phải xử lý gấp. Theo lời khuyên của Nguyển Hiển — tác giả Agile Y, cách duy nhất để team đạt được các sprint thành công là áp dụng các kỹ thuật của XP. Đó là lý do vì sao team Shippo hiện tại đang áp dụng TDD và BDD trong việc phát triển. Trong thời gian đầu áp dụng, đây là một yếu tố kéo tiến độ triển khai xuống 1/2. Bởi vậy cá nhân mình khá e dè với TDD và BDD.
Refactor, trả nợ technical debt có thể diễn ra trong từng sprint
Thực tế bên mình chưa áp dụng các đánh giá về technical debt để có so sánh với hiệu quả các thay đổi. Tuy nhiên trước đây mình quan niệm việc phát triển và tái cấu trúc diễn ra song song mà vẫn đảm bảo được mục tiêu của sprint. Thực tế việc này là quá khó đối với team, kể cả khi đã có TDD hay BDD. Rất dễ hiểu dev team chỉ có thể tập trung vào việc phát triển hoặc tái cấu trúc giải quyết nợ kỹ thuật trong các sprint độc lập. Cả sprint kỹ thuật không nâng cấp hay phát triển thêm chức năng thực sự không dễ chịu dưới áp lực phát triển thật nhanh của các nhóm startup. Vì vậy đối với ban lãnh đạo Shippo, có thể nói nó là sự hi sinh khá lớn.
Tất cả các nhóm phát triển đều thích và muốn áp dụng Agile.
Mình thích Agile, nhưng cũng sai lầm khi cho rằng tất cả thành viên team PTSP đều thích nó. Cá nhân mình đã gặp một trường hợp developer — thậm chí là một developer giỏi — không hề muốn làm việc trong môi trường Agile. Thật khó để giải thích, nhưng nó cho thấy không phải ai cũng mong muốn áp dụng Agile. Đánh đổi là điều tất yếu.
Cuối cùng
Cá nhân mình, Agile đã không chỉ còn ở trong phạm vi công việc. Agile đã thay đổi mình khá nhiều, từ sự chấp nhận cải tiến hài hòa hơn, chấp nhận sự đa dạng trong suy nghĩ và khả năng của các đồng sự tới thay đổi cả quan niệm cá nhân mình về công việc và đời sống. Mỗi tổ chức nói chung hay các team phát triển nói riêng sẽ có gặp các vấn đề khác nhau khi áp dụng Agile. Trên là các chia sẻ câu chuyện của mình với team PTSP Shippo và Alimama (trước đây), hi vọng nó mang điều gì đó có ích với các bạn đang bắt đầu với Agile.
Lưu Trọng Hiếu
