Tư duy Agile cho lãnh đạo

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

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).

Thời gian trung bình một doanh nghiệp ở 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 như Hình dưới.

Môi trường kinh doanh thay đổi ngày càng nhanh

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ác cấp độ năng lực khác nhau

  • 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] như hình dưới.

Áp dụng tư duy Agile ở cấp độ tổ chức

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 Agile của 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ư:

1) 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.

2) 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.

3) 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.

4) 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.

Tình huốngĐặc điểm nhận dạngVai trò người ra quyết định
Hiển nhiên
  • Các khuôn mẫu (pattern) và sự kiện lặp đi lặp lại
  • Mọi người đều thấy rõ mối quan hệ nhân-quả
  • Có một câu trả lời đúng đắn
  • Mọi người biết rõ những cái đã biết
  • Quản lý theo thực tế (Fact-based management)
  • Phán đoán trước, phân loại sau, rồi phản hồi
  • Sử dụng quy trình đúng đắn
  • Ủy quyền
  • Sử dụng kinh nghiệm tốt (best practice)
  • Truyền đạt rõ ràng, trực tiếp
  • Giao tiếp hai chiều có thể không cần thiết
Rối rắm
  • Cần chuyên gia phân tích
  • Có thể nhận biết quan hệ nhân-quả nhưng không hiển nhiên đối với mọi người
  • Có nhiều hơn một câu trả lời
  • Mọi người biết là có những thứ chưa biết đến
  • Quản lý theo thực tế
  • Phán đoán trước, phân tích sau, rồi phản hồi
  • Thiết lập đội chuyên gia
  • Lắng nghe các lời khuyên có phần khác biệt
Phức hợp
  • Thay đổi liên tục và không thể tiên lượng
  • Không có câu trả lời đúng đắn; các khuôn mẫu hoạt động xuất hiện dần dần
  • Mọi người không biết những điều chưa biết
  • Rất nhiều ý tưởng đối nghịch nhau
  • Cần những tiếp cận sáng tạo
  • Lãnh đạo dựa-trên-khuôn-mẫu (pattern-based leadership)
  • Thử nghiệm trước, phán đoán sau, rồi phản hồi
  • Tạo môi trường thử nghiệm cho phép các khuôn mẫu xuất hiện.
  • Tăng mức độ tương tác và giao tiếp hai chiều
  • Dùng các phương pháp để tạo lập thật nhiều ý tưởng: thảo luận mở; tạo lập biên; khuyến khích các nhân tố thu hút (attractor); khuyến khích sự bất đồng quan điểm và sự đa dạng; quản lý các điều kiện ban đầu và giám sát để hình thành các khuôn mẫu.
Hỗn độn
  • Nhiễu loạn cao độ
  • Không rõ quan hệ nhân- quả, thậm chí không có điểm nào để tìm kiếm manh mối
  • Không thể biết được điều gì
  • Phải ra nhiều quyết định liên tục mà không có thời gian suy nghĩ
  • Lãnh đạo dựa-trên-khuôn-mẫu (pattern-based leadership)
  • Hành động trước, phán đoán sau, rồi phản hồi
  • Quan sát xem cái nào hiệu quả thay vì tìm kiếm câu hỏi đúng đắn
  • Hành động ngay lập tức để cứu vãn trật tự (mệnh lệnh và kiểm soát)
  • Truyền đạt rõ ràng, trực tiếp

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.

Các Chapter và Guild

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.

Cấu trúc lưỡng hợp của Kotter

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.

Cấu trúc của nhóm Scrum

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.

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

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