Sai lầm lớn nhất của Agile Transformation: Khi doanh nghiệp biến chuyển đổi thành một dự án

Có một nghịch lý mà chúng tôi thường xuyên quan sát thấy khi đồng hành cùng các chương trình Agile Transformation.

Càng đầu tư bài bản cho chương trình chuyển đổi, khả năng đạt được kết quả như kỳ vọng đôi khi lại càng thấp.

Điều này nghe có vẻ mâu thuẫn.

Bởi nếu một doanh nghiệp có ngân sách, có sự cam kết của lãnh đạo, có đội ngũ được đào tạo Scrum, sử dụng Jira, xây dựng roadmap rõ ràng và thuê đơn vị tư vấn giàu kinh nghiệm, đáng lẽ xác suất thành công phải cao hơn.

Nhưng thực tế lại không hoàn toàn như vậy.

• Sprint vẫn diễn ra đều đặn.
• Product Backlog ngày càng đầy đủ.
• Scrum Master và Product Owner đều đã được đào tạo.
• Các dashboard ngày càng đẹp hơn.

Nhưng: 

• Khách hàng vẫn phải chờ.
• Time-to-Market gần như không cải thiện.

Đó cũng là lúc nhiều lãnh đạo bắt đầu đặt câu hỏi:

"Chúng ta đã làm rất nhiều. Vậy tại sao doanh nghiệp vẫn chưa nhanh hơn?"

Các nhóm phát triển vẫn mất nhiều thời gian chờ phê duyệt, chờ môi trường triển khai hoặc chờ các bộ phận hỗ trợ hoàn thành công việc.

Nếu điều này nghe quen thuộc, rất có thể vấn đề không nằm ở Scrum. Vấn đề nằm ở cách chúng ta nhìn nhận chính hành trình chuyển đổi.

Agile Transformation không phải là một dự án

Đây là một trong những hiểu lầm phổ biến nhất.

Một dự án luôn có:

• phạm vi xác định,
• kế hoạch rõ ràng,
• ngân sách cố định,
• ngày bắt đầu,
• ngày kết thúc.

Trong khi đó, Agile Transformation bắt đầu bằng một mục tiêu rõ ràng, nhưng không phải bằng một lời giải hoàn chỉnh.

Doanh nghiệp có thể biết mình muốn rút ngắn Time-to-Market, tăng khả năng thích ứng hay xây dựng Product Operating Model.

Nhưng rất ít tổ chức có thể xác định ngay từ đầu tất cả những thay đổi cần thực hiện để đạt được mục tiêu đó.

Chỉ khi bắt đầu thay đổi, doanh nghiệp mới dần nhìn thấy những điểm nghẽn trước đây bị che khuất: quyền ra quyết định, dependency giữa các phòng ban, quy trình phê duyệt hay những rào cản trong mô hình vận hành.

Vì vậy, giá trị của Agile Transformation không nằm ở việc thực hiện đúng kế hoạch ban đầu, mà ở khả năng liên tục học hỏi và điều chỉnh khi tổ chức hiểu rõ hơn về chính mình.

Scrum không làm doanh nghiệp Agile hơn. Scrum làm doanh nghiệp nhìn thấy sự thật.

Một trong những trải nghiệm thú vị nhất khi đồng hành cùng các chương trình Agile Transformation là điều xảy ra sau vài Sprint đầu tiên.

Ban đầu, nhiều lãnh đạo kỳ vọng Scrum sẽ giúp các nhóm phát triển nhanh hơn.

Sau vài Sprint đầu tiên, doanh nghiệp thường nhìn thấy rất nhiều điểm nghẽn vốn đã tồn tại từ trước:

• Product Owner chưa thực sự có quyền quyết định;
• Release phải qua nhiều cấp phê duyệt;
• Product Team phụ thuộc vào Platform, Security hoặc Infrastructure;
• Thời gian chờ nhiều hơn thời gian tạo ra giá trị.

Những điểm nghẽn này không phải do Scrum tạo ra.

Chúng đã tồn tại từ lâu.

Khác biệt là trước đây chúng thường bị che khuất bởi các kế hoạch dài hạn hoặc được xem như "cách tổ chức vẫn vận hành".

Scrum chỉ khiến chúng trở nên minh bạch hơn.

Và đó chính là giá trị lớn nhất của Scrum.

Scrum không hứa hẹn loại bỏ mọi điểm nghẽn. Scrum giúp tổ chức nhìn thấy những điểm nghẽn mà trước đây họ chưa thực sự đối diện.

Khi những vấn đề ấy đã được nhìn thấy, tổ chức mới có cơ hội cải thiện chúng.

Đó cũng là lý do nhiều doanh nghiệp triển khai Scrum rất bài bản nhưng Time-to-Market vẫn không thay đổi.

Vấn đề không còn nằm ở cách một nhóm làm việc.

Mà nằm ở cách toàn bộ hệ thống hỗ trợ hoặc cản trở việc tạo ra giá trị.

Một bài học thú vị từ một doanh nghiệp phần mềm quốc tế

Trong quá trình nghiên cứu các mô hình chuyển đổi Agile trên thế giới, tôi đặc biệt ấn tượng với một doanh nghiệp phần mềm đã chia sẻ hành trình của mình thông qua Scrum.org. 

Điều đáng chú ý không phải là họ áp dụng Scrum.

Điều đáng chú ý là họ đã áp dụng tư duy Scrum cho chính quá trình chuyển đổi.

Thay vì cố gắng thiết kế một "kế hoạch hoàn hảo", họ coi chương trình chuyển đổi như một sản phẩm đang được phát triển.

Điều đó có nghĩa là:

• Những cải tiến cần thực hiện được đưa vào một backlog.
• Các ưu tiên được xem xét và điều chỉnh thường xuyên.
• Sau mỗi chu kỳ, tổ chức đánh giá điều gì tạo ra giá trị, điều gì chưa hiệu quả và quyết định bước tiếp theo dựa trên dữ liệu thực tế.

Đây là điểm khiến tôi dừng lại suy nghĩ.

Nếu Scrum được tạo ra để phát triển sản phẩm trong môi trường nhiều thay đổi, tại sao chính quá trình chuyển đổi tổ chức – vốn còn nhiều bất định hơn – lại được quản lý theo cách tuyến tính?

BitTrain Flow Optimization Cycle™

Qua nhiều chương trình Agile Coaching và Agile Transformation, BitTrain nhận thấy một điểm chung ở những doanh nghiệp chuyển đổi thành công.

Họ không bắt đầu bằng việc lựa chọn Scrum hay SAFe®.

Họ bắt đầu bằng việc quan sát cách giá trị đang chảy trong tổ chức.

BitTrain gọi đó là Flow Optimization Cycle™.

Quan sát dòng chảy giá trị → Xác định điểm nghẽn → Trao năng lực cho đội ngũ → Đo lường giá trị khách hàng → Tiếp tục cải tiến

Điều BitTrain thường quan sát thấy phần lớn tổ chức không gặp vấn đề ở Scrum Team.

Điểm nghẽn thường xuất hiện ở cấp độ hệ thống.

• Decision – Quyền ra quyết định vẫn tập trung, khiến Product Team chưa thực sự được trao quyền.
• Dependency – Một tính năng phải đi qua nhiều nhóm và nhiều điểm bàn giao trước khi đến tay khách hàng.
• Operating Model – Cơ chế quản trị, phê duyệt và phối hợp giữa các bộ phận chưa được thiết kế để tối ưu Flow of Value.

Đây chính là những loại rào cản mà Flow Optimization Cycle™ hướng tới giúp doanh nghiệp phát hiện và cải thiện.

BitTrain Transformation Lens™: 5 câu hỏi dành cho lãnh đạo

Trước khi đầu tư thêm vào công cụ hay đào tạo, hãy thử trả lời năm câu hỏi sau:

1. Đội ngũ sản phẩm có thực sự được trao quyền ra quyết định không?
2. Giá trị bị dừng lại lâu nhất ở khâu nào trong toàn bộ hành trình từ ý tưởng đến triển khai?
3. Sau mỗi Sprint, tổ chức đã học được điều gì và thay đổi điều gì?
4. Bao nhiêu thời gian của đội ngũ đang dành cho cải tiến hệ thống thay vì chỉ xử lý công việc hiện tại?
5. Chúng ta đang đo lường số lượng hoạt động Agile hay kết quả kinh doanh mà Agile mang lại?

Nếu phần lớn câu trả lời còn khiến bạn do dự, rất có thể chương trình Agile Transformation của tổ chức vẫn đang tập trung vào "thực hành Scrum" nhiều hơn là "xây dựng năng lực thích ứng".

Bài học

Điều đáng học từ những câu chuyện chuyển đổi thành công không phải là sao chép cách một doanh nghiệp khác tổ chức Sprint hay xây dựng backlog.

Điều đáng học là cách họ học hỏi và thay đổi liên tục.

Khi coi chuyển đổi là một quá trình học hỏi liên tục thay vì một dự án có ngày kết thúc, doanh nghiệp sẽ bắt đầu đưa ra những quyết định khác: ưu tiên khác, đo lường khác và đầu tư khác.

Agile Transformation không phải là một dự án có ngày kết thúc. Đó là quá trình doanh nghiệp từng bước loại bỏ những rào cản đang làm chậm dòng chảy giá trị.

Nếu ngày mai tất cả Scrum Team của bạn đều tăng Velocity thêm 20%. Liệu khách hàng có nhận được sản phẩm nhanh hơn không?

Nếu câu trả lời vẫn là "không". Có lẽ điều cần thay đổi không còn nằm ở Team. Mà nằm ở cách toàn bộ tổ chức đang vận hành.

Đó cũng là lúc Agile Transformation thực sự bắt đầu.