Tại sao lãnh đạo doanh nghiệp cần có Tư duy Agile?

Đứng trước môi trường kinh doanh đầy biến động hiện nay, hầu hết các lãnh đạo doanh nghiệp đều ưu tiên gia tăng tính linh hoạt cho tổ chức [1]. Tuy nhiên, để đạt được sự linh hoạt này, không chỉ dừng ở nỗ lực của khối chiến lược hay nghiên cứu phát triển mà cần sự góp sức của từng bộ phận và nhóm để đổi mới sản phẩm, dịch vụ đáp ứng nhu cầu của khách hàng. Phần lớn ngân hàng lớn trên thế giới đã lựa chọn tư duy và các phương pháp làm việc Agile để duy trì tính hiệu quả, an toàn và sự nhanh nhạy cho khối công nghệ thông tin, kinh doanh và vận hành [2].

Để chuyển đổi số thành công hay các mô hình kinh doanh số mới, doanh nghiệp cần áp dụng tư duy Agile ở mức độ tổ chức [3]. Trong đó, người lãnh đạo cần trang bị Tư duy Agile để dẫn dắt doanh nghiệp trở thành một tổ chức số.

Sự biến động của môi trường kinh doanh hiện nay và cuộc cách mạng số

Môi trường kinh doanh ngày càng khắc nghiệt, thời gian trung bình một doanh nghiệp ở trong S&P 500 hiện nay giảm từ 30-35 năm trong thập niên 70 xuống còn 15-20 năm (Chart 1).

Sự biến động của một doanh nghiệp nằm trong S&P 500

Sự khắc nghiệt của môi trường kinh doanh được mô tả bằng cụm từ VUCA, cụ thể: 

• Volatility (Biến động): Biến động đề cập đến tốc độ thay đổi trong một ngành, thị trường hoặc thế giới nói chung. Bao gồm các biến động về nhu cầu, sự hỗn loạn và thời gian ngắn của thị trường. Thế giới càng biến động, mọi thứ càng thay đổi nhanh chóng. 
• Uncertainty (Không chắc chắn): Sự không chắc chắn đề cập đến mức độ mà chúng ta có thể tự tin dự đoán tương lai. Đây là một đặc tính khách quan của môi trường. Môi trường không chắc chắn là môi trường không cho phép bất kỳ dự đoán cũng như cơ sở thống kê nào. Thế giới càng bất định, càng khó dự đoán. 
• Complexity (Phức tạp): Độ phức tạp đề cập đến số lượng các yếu tố cần tính đến, sự đa dạng và mối quan hệ giữa chúng. Càng nhiều yếu tố đa dạng liên kết với nhau, môi trường càng phức tạp. Thế giới càng phức tạp thì càng khó phân tích kỹ lưỡng môi trường và đưa ra kết luận.
• Ambiguity (Mơ hồ): Sự mơ hồ đề cập đến sự thiếu rõ ràng về cách giải thích điều gì đó. Ví dụ, trong tình huống không rõ ràng với thông tin không đầy đủ, mâu thuẫn hoặc không chính xác rất khó để đưa ra kết luận rõ ràng. Thế giới càng mơ hồ, càng khó giải thích.

Như chúng ta đã biết, các ứng dụng, dịch vụ trên điện thoại di động hay trên web được cập nhật hằng tuần, thậm chí hằng ngày.

Khả năng linh hoạt là chìa khóa giúp doanh nghiệp duy trì và phát triển

Để thích ứng với môi trường kinh doanh VUCA hiện nay, doanh nghiệp ta cần sở hữu năng lực linh hoạt. Tổ chức Agile Business Consortium đã định nghĩa năng lực linh hoạt như sau:

• Thích ứng nhanh chóng với sự thay đổi của thị trường – bên trong & bên ngoài
• Phản hồi nhanh chóng và linh hoạt với nhu cầu của khách hàng
• Thích ứng và dẫn dắt sự thay đổi theo cách đảm bảo năng suất, hiệu quả về chi phí đi kèm với chất lượng
• Liên tục duy trì được lợi thế cạnh tranh

Khi xét năng lực ở các cấp độ quy mô khác nhau sẽ nhìn thấy hiệu quả khác nhau. Steve Denning trong cuốn sách “The Age of Agile” đã chia năng lực thành các cấp độ sau đây:

• Cấp độ vận hành: cải thiện hiệu suất, chi phí và gia tăng chất lượng sản phẩm, dịch vụ đáp ứng nhu cầu khách hàng ở mức độ nhóm, đơn vị hay toàn bộ tổ chức cho các dịch vụ và sản phẩm hiện có.
• Cấp độ chiến lược: Những đổi mới để tạo ra các mô hình kinh doanh mới.

Đặc biệt, để chuyển đổi số thành công ở cấp độ vận hành hay các mô hình kinh doanh số mới, doanh nghiệp cần áp dụng tư duy Agile ở mức độ tổ chức [3].

Tư duy Agile là cách thức để đạt được năng lực linh hoạt

Phần lớn tổ chức, đặc biệt là các ngân hàng, đã lựa chọn Agile như cách thức để đạt được khả năng linh hoạt. Ahmed Sidky – Chủ tịch của ICAgile, có một cách định nghĩa Agile như ở hình dưới.

Định nghĩa về Agile theo Chủ tịch của ICAgile – Ahmed Sidky

Theo đó, tư duy Agile tập trung vào bốn điểm chính sau đây:

1) Trách nhiệm và tự chủ của mỗi cá nhân và đội nhóm hơn là kiểm soát, tuân thủ quy trình, công cụ.

2) Sản phẩm dịch vụ tới khách hàng hơn là những bộ tài liệu dễ hiểu.

3) Cộng tác với khách hàng để cùng kiến tạo giá trị.

4) Phản hồi với thay đổi để tạo kết quả hơn là chỉ tuân theo kế hoạch.

Có rất nhiều kỹ thuật khác nhau đã được tạo ra thể hiện tinh thần đó như:

• Chia thành các nhóm nhỏ tự quản với một nhiệm vụ cụ thể, gọi là nhóm đặc nhiệm – Squad.
• Cả nhóm cùng họp đứng hằng ngày để chia sẻ thông tin và điều chỉnh hành động để bám sát mục tiêu chứ không đợi tới họp giao ban hay chỉ báo cáo qua email.
• Trong một khoảng thời gian ngắn như hai tuần, cả nhóm không phân biệt kỹ năng và chức danh cùng làm việc để hoàn thành sản phẩm cho khách hàng chứ không chỉ làm rõ yêu cầu khách hàng.
• Thử nghiệm với khách hàng thường xuyên để xác định bước hành động tiếp theo, dù kế hoạch còn rất dài.

Một trong những cách thức tổ chức được áp dụng phổ biến nhất là Scrum. Scrum đã tổ chức lại khá nhiều kỹ thuật nhỏ đó để đưa ra một cách thức làm việc hiệu quả cho phần lớn các nhóm Agile. 

Tóm tắt phương pháp Scrum (trích từ “Cẩm nang Scrum”)

Khi nào sử dụng Tư duy Agile, khi nào không?

Một câu hỏi mà rất nhiều lãnh đạo doanh nghiệp trăn trở là: liệu Agile có phù hợp với đặc thù công việc của đơn vị mình không? Đây là một câu hỏi không dễ trả lời. Tuy nhiên, chúng ta có thể bắt đầu bằng các phân tích sau:

Trong quản trị doanh nghiệp hay hẹp hơn là quản trị dự án, có hai loại dự án có cách tiếp cận khác nhau là dự án thuộc loại Thực thi (Execution) và dự án thuộc loại Mới tinh (Novel). Trong đó:

• Loại Thực thi: cần lên kế hoạch chi tiết, cụ thể, 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: do ẩn chứa quá nhiều yếu tố không đoán được (uncertainty), nên cần một kế hoạch có khả năng thích ứng nhanh với các phản hồi mới, dữ liệu mới trong quá trình triển khai. Đối với loại dự án này, cần có kế hoạch với khả năng thích ứng tốt, vòng phản hồi ngắn và sự cộng tác chặt chẽ giữa các bên liên quan với đội dự án làm việc tự chủ nhiều hơn thay vì làm việc kiểu “ra lệnh và kiểm soát” (command-and-control). 

Nói tóm lại, với các dự án loại Thực thi, chúng ta có thể triển khai theo dạng truyền thống; còn với các dự án loại Mới tinh thì nên sử dụng Agile mới ổn.

Tuy nhiên, để phân định rạch ròi dự án thuộc loại Thực thi hay Mới tinh không phải là điều dễ dàng. 

Một dự án do 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. Trong khi, 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. Chưa kể trong quá trình thực thi cũng tồn tại những yếu tố biến động của môi trường xung quanh.

Trong bài báo “Embrace Agile” đăng trên HBR gần đây, đồ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, chỉ ra 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 hiểu rõ hơn về điều 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
• Ưu tiên cộng tác liên chức năng 
• 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ể chia thành nhiều phần nhỏ và đượ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 bài học chứ không mang đến những thảm họa.

Ngược lại, Agile có thể không phù hợp khi:

• Đ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 và giải pháp rất rõ ràng. Có thể đặc tả chi tiết 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 bài báo “A Leader’s Framework for Decision Making” đăng trên HBR số Tháng 11 năm 2007, hai tác giả Snowden và Boone đã trình bày một mô hình phân loại thế giới thành các vùng, với các đặc điểm tương đối khác nhau và độ phức tạp tăng dần, như sau: Hiển nhiên (Obvious), Rối rắm (Complicated), Phức hợp (Complex) và Hỗn độn (Chaotic). 

Trong đó, các dự án có độ phức tạp là Hiển nhiên hoặc Rối rắm thuộc loại Thực thi. Còn các dự án có độ phức tạp từ Phức hợp đến Hỗn độn thuộc loại Mới tinh.

Mô hình nghiên cứu về phức hợp Cynefin

Bảng dưới đây tóm tắt các 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 “vạn năng” cho mọi tình huống, mà cần có tư duy khác nhau trong các tình huống khác nhau.

Nhận biết và ra quyết định phù hợp với độ phức tạp, theo Snowden và Boone

Như chúng ta thấy, Agile phù hợp nhất ở vùng Phức hợp, 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 tối ưu nhất 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ối rắm, nhưng vùng Phức hợp là vùng dễ thấy tính tương thích nhiều nhất.

Cấu trúc của một tổ chức Agile

Hãy cùng tìm hiểu về cấu trúc của một tổ chức Agile thông qua ví dụ về Spotify.

Tại Spotify, Squad giống như một Nhóm Scrum và được thiết kế như một startup-nhỏ. Những người có đủ các kỹ năng và công cụ cần thiết để thiết kế, phát triển, kiểm thử và phát hành sản phẩm, sẽ ngồi lại với nhau. Họ là nhóm tự tổ chức và quyết định cách làm việc riêng – có thể dùng các Sprint trong Scrum, Kanban hoặc kết hợp cả hai phương pháp.

Mỗi Squad có một nhiệm vụ dài hạn kiểu như xây dựng và cải tiến ứng dụng trên Android, tạo ra trải nghiệm radio trên Spotify, mở rộng hệ thống backend, hoặc cung cấp các giải pháp thanh toán. Hình ảnh dưới đây minh họa những trách nhiệm của Squad trong các phân đoạn khác nhau của quá trình trải nghiệm người dùng.

Cấu trúc sử dụng ma trận khi áp dụng mô hình Spotify

Tribe là tập hợp các Squad làm việc trong những lĩnh vực có liên quan – như là Khách hàng cá nhân hay Trái phiếu hoặc Vận hành.

Trên thực tế, không ít lần xảy ra tình trạng: Kiểm thử ở Squad A đang phải vật lộn với vấn đề mà kiểm thử ở Squad B đã giải quyết tuần trước. Nếu tất cả kiểm thử viên của các Squad và Tribe có thể tập hợp lại thì họ có thể chia sẻ kiến thức và tạo ra các công cụ giúp ích cho tất cả Squad.

Nếu mỗi Squad hoàn toàn tự chủ và thiếu đi sự giao tiếp giữa các Squad, thì ý nghĩa của công ty là gì? Spotify có thể được phân chia thành 30 công ty khác nhau.

Vì vậy, Spotify có các Chapter và Guild để gắn kết toàn công ty, vừa duy trì sự tự chủ vừa đảm bảo tính gắn kết của tổ chức.

• Chapter là một gia đình bé nhỏ gồm những người có kỹ năng và năng lực tương đồng, trong một Tribe.
• Guild là “cộng đồng quan tâm/yêu thích” có quy mô rộng hơn. Đây là một nhóm người muốn chia sẻ kiến thức, công cụ, mã nguồn và các phương pháp thực hành. 

Chapter nằm trong một Tribe, trong khi Guild thường trải rộng ra toàn tổ chức.

Bên cạnh mô hình Spotify, cấu trúc lưỡng hợp của Kotter thường được áp dụng phổ biến hơn khi triển khai Agile trong các tổ chức truyền thống như ngân hàng.

Trong mô hình này, cấu trúc truyền thống được duy trì và hình thành mạng lưới cấu trúc các nhóm sáng tạo ít “chính thức” hơn để triển khai các sáng kiến đổi mới.

Vai trò, trách nhiệm của lãnh đạo trong tổ chức Agile

Để hiểu rõ vai trò của lãnh đạo trong tổ chức Agile, chúng ta xem xét cấu trúc của một nhóm Agile phổ biến nhất – Nhóm Scrum (Trích Cẩm nang Scrum – thuộc tủ sách của Học viện Agile).  

Nhóm Scrum bao gồm các vai trò: Product Owner, Nhà Phát triển và Scrum Master. Mô hình nhóm Scrum được thiết kế để tối ưu hóa sự linh hoạt, sáng tạo và năng suất. Nhóm Scrum chuyển giao các gói sản phẩm đạt tiêu chuẩn “Hoàn thành” và có thể sử dụng được, theo phân đoạn lặp đi lặp lại và tăng trưởng dần (incremental).

Để dễ hình dung hơn, chúng ta có thể so sánh cấu trúc của nhóm Scrum với nhóm đua thuyền rồng. Product Owner là người lái, định hướng con thuyền. Các tay chèo là các nhà Phát triển. Scrum Master là người giúp giữ nhịp để nhóm đạt hiệu năng tốt nhất trong cả cuộc đua.

Nhóm tự quản liên chức năng

Nhóm tự quản liên chức năng

Nhóm Scrum là nhóm tự quản (self-managed) và liên chức năng (cross-functional). Trong đó:

• Nhóm tự quản: nhóm tự quyết định sẽ làm gì, ai phụ trách và cách thức tốt nhất để hoàn thành công việc, chứ không cần sự chỉ đạo từ người bên ngoài nhóm. Trong nhóm, không ai giao việc cho ai mà các thành viên chủ động lập kế hoạch, phân chia công việc dựa trên vai trò được phân công từ trước. Mỗi thành viên được trao quyền để hoàn thành công việc, hướng đến mục tiêu chung.
• Nhóm liên chức năng: bao gồm các cá nhân với kỹ năng, chuyên môn cần thiết để hoàn thành công việc mà không phụ thuộc vào người bên ngoài nhóm. Trong nhóm, các thành viên có thể đến từ nhiều phòng ban khác nhau hoặc từ bên ngoài (khách hàng, các cá nhân có liên quan, chuyên gia tư vấn,…), tập trung thành một đội để hoàn thành mục tiêu chung.

Scrum Master là một lãnh đạo đích thực, người phục vụ Nhóm Scrum và tổ chức

Scrum Master là một vai trò then chốt giúp Nhóm Scrum làm việc hiệu quả thông qua cải thiện các kĩ thuật trong khung Scrum. Scrum Master có trách nhiệm đảm bảo nhóm hiểu lý thuyết và thực hành Scrum đúng kỹ thuật, tuân thủ nguyên lý Agile như trong “Hướng dẫn Scrum”. 

Scrum Master không trực tiếp tham gia vào công việc làm ra sản phẩm, nhưng là chất kết dính để các bên phối hợp với nhau tạo ra sản phẩm tốt. Scrum Master không phải là quản lí của Nhóm mà là một lãnh đạo theo phong cách phục vụ (Servant Leader).

Với Nhóm Scrum, Scrum Master phục vụ theo nhiều cách, cụ thể:

• Đào tạo Scrum căn bản cho các thành viên trong nhóm.
• Huấn luyện thành viên nhóm theo mô hình tự quản và liên chức năng. Ví dụ, nhắc nhở cập nhật Sprint Backlog và biểu đồ Sprint Burndown, thực hiện đúng sự kiện Scrum Hằng ngày, đảm bảo thông tin minh bạch, các Nhà Phát triển sẽ hỗ trợ nhau tự chịu trách nhiệm với Mục tiêu Sprint.
• Giúp nhóm tập trung vào việc tạo ra những Phần tăng trưởng giá trị cao thỏa mãn Định nghĩa Hoàn thành.
• Đảm bảo tất cả sự kiện trong Scrum diễn ra tích cực, năng suất và trong khung thời gian. Ví dụ, chuẩn bị tốt khâu hậu cần cho các sự kiện.
• Hỗ trợ tìm kiếm và sử dụng hiệu quả các công cụ hỗ trợ phát triển, như công cụ quản lý Sprint Backlog, duy trì biểu đồ Sprint Burndown, các công cụ quản lý tài liệu, họp và giao tiếp hiệu quả.
• Bảo vệ các Nhà Phát triển trước những can thiệp bên ngoài trong quá trình triển khai một Sprint. Ví dụ, Scrum Master cần giải thích rõ cho quản lý về những tác hại của việc thay đổi Mục tiêu Sprint trong quá trình thực hiện đối với nhóm và sản phẩm, và nên đợi đến Sprint tiếp theo.
• Đảm bảo các Nhà Phát triển được trang bị đầy đủ tài nguyên cần thiết để phát triển. Ví dụ như: không gian làm việc, các công cụ hỗ trợ và các tài nguyên khác khi có nhu cầu,…

Với Product Owner, Scrum Master phục vụ theo nhiều cách, cụ thể:

• Tìm kiếm các kĩ thuật để định nghĩa Mục tiêu, quản lý hiệu quả yêu cầu;
• Giúp Nhóm Scrum hiểu giá trị của các hạng mục trong yêu cầu công việc rõ ràng, ngắn gọn và cách thức xây dựng;
• Giúp lập kế hoạch sản phẩm thực nghiệm trong môi trường phức tạp;
• Thúc đẩy sự cộng tác với các bên liên quan theo nhu cầu hoặc khi cần thiết.

Với tổ chức, Scrum Master phục vụ theo nhiều cách, cụ thể:

• Dẫn dắt, đào tạo, huấn luyện tổ chức trong việc tiếp nhận Scrum;
• Lập kế hoạch, tư vấn các cách triển khai Scrum trong tổ chức;
• Giúp đỡ nhân viên và các bên liên quan hiểu, cho phép cách tiếp cận thực nghiệm với những vấn đề phức tạp;
• Tháo gỡ rào cản giữa các bên liên quan và Nhóm Scrum.

Tác giả: Phạm Anh Đới

Tham khảo

1. https://www.forbes.com/sites/forbesinsights/2017/11/30/5-steps-to-greater-agility-in-your-organization
2. https://www.mckinsey.com/industries/financial-services/our-insights/banking-matters/a-discussion-on-agile-in-banking-beyond-buzzwords
3. https://internationalbanker.com/banking/becoming-an-agile-bank

Bài viết liên quan:

• Hướng dẫn về Agile dành cho lãnh đạo doanh nghiệp