Làn sóng Agile đã càn lướt xong giới phát triển phần mềm, và bắt đầu chiếm lĩnh những diễn đàn vốn dành riêng cho giới quản lí như Harvard Business Review (HBR) hay Forbes. Tất nhiên, người ta đều biết là Agile có chỗ đứng vững chắc trong nhiều lĩnh vực, từ ngành phần mềm, phần cứng, ngành sản xuất ô tô, ngành ngân hàng, ngành hàng không, ngành marketing hay giáo dục. Nhưng câu hỏi đơn giản này luôn làm phiền những sếp quy trình, những COO, CIO hay cả những CEO cấp tiến: “Agile có phù hợp với công ty của mình hay không?”.
Những người có kinh nghiệm thấy ngay rằng không thể trả lời nhanh câu hỏi này. Nhưng chúng ta luôn có những manh mối để suy nghĩ và bắt đầu.
Hãy xuất phát từ phạm vi hẹp: Quản trị dự án. Các giáo sư dạy môn quản trị dự án hiện đại nêu đại khái: Có hai loại dự án cần những cách tiếp cận khác nhau, một là các dự án thuộc loại Thực thi (Execution), một loại ở thái cực kia là các dự án thuộc loại Mới tinh (Novel). Loại Thực thi thì cần lên kế hoạch kĩ, chi tiết, rồi thi hành và kiểm soát thật chặt để đạt được kết quả tốt. Loại Mới tinh thì lại không thể làm thế vì nó ẩn chứa quá nhiều yếu tố không đoán được (uncertainty). Với loại này, một kế hoạch cần có khả năng cập nhật với các phản hồi mới, dữ liệu mới trong quá trình triển khai dự án. Do đó nó nên được thực hiện với khả năng thích ứng tốt, có vòng phản hồi ngắn, và cần sự cộng tác chặt chẽ giữa các bên liên quan, đội dự án cũng được linh hoạt hơn, tự quản nhiều hơn thay vì làm việc thuần túy kiểu “ra lệnh và kiểm soát” (command-and-control). Nói gọn lại, các dự án thuộc típ Thực thi sẽ vẫn hiệu quả tuyệt vời khi chúng ta triển khai theo dạng truyền thống; còn các dự án loại “mới tinh” thì nên sử dụng Agile mới ổn. Chuyện có vẻ rõ như ban ngày.
Tuy nhiên, nhận ra dự án thuộc loại Thực thi hay Mới tinh không bao giờ là hiển nhiên. Một dự án được con người vận hành, luôn tiềm ẩn những yếu tố khó đoán định trong quá trình tương tác nội bộ, tương tác trong-ngoài, tương tác với môi trường; kết quả thì không phải lúc nào cũng dễ dàng hình dung rõ ràng ngay từ lúc lập kế hoạch ban đầu để có thể lên kế hoạch chi tiết và xây dựng cho được một biểu đồ Gantt đẹp đẽ. Còn khi thực thi, môi trường có thể vẫn cứ biến động không ngừng. Hóa ra, nhìn nhận đâu là dự án kiểu gì không hề dễ dàng.
Nói vậy không có nghĩa là giới học thuật và thực hành chưa có những nỗ lực đáng kể để giúp tình hình bớt bế tắc. Trong bài báo mới đây (Embrace Agile) đăng trên HBR, đồng tác giả Scrum, ông Jeff Sutherland cùng với giáo sư Takeuchi ở Đại học Harvard và Darrell K. Rigby đã cung cấp một số lời khuyên hữu ích. Các ông cho rằng Agile phù hợp khi:
- Nhu cầu khách hàng và yêu cầu về giải pháp thay đổi thường xuyên
- Cần cộng tác chặt chẽ với khách hàng và có thể cung cấp các phản hồi nhanh, khách hàng nắm rõ hơn về những gì họ mong muốn
- Vấn đề rất phức tạp, giải pháp không rõ từ đầu và phạm vi cũng không được xác định rõ
- Đặc tả sản phẩm có thể thay đổi, và những sáng tạo đột phá luôn được ưu tiên
- Cộng tác liên-chức năng là sống còn
- Việc phát triển tăng trưởng mang lại giá trị, và khách hàng có thể sử dụng ngay những giá trị này
- Công việc có thể bẻ nhỏ thành từng phần và có thể được thực thi trong những phân đoạn lặp ngắn
- Những thay đổi ở phút chót có thể quản lí được
- Những sai sót có thể mang lại những bài học chứ không mang đến những thảm họa.
Và, Agile có thể không phù hợp trong những điều kiện ngược lại:
- Điều kiện thị trường ổn định và có thể tiên lượng
- Yêu cầu rất rõ ràng và luôn ổn định
- Khách hàng không thể cộng tác thường xuyên
- Công việc tương tự những gì đã làm trước đó, và giải pháp là rất rõ ràng. Đặc tả chi tiết có thể làm ra với sự dự đoán rõ ràng và chính xác. Vấn đề có thể giải quyết tuần tự qua từng bộ phận chức năng mà không gặp trở ngại nào.
- Khách hàng không thể bắt đầu kiểm thử các phần sản phẩm cho tới khi sản phẩm hoàn chỉnh
- Thay đổi phút chót rất tốn kém, hoặc không thể
- Sai sót trong thực thi có thể dẫn đến thảm họa không thể cứu vãn được.
Trong khi những lời khuyên chí tình này xuất phát từ những bộ óc có thừa trải nghiệm với Agile. Trong số họ có cả cha đẻ của Scrum, và “ông nội” của Scrum (ông Takeuchi, đồng tác giả bài báo trứ danh đánh dấu sự ra đời ý tưởng Scrum năm 1986 cũng trên Harvard Business Review, bài báo “The New New Product Development Game”), thì nó cũng chỉ cung cấp lời khuyên kiểu “rule of thumb” cho những người thực hành, mà có thể chưa làm thỏa mãn những người muốn có cái nhìn mang tính kĩ thuật để ra những quyết định quan trọng. Thật may mắn là chúng ta có thể tìm thấy một chút manh mối với mô hình Cynefin, một mô hình nghiên cứu về phức hợp.
Trong bài báo “A Leader’s Framework for Decision Making” trên HBR số Tháng 11 năm 2007, các tác giả Snowden và Boone trình bày một mô hình phân loại thế giới trong các vùng với các đặc điểm tương đối khác nhau với độ phức tạp tăng dần: Hiển nhiên (Obvious), Rắm rối (Complicated), Phức hợp (Complex) và Hỗn độn (Chaotic). Nếu các dự án tính phức tạp là Hiển nhiên hoặc Rắm rối, thì chúng thuộc loại Thực thi đã đề cập ở đầu bài này. Với các dự án có độ phức tạp từ Phức hợp đến Hỗn độn, chúng ta có loại Mới tinh. Dĩ nhiên, chúng đòi hỏi những cách thức suy nghĩ và ra quyết định khác nhau.
Bảng dưới đây tóm tắt những dấu hiệu nhận dạng độ phức tạp cho các bối cảnh khác nhau. Dưới góc nhìn của Cynefin, không có một chiến lược ra quyết định kiểu vạn năng cho các tình huống. Chúng ta cần nhiều hơn một kiểu nghĩ để sử dụng trong các tình huống khác nhau.
Như chúng ta thấy, Agile phù hợp hơn ở vùng Phức hợp (hai cha đẻ của Scrum, Ken Swchaber và Jeff Sutherland cũng đã nhắc lại nhiều lần), nơi có thể vận dụng cách thức thí nghiệm-phán đoán-phản hồi để ra quyết định, trao quyền tự quản cho nhóm, thiết lập các điều kiện ban đầu và luôn tìm kiếm các khuôn mẫu thích ứng có tính tối ưu nổi lên trong quá trình nhóm làm việc tự-tổ-chức. Ở một mức độ nhất định, Agile có thể phù hợp ở vùng Rắm rối, nhưng nói chung, vùng Phức hợp là vùng dễ thấy tính tương thích nhiều nhất.
Dựa trên Cynefin, chúng ta có cái nhìn rõ ràng hơn trong trường hợp nào thì Agile sẽ hiệu quả. Agile rõ ràng không phải là phương thuốc vạn năng, cứ mang vào công ty là thổi bay các vấn đề của tổ chức, hoặc giúp công ty tăng trưởng thần kì.
Tuy vậy, Cynefin vẫn chỉ là một công cụ mang tính kĩ thuật. Và những lời khuyên ở bên trên cũng mang tính kĩ thuật. Nó động đến câu hỏi “phải làm sao” khi ra quyết định Agile hay không Agile. Nhưng việc ra các quyết định trong thực tế lại đòi hỏi chúng ta phải hỏi “tại sao”, “để làm gì” nhiều hơn. Agile để làm gì? Tức là hỏi cái mục đích của việc sử dụng Agile. Xa hơn nữa, là hỏi cái triết lí kinh doanh của nhà lãnh đạo là gì. Câu hỏi này có vẻ hệ trọng hơn câu hỏi hơn câu hỏi chúng ta đã trả lời trong bài này. Bởi theo Steve Denning đã đề cập trong “The Leaders Guide to Radical Management”, Agile mà thiếu đi cái triết lí phù hợp, thì có thể nảy sinh rất nhiều xung đột. Nhưng đó sẽ là một chủ đề khác, chúng ta sẽ trở lại sau.
Dương Trọng Tấn
Giám đốc Học viện Agile.
