Làm vượt kỳ vọng của khách hàng

Nguyên tắc đầu tiên trong Disciplined Agile (DA) là làm vượt kỳ vọng của khách hàng. Để một chuỗi giá trị được thành công, sự hài lòng của khách hàng phải là ưu tiên chủ đạo. Vào năm 2001, những người viết Tuyên ngôn Agile (Agile Manifesto) đã nói rằng “Ưu tiên cao nhất của chúng ta là làm hài lòng khách hàng thông qua việc phân phối sớm và liên tục các phần mềm có giá trị” - đây là một khởi đầu tốt, nhưng những người áp dụng Disciplined Agile đánh giá cao triết lý của Lean hơn, bởi để thành công thì không chỉ đơn giản là đáp ứng kỳ vọng của khách hàng, mà thay vào đó chúng ta phải luôn luôn làm vượt trên cả kỳ vọng của họ bất kỳ lúc nào nếu chúng ta muốn giữ chân khách hàng.

Để làm vượt kỳ vọng của khách hàng, các sản phẩm và dịch vụ mà chúng ta cung cấp không chỉ đáp ứng nhu cầu mà còn phải vượt trên sự mong đợi của họ. Ví dụ: Khi bạn đi du lịch và nghỉ dưỡng tại một resort, nếu resort này làm hài lòng bạn như những resort mà bạn đã từng trải nghiệm trước đây thì việc lựa chọn một trong các resort này ở lần tiếp theo là ngang nhau. Nhưng bây giờ, hãy tưởng tượng rằng khi bạn đến resort được nhân viên hướng dẫn chào đón bằng danh thiếp viết tay có chính tên của mình, món ăn nhẹ yêu thích của bạn đang đợi bạn trong phòng và bạn được nâng cấp miễn phí lên một căn phòng có view tuyệt đẹp - tất cả đều không cần hỏi. Điều này sẽ khiến bạn “Wow” hơn phải không? Mặc dù việc nâng cấp sẽ không xảy ra mỗi khi bạn nhận phòng, nhưng đó là một hành động tuyệt vời khi nó xảy ra và khả năng bạn quay lại resort này sẽ cao bởi dịch vụ rất hoàn hảo.

Các doanh nghiệp thành công là các doanh nghiệp có thể cung cấp các sản phẩm và dịch vụ tuyệt vời nhất để làm vượt kỳ vọng của khách hàng. Thiết kế hệ thống - yêu cầu chúng ta xây dựng hình ảnh doanh nghiệp từ trong tâm trí khách hàng, hợp tác chặt chẽ với họ, xây dựng theo từng bước nhỏ và sau đó tìm kiếm phản hồi, để chúng ta hiểu rõ hơn điều gì sẽ thực sự làm vượt kỳ vọng của họ. Là những người áp dụng Disciplined Agile, để phát triển, chúng ta phải đón nhận và thích nghi với sự thay đổi, bởi các bên liên quan của chúng ta cũng sẽ thay đổi suy nghĩ của họ khi họ tìm hiểu những gì họ thực sự mong muốn từ sản phẩm của chúng ta.

Hãy trở nên tuyệt vời

Nguyên tắc thứ 2 được nhắc đến trong Disciplined Agile chính là hãy trở nên tuyệt vời. Ai mà không muốn trở nên tuyệt vời? Ai mà không muốn trở thành một phần của một nhóm tuyệt vời, làm những điều tuyệt vời khi làm việc cho một tổ chức tuyệt vời? Tất cả chúng ta đều muốn những thứ này. Josh Kerievsky đã phổ biến khái niệm rằng các nhóm Modern Agile làm cho mọi người trở nên tuyệt vời hơn và tất nhiên không phải cứ muốn là sẽ có ngay những đội nhóm tuyệt vời và những tổ chức tuyệt vời được. Tương tự, trong công việc phát triển phần mềm tinh gọn (Lean Software Development), Poppendiecks nhận thấy rằng lợi thế bền vững sẽ có được từ những người có tư duy và tương tác tốt. Giúp mọi người trở nên tuyệt vời là điều quan trọng bởi vì, như Richard Branson của Virgin Group nói, “Hãy quan tâm đến nhân viên và họ sẽ chăm sóc doanh nghiệp của chúng ta”.

Với tư cách là một cá nhân, có một số điều mà chúng ta có thể làm để trở nên tuyệt vời:

• Trước hết, hãy hành động theo cách mà chúng ta có thể nhận được sự tôn trọng và tin tưởng từ đồng nghiệp. Hãy trở thành người đáng tin cậy, trung thực, cởi mở và đối xử với họ một cách tôn trọng. 
• Thứ hai, sẵn sàng cộng tác với những người khác. Chia sẻ thông tin với đồng nghiệp khi được hỏi, ngay cả khi đó là một công việc đang được tiến hành, chưa hoàn thành. Đề nghị trợ giúp khi cần thiết và quan trọng không kém chính là việc tự tìm kiếm sự trợ giúp. 
• Thứ ba, hãy là người luôn muốn học hỏi một cách tích cực. Luôn tìm kiếm cơ hội để thử nghiệm và học hỏi nhằm làm chủ công việc của chúng ta. Hãy vượt ra ngoài chuyên môn của chúng ta, tìm hiểu về quy trình và môi trường kinh doanh rộng lớn hơn. Bằng cách trở thành một “chuyên gia tổng quát” (generalizing specialist - biết chuyên sâu nhiều mảng kiến thức), chúng ta sẽ có thể đánh giá tốt hơn về những người khác và từ đó tương tác với họ hiệu quả hơn.

Các nhóm tuyệt vời được xây dựng xung quanh những cá nhân năng động, những người được tạo môi trường làm việc tốt nhất và sự hỗ trợ cần thiết để hoàn thành các mục tiêu của họ. Một nghiên cứu năm 2015 tại Google cho thấy rằng các nhóm thành công mang lại sự an toàn về tâm lý cho các thành viên trong nhóm, các thành viên trong nhóm có thể phụ thuộc vào nhau, có cấu trúc, có sự rõ ràng xung quanh vai trò và trách nhiệm, mọi người làm những công việc có ý nghĩa và tác động đến nhau. Các nhóm tuyệt vời có mối quan hệ làm việc rất tốt với các bên liên quan của họ, cộng tác với họ để đảm bảo rằng những gì họ làm là những gì các bên liên quan thực sự cần. Cuối cùng, các nhóm tuyệt vời là một khối tổng thể - họ là một tập thể với những kỹ năng cần thiết để hoàn thành công việc, có các nguồn lực, quyền hạn cần thiết để thành công và bản thân các thành viên trong nhóm có xu hướng trở thành các “chuyên gia tổng quát”.

Các nhóm tuyệt vời cũng chọn việc tích hợp đảm bảo chất lượng ngay từ đầu. Lean cho chúng ta biết rằng quy trình không nên để xảy ra lỗi ngay từ đầu. Nhưng nếu chúng ta không thể tích hợp đảm bảo chất lượng ngay từ đầu, chúng ta nên làm việc theo cách đó là thực hiện từng công việc, xác thực nó, khắc phục bất kỳ vấn đề nào đang xảy ra và sau đó lặp lại. Tuyên ngôn Agile rõ ràng chỉ ra rằng cần phải liên tục chú ý đến sự tối ưu về kỹ thuật và thiết kế để tăng cường tính linh hoạt của sản phẩm.

Là một nhà lãnh đạo, chúng ta có thể cho phép nhân viên của mình trở thành những cá nhân tuyệt vời làm việc trong các nhóm tuyệt vời thông qua việc cung cấp cho họ quyền hạn và nguồn lực cần thiết để họ thực hiện công việc của mình, bằng cách xây dựng một môi trường và văn hóa an toàn, và bằng cách thúc đẩy họ vượt trội. Như Dan Pink đã chỉ ra, mọi người được thúc đẩy bởi họ được cung cấp quyền tự chủ để thực hiện công việc của họ, có cơ hội để làm chủ công việc của họ và thực hiện các việc đó một cách có mục đích. Chúng ta muốn có những gì, nhân viên có động lực hay nhân viên mất động lực?

Giải quyết vấn đề theo từng ngữ cảnh

Nguyên tắc thứ 3 trong Disciplined Agile là giải quyết vấn đề theo từng ngữ cảnh. Mỗi người là duy nhất, với những kỹ năng, sở thích về phong cách làm việc, mục tiêu nghề nghiệp và phong cách học tập của riêng họ. Mỗi nhóm là duy nhất không chỉ bởi vì nhóm đó bao gồm những người độc nhất mà còn bởi vì nhóm phải đối mặt với những tình huống độc nhất. Tổ chức của chúng ta cũng là duy nhất, ngay cả khi có các tổ chức khác hoạt động trong cùng một lĩnh vực với mình. Ví dụ, các nhà sản xuất ô tô như Ford, Audi và Tesla đều xây dựng cùng một loại sản phẩm là ô tô nhưng họ là những công ty rất khác nhau bởi phân khúc sản phẩm khác nhau, loại hình xe khác nhau.... Cá nhân, các nhóm và tổ chức đều là duy nhất - vì vậy quy trình và cấu trúc tổ chức của chúng ta phải được điều chỉnh cho phù hợp với tình huống mà chúng ta hiện đang đối mặt. Nói cách khác, giải quyết vấn đề theo từng ngữ cảnh.

Yếu tố ngữ cảnh

Hình 1 thể hiện tổng quan các yếu tố mà chúng ta nên xem xét liên quan đến ngữ cảnh của tình huống mà nhóm của chúng ta phải đối mặt. Chúng ta có thể sắp xếp chúng thành hai loại:

• Các yếu tố lựa chọn (Selection factors) thúc đẩy lựa chọn ban đầu của chúng ta xung quanh cách làm việc ở mức độ tổng quát (WoW) và đặc biệt là lựa chọn ban đầu về vòng đời phát triển giải pháp của chúng ta .
• Các yếu tố mở rộng quy mô (Scaling Factors) dẫn đến các quyết định chi tiết về cách làm việc của nhóm chúng ta.

Tất nhiên nó không bao giờ đơn giản như vậy. Các yếu tố lựa chọn sẽ có ảnh hưởng đến các lựa chọn cách làm việc chi tiết của chúng ta và các yếu tố mở rộng cũng sẽ có tác động đến các quyết định ban đầu của chúng ta. Nhìn chung các yếu tố lựa chọn có tác động lớn hơn đến các lựa chọn ban đầu so với các yếu tố mở rộng và tương tự, các yếu tố mở rộng có tác động lớn hơn đến các quyết định điều chỉnh chi tiết của chúng ta hơn là các yếu tố lựa chọn.

Hình 1. Các yếu tố ngữ cảnh
  

Các yếu tố ngữ cảnh phụ thuộc lẫn nhau. Hình 2 cho thấy các mối quan hệ chính giữa các yếu tố ngữ cảnh. Ví dụ, chúng ta có thể thấy rằng:

• Khi độ phức tạp của một vấn đề tăng lên, các kỹ năng cần thiết để giải quyết sự phức tạp đó cũng tăng lên (các vấn đề khó hơn đòi hỏi kỹ năng cao hơn để giải quyết).
• Khi kỹ năng của các thành viên trong nhóm tăng lên, quy mô của nhóm cần thiết để giải quyết vấn đề mà nhóm gặp phải có thể bị thu hẹp lại (tức là một nhóm nhỏ gồm những người có kỹ năng có thể thực hiện công việc của một nhóm lớn hơn gồm những người có kỹ năng thấp hơn).
• Văn hóa tổ chức và văn hóa nhóm của chúng ta có xu hướng ảnh hưởng lẫn nhau, vì vậy chúng ta nên xây dựng chúng theo hướng tích cực nhất.
• Văn hóa nhóm của chúng ta sẽ thay đổi tùy theo sự phân bố của tổ chức (nhóm của chúng ta sẽ có văn hóa khác với văn hóa của các nhóm trong một bộ phận khác của tổ chức của chúng ta hoặc của các nhóm trong một công ty khác).
• Nhóm của chúng ta càng được phân chia theo tính tổ chức (công ty chuyên trách, phòng ban chuyên môn) thì cơ hội được phân bố theo địa lý càng lớn. Ví dụ: nếu chúng ta đang gia công một số công việc cho một tổ chức khác, những người làm công việc đó có thể ở một quốc gia khác với chi phí thấp hơn.

Hình 2. Mối quan hệ giữa các yếu tố ngữ cảnh
  

Chiến thuật mở rộng quy mô linh hoạt

Chúng ta hãy khám phá các yếu tố mở rộng một chút. Như đã đề cập trước đó, các yếu tố mở rộng có xu hướng thúc đẩy các quyết định chi tiết của chúng ta về cách làm việc của chúng ta (WoW). Ví dụ: một nhóm 8 người làm việc trong cùng một phòng về một vấn đề rất phức tạp, trong một tình huống quan trọng đến tính mạng, sẽ tự tổ chức theo cách khác và sẽ chọn tuân theo các phương pháp thực hành khác, so với một nhóm gồm 50 người ngồi ở nhiều nơi trong khuôn viên công ty khi giải quyết một vấn đề phức tạp trong một tình huống không cần tuân thủ theo quy định nghiêm ngặt. Mặc dù hai nhóm này có thể làm việc cho cùng một công ty nhưng họ có thể chọn làm việc theo những cách rất khác nhau.

Hình 3 mô tả các yếu tố mở rộng quy mô dưới dạng biểu đồ radar, đôi khi được gọi là biểu đồ mạng nhện. Có một số hàm ý thú vị như sau:

• Càng ở xa tâm của radar, độ rủi ro càng lớn. Ví dụ: thuê ngoài sẽ rủi ro hơn nhiều so với xây dựng đội ngũ nội bộ của riêng mình. Một nhóm lớn là một đề xuất rủi ro hơn nhiều so với một nhóm nhỏ. Một tình huống quan trọng ảnh hưởng tới tính mạng sẽ rủi ro hơn nhiều so với một tình huống quan trọng về tài chính.
• Bởi vì các nhóm trong các tình huống khác nhau sẽ cần phải lựa chọn làm việc theo cách phù hợp với tình huống mà họ phải đối mặt, để giúp họ điều chỉnh cách tiếp cận của mình một cách hiệu quả, chúng ta cần cung cấp cho họ các lựa chọn.
• Bất kỳ ai tương tác với nhiều nhóm cần phải đủ linh hoạt để làm việc với từng nhóm đó một cách thích hợp. Ví dụ: chúng ta sẽ quản lý nhóm nhỏ, ngồi cùng với nhau, khác với quản lý nhóm quy mô trung bình, ngồi nhiều nơi trong khuôn viên công ty. Tương tự, một chuyên gia đang hỗ trợ cả hai nhóm thì cách làm việc của chuyên gia này cũng phải linh hoạt để quá trình hợp tác phù hợp với từng nhóm.

Hình 3. Các yếu tố mở rộng chiến thuật mà các đội phải đối mặt

Doanh nghiệp yêu cầu giải pháp cấp doanh nghiệp

Phương pháp Scrum đưa ra hướng dẫn vững chắc để cung cấp giá trị một cách linh hoạt nhưng nó chỉ được mô tả chính thức bởi một bản hướng dẫn 16 trang (Scrum Guide). Disciplined Agile nhận ra rằng sự phức tạp của doanh nghiệp đòi hỏi nhiều hướng dẫn hơn và do đó cung cấp một khung tham chiếu toàn diện để điều chỉnh cách tiếp cận linh hoạt cho bối cảnh độc đáo của chúng ta một cách đơn giản. Có thể điều chỉnh cách tiếp cận của chúng ta cho phù hợp với bối cảnh bằng nhiều lựa chọn (chẳng hạn như những lựa chọn chúng ta cung cấp thông qua sơ đồ mục tiêu - Goal Diagram) thay vì tiêu chuẩn hóa trên một phương pháp hoặc khuôn khổ nào đó.

Hãy thực dụng

Nguyên tắc thứ 4 trong Disciplined Agile không thể không kể đến chính là Chủ nghĩa thực dụng. Mọi người thường ngạc nhiên khi thấy nhận định rằng các phương pháp phổ biến như Scrum và Extreme Programming (XP) là có tính khuôn khổ, nguyên tắc. Nhưng thực sự là như vậy. Scrum quy định một cuộc họp độc lập hàng ngày (Daily Scrum) không quá 15 phút mà tất cả các thành viên trong nhóm phải tham dự, các nhóm phải có một cuộc họp tổng kết vào cuối mỗi lần lặp (Sprint) và quy mô nhóm đó không được nhiều hơn 9 người. Extreme Programming yêu cầu pair-programming (hai người lập trình viên cùng làm việc tại một máy). Nhiều người áp dụng Agile thuần khá cuồng tín về việc tuân theo các phương pháp cụ thể một cách nghiêm ngặt. Trên thực tế, chúng ta có thể đã gặp nhiều người nói rằng để “làm Agile đúng”, chúng ta cần có 5-9 người trong một phòng, với Product Owner luôn có mặt. Nhóm không nên bị quấy rầy bởi những người bên ngoài nhóm và nên chuyên tâm 100% cho dự án. Tuân theo nguyên tắc, khuôn khổ không phải là một điều xấu. Tuy nhiên, ở nhiều doanh nghiệp, điều kiện lý tưởng như vậy hiếm khi tồn tại. Thực tế là chúng ta phải đối phó với nhiều tình huống không tối ưu, chẳng hạn như nhóm phân tán, quy mô nhóm lớn, thuê ngoài, phối hợp nhiều nhóm và không phải lúc nào các bên liên quan cũng sẵn sàng tham gia vào dự án.

Bộ công cụ DA nhận ra những thực tế này và thay vì nói “chúng ta không thể nhanh nhẹn, linh hoạt” trong các tình huống, chúng ta có thể nói “hãy làm việc hiệu quả nhất có thể.” Thay vì chỉ định “các phương pháp hay nhất”, DA thay vào đó cung cấp các chiến lược để tối đa hóa lợi ích của agile mặc dù đã có những thỏa hiệp cần thiết nhất định. Do đó, DA thực dụng, không thuần túy trong hướng dẫn của nó - DA giúp chúng ta đưa ra các lựa chọn quy trình tốt hơn chứ không phải các quy tắc nghiêm ngặt thậm chí có thể không áp dụng được trong bối cảnh chúng ta phải đối mặt.

Lựa chọn là Tốt

“Lựa chọn là Tốt” là nguyên tắc thứ 5 trong Disciplined Agile. Hãy giả sử tổ chức của chúng ta có nhiều nhóm làm việc trong một loạt các tình huống (trừ những công ty rất nhỏ thì không có nhiều nhóm). Làm thế nào để chúng ta xác định một quy trình áp dụng cho mỗi và mọi tình huống bao gồm một loạt các vấn đề mà mỗi nhóm phải đối mặt? Làm cách nào để chúng ta cập nhật nó khi mỗi nhóm học hỏi và phát triển cách tiếp cận của họ?

Câu trả lời là chúng ta không thể, việc ghi lại một quy trình như vậy là tốn kém theo cấp số nhân. Điều đó có nghĩa là chúng ta cần phải thực hiện cùng một quy trình quy định cho tất cả mọi người? Khi chúng ta làm điều đó, chúng ta sẽ gây ra sự bất ổn về quy trình cho các nhóm của mình, làm giảm khả năng hiệu quả của họ và tăng khả năng làm việc theo kiểu đối phó, bên ngoài nhìn vào sẽ tưởng họ đang tuân theo quy trình nhưng thực tế thì không. Hay là chúng ta sẽ “không theo một quy trình định trước nào cả - process free-for-all” và yêu cầu tất cả các nhóm của mình tự tìm hiểu? Mặc dù điều này có thể hiệu quả nhưng nó có xu hướng rất tốn kém và mất thời gian trong thực tế - ngay cả khi được huấn luyện, mỗi nhóm buộc phải phát minh hoặc khám phá các phương pháp và chiến lược đã có từ nhiều năm, đôi khi là nhiều thập kỷ. May mắn thay, bộ công cụ Disciplined Agile cung cấp một cách tốt hơn.

Các bối cảnh khác nhau đòi hỏi các chiến lược khác nhau - các nhóm cần có khả năng làm chủ quy trình của riêng mình và thử nghiệm để biết được cách làm việc nào phù hợp với thực tế tương ứng với từng tình huống mà chúng ta phải đối mặt. Đây là lý do tại sao bộ công cụ DA giới thiệu cho mọi người các lựa chọn thông qua việc áp dụng các sơ đồ mục tiêu (Goal Diagram), xem hình bên dưới - ví dụ về các tùy chọn để giải quyết thay đổi nhu cầu của các bên liên quan trong suốt quá trình cung cấp giải pháp của nhóm. Ý tưởng là đưa ra các điểm quyết định quan trọng một cách rõ ràng, chẳng hạn như thời điểm chấp nhận các thay đổi, sau đó trình bày cho nhóm các lựa chọn và sự đánh đổi xung quanh các lựa chọn đó (điểm lợi, điểm bất lợi). Điều này cho phép các nhóm đưa ra các lựa chọn quy trình tốt hơn trong tình huống mà họ phải đối mặt. Để thực hiện những lựa chọn này, các nhóm cần biết: từng tùy chọn là gì, sự đánh đổi liên quan đến từng tùy chọn và trong những trường hợp nào tùy chọn được và không được áp dụng.

Hình 4. Sơ đồ mục tiêu cho việc giải quyết thay đổi nhu cầu của các bên liên quan
  

Chiến lược dựa trên sự lựa chọn này là một con đường trung gian. Ở một khía cạnh nào đó, các phương pháp rất nguyên tắc/theo khuôn khổ, đều có vị trí của chúng, chẳng hạn như Scrum và SAFe cho chúng ta biết một cách để thực hiện mọi việc. Những lời khuyên, lời góp ý của những phương pháp này sẽ cho chúng ta biết những chiến lược này thực tế hoạt động khá hiệu quả trong một số tình huống và chúng sẽ thật sự hiệu quả đối với chúng ta khi chúng ta thấy mình ở trong tình huống đó. Tuy nhiên, nếu chúng ta không ở trong tình huống phù hợp của một phương pháp có tính khuôn khổ cao thì nó có thể gây hại nhiều hơn lợi. Ở một khía cạnh khác là các phương pháp thực nghiệm như Spotify cho phép chúng ta thử nghiệm và học hỏi khi từ những gì mình đã làm. Phương pháp này sẽ mang lại hoạt động hiệu quả trong thực tế nhưng có thể rất tốn kém, mất thời gian và dễ dẫn đến sự mâu thuẫn đáng kể giữa các nhóm, từ đó làm cản trở quá trình tổ chức tổng thể của chúng ta.

DA nằm giữa hai thái cực này - bằng cách sử dụng cách tiếp cận theo hướng mục tiêu, nó cung cấp sự tương đồng về quy trình giữa các nhóm được yêu cầu ở cấp tổ chức, đồng thời cung cấp cho các nhóm sự linh hoạt cần thiết để điều chỉnh và phát triển các quy trình nội bộ của họ nhằm giải quyết các vấn đề trong các tình huống mà họ đối mặt. Các nhóm có thể chọn từ các chiến lược đã biết, các tùy chọn có khả năng xảy ra để thử nghiệm, tăng cơ hội tìm thấy thứ gì đó phù hợp với mình trong thực tế. Ít nhất cũng thấy được mình có nhiều sự lựa chọn thay vì một cách được mô tả bởi các phương pháp mang tính khuôn khổ.

Có một cụm từ hấp dẫn trong thế giới Agile được gọi là “thất bại nhanh - fail fast” hay là “học nhanh - learn fast”. Như đã mô tả trước đó, lãnh đạo nên khuyến khích thử nghiệm sớm vì lúc này sự hứng thú học hỏi rất cao và khuyến khích cải thiện càng nhanh càng tốt. Tuy nhiên, DA gợi ý rằng bằng cách tham khảo các chiến lược đã được chứng minh trong Disciplined Agile, bạn sẽ đưa ra lựa chọn tốt hơn cho bối cảnh của mình, đẩy nhanh quá trình học tập và ít thất bại hơn. Lựa chọn tốt hơn dẫn đến kết quả tốt hơn.

Tối ưu hóa luồng công việc

Nguyên tắc thứ 6 trong Disciplined Agile là Tối ưu hóa luồng công việc. Tổ chức của chúng ta là một hệ thống thích ứng phức tạp (CAS - complex adaptive system) gồm nhiều đội nhóm tương tác với nhau, phát triển liên tục và ảnh hưởng lẫn nhau khi họ làm việc. Thách thức mà chúng ta phải đối mặt là làm cách nào để đảm bảo rằng các nhóm này cộng tác với nhau nhằm đem đến hiệu quả cho các chuỗi giá trị của tổ chức? Làm cách nào để chúng ta đảm bảo rằng các team này được liên kết tốt, duy trì liên kết tốt và tốt hơn nữa là cải thiện sự liên kết của họ theo thời gian?

Hàm ý là với tư cách là một tổ chức, chúng ta cần tối ưu hóa quy trình làm việc tổng thể của mình. Bộ công cụ DA hỗ trợ một số lượng lớn các chiến lược để làm như vậy:

• Bàn giao giải pháp liên tục với tốc độ bền vững: bản tuyên ngôn Agile khuyên nhóm cung cấp các giải pháp cho khách hàng một cách thường xuyên, từ một vài tuần đến vài tháng, thời gian ngắn hơn thì tốt hơn. Triết lý này là một trong bốn triết lý được thúc đẩy bởi Heart of Agile, đề cập đến bàn giao giải pháp. Tương tự, nó là một trong bốn triết lý của Modern Agile, đề cập đến cung cấp giá trị liên tục và nó là chiến lược cơ bản của Disciplined DevOps. Kể từ năm 2001, Agile đã chỉ ra rằng có thể cung cấp các hệ thống chất lượng cao một cách nhanh chóng. Bằng cách giới hạn công việc của một nhóm trong phạm vi năng lực của nhóm, được phản ánh bởi tốc độ của nhóm (đây là số “story point” mà nhóm hoàn thành sau mỗi vòng lặp - iteration, hay còn gọi là velocity), chúng ta có thể thiết lập một luồng công việc đáng tin cậy và có thể lặp lại. Một tổ chức hiệu quả không yêu cầu các nhóm làm nhiều hơn khả năng của họ, mà thay vào đó yêu cầu họ tự tổ chức và xác định những gì họ có thể hoàn thành. Việc để cho các nhóm cung cấp giải pháp hoạt động được dựa trên nhu cầu sẽ thúc đẩy họ tập trung vào việc liên tục gia tăng giá trị.
• Tối ưu hóa tổng thể: Những người áp dụng Disciplined Agile làm việc theo cách “có nhận thức về doanh nghiệp” (enterprise aware) - họ nhìn nhận được nhóm của họ là một trong nhiều nhóm trong tổ chức và kết quả là họ tự ý thức được mình cần làm việc theo cách mang lại những gì tốt nhất cho tổ chức chung chứ không chỉ làm những gì thuận tiện cho họ. Quan trọng hơn, nhóm cố gắng hợp lý hóa quy trình tổng thể, nhằm tối ưu hóa tổng thể như Lean khuyên chúng ta nên làm. Điều này bao gồm việc tìm cách giảm thời gian chu kỳ tổng thể (cycle time) - nghĩa là giảm tổng thời gian từ đầu đến cuối quy trình cung cấp giá trị cho khách hàng, là một phần quan trọng của việc làm đó.
• Làm cho công việc trôi chảy: Trực quan hóa quy trình làm việc để tạo ra một quy trình phân phối trôi chảy và giới hạn khối lượng công việc đang thực hiện (WIP - work in progress) ở mức tối thiểu. Chiến lược này được áp dụng từ Kanban, cho phép các nhóm xác định, sau đó loại bỏ các điểm nghẽn trong quy trình một cách nhanh chóng.
• Loại bỏ lãng phí: Lean thinking coi bất kỳ hoạt động nào không trực tiếp làm tăng giá trị cho sản phẩm đều được xem là lãng phí. Lãng phí bao gồm thời gian chờ đợi người khác hoàn thành công việc, tạo ra các công việc hoặc các tính năng của sản phẩm không cần thiết và sự gián đoạn cộng tác do phải làm việc với nhiều quy trình dư thừa của nhiều bên liên quan. Để giảm lãng phí, điều quan trọng là các nhóm được phép tự tổ chức và hoạt động theo thực tế công việc mà họ đang cố gắng hoàn thành.
• Cải tiến liên tục: Là một nhà lãnh đạo, chúng ta luôn muốn thúc đẩy văn hóa cải tiến liên tục, bao gồm việc chia sẻ các kỹ năng và kiến thức giữa mọi người và các nhóm trong tổ chức của mình. Đây được coi là một triết lý cơ bản của agile - Nguyên tắc thứ 12 trong tuyên ngôn Agile là "Trong khoảng thời gian đều đặn, nhóm phản ánh về cách trở nên hiệu quả hơn, sau đó điều chỉnh hành vi của mình cho phù hợp" và cả Cải tiến và Phản ánh đều là những nguyên tắc của Heart of Agile. Một kỹ thuật quan trọng hỗ trợ cải tiến liên tục là “học lặp lại hai lần” (double-loop learning) nhằm thúc đẩy ý tưởng rằng chúng ta sửa đổi cách tiếp cận của mình dựa trên những gì chúng ta học được từ kinh nghiệm của mình.
• Thử nghiệm để học hỏi: Có lẽ tác động đáng kể nhất từ công việc của Eric Ries trong Lean Startup là việc phổ biến tư duy thử nghiệm, áp dụng các khái niệm cơ bản của phương pháp khoa học vào kinh doanh. Tư duy này có thể được áp dụng để cải tiến quy trình theo cái mà Ries gọi là chiến lược học tập đã được xác thực. Chiến lược trước tiên là xác định một giả thuyết cải tiến cùng với tiêu chí "Chúng ta nghĩ rằng làm X sẽ cải thiện Y." Thứ hai, chạy một thử nghiệm nhỏ bằng việc thử nó một cách có kiểm soát, với các phép đo để xem hiệu quả của sự thay đổi. Thứ ba, quan sát những gì xảy ra để xác định hiệu quả của X và liệu chúng ta có cần phát triển X và chạy một thử nghiệm tiếp theo (học lặp lại hai lần) hay không. Tư duy thử nghiệm giúp củng cố và thường đẩy nhanh chiến lược học hỏi liên tục. Như chúng ta đã chỉ ra trước đó, để kích hoạt tư duy thử nghiệm trong tổ chức của mình với tư cách là người lãnh đạo, chúng ta phải thiết lập một môi trường an toàn nơi thử nghiệm được khuyến khích và khen thưởng.
• Đo lường những gì đã làm: Áp dụng các phép đo lường để cải thiện kết quả. Chúng ta đang hy vọng cải thiện điều gì? 
  • Chất lượng?
  • Thời gian ra mắt thị trường?
  • Tinh thần nhân viên?
  • Sự hài lòng của khách hàng?
  • Hay sự kết hợp của tất cả các yếu tố trên?
• Mỗi người, mỗi nhóm và tổ chức đều có những ưu tiên cải tiến và cách thức làm việc của riêng họ, vì vậy họ sẽ có bộ thước đo riêng mà họ thu thập để cung cấp cái nhìn sâu sắc về cách họ đang làm và quan trọng hơn là cách tiến hành. Và các cách đo lường này cũng không ngừng phát triển theo thời gian. Điều muốn đề cập ở đây là chiến lược đo lường của chúng ta phải linh hoạt và phù hợp với mục đích và tất nhiên sẽ khác nhau giữa các nhóm.
• Ưu tiên các nhóm ổn định tồn tại lâu dài: Một xu hướng rất phổ biến trong cộng đồng agile là sự di chuyển ra khỏi tư duy dự án, và tư duy quản lý dự án nói chung (nhóm dự án tan rã khi dự án kết thúc), chuyển sang tư duy các nhóm lâu dài. Những nhóm như vậy phát triển theo thời gian, mọi người tham gia vào nhóm và không lâu sau một số thành viên lần lượt rời khỏi nhóm, nhưng bản thân nhóm có thể hoạt động trong nhiều năm. Ví dụ, Microsoft đã có một nhóm phát triển và duy trì Microsoft Word từ năm 1981. Điều quan trọng cần lưu ý là việc rời bỏ tư duy quản lý dự án trong cộng đồng agile này không phải là rời bỏ quản lý mà thay vào đó là rời bỏ những rủi ro và chi phí overhead của dự án.

Tổ chức xung quanh Sản phẩm / Dịch vụ

Nguyên tắc thứ 7 trong Disciplined Agile là Tổ chức xung quanh sản phẩm / dịch vụ. Có một số lý do để lý giải tại sao điều quan trọng là phải tổ chức xung quanh các sản phẩm và dịch vụ, hay đơn giản hơn là các dịch vụ mà chúng ta cung cấp cho khách hàng của mình, tức là chúng ta không tổ chức xung quanh chức năng công việc, chẳng hạn như có một nhóm bán hàng, một nhóm phân tích dữ liệu, một nhóm quản lý nhà cung cấp, một nhóm quản lý dự án, v.v. Vấn đề khi làm như vậy thì chi phí overhead và thời gian cần thiết để quản lý công việc giữa các nhóm và sắp xếp các ưu tiên khác nhau của các nhóm rất cao. Thay vào đó, chúng ta xây dựng các nhóm chuyên tâm 100%, tập trung vào việc cung cấp sản phẩm cho một hoặc nhiều khách hàng. Các nhóm này sẽ có đầy đủ chức năng cần thiết để thực hiện công việc (nhóm đa chức năng), tức các thành viên bao gồm những người có kỹ năng bán hàng, kỹ năng phân tích dữ liệu, kỹ năng quản lý, v.v.

Tổ chức xung quanh các sản phẩm / dịch vụ cho phép chúng ta xác định và tối ưu hóa các luồng công việc quan trọng, các chuỗi giá trị. Chúng ta sẽ thấy rằng một tập hợp các dịch vụ có liên quan sẽ xác định một chuỗi giá trị mà chúng ta cung cấp cho khách hàng của mình và chuỗi giá trị này sẽ được thực hiện bởi tập hợp các nhóm cung cấp các dịch vụ đó.

Tổ chức xung quanh các sản phẩm / dịch vụ cho phép chúng ta tập trung vào việc làm hài lòng khách hàng. Stephen Denning gọi đây là “Luật của Khách hàng” - Law of the Customer, khi mà mọi người cần phải đam mê và tập trung vào việc gia tăng giá trị cho khách hàng của họ. Đối tượng khách hàng lý tưởng nhất là những khách hàng bên ngoài doanh nghiệp - những người hoặc tổ chức mà doanh nghiệp của chúng ta tồn tại để phục vụ. Nhưng cũng có thể là những khách hàng nội bộ, những nhóm khác hoặc những người mà chúng ta đang cộng tác để cho phép họ phục vụ khách hàng của họ hiệu quả hơn.

Trong một chuỗi giá trị, chúng ta nhận thấy rằng các nhóm đa chức năng gắn bó với nhau theo thời gian dài là hiệu quả nhất trong thực tế. Tuy nhiên phải nói rằng, sẽ luôn có những công việc theo tư duy dự án (nhóm dự án tan rã khi dự án kết thúc). Đây là lý do tại sao Disciplined Agile hỗ trợ các vòng đời phát triển giải pháp phù hợp với các nhóm dự án cũng như các nhóm gắn bó lâu năm.

Nhận thức về Doanh nghiệp

Nhận thức về doanh nghiệp là nguyên tắc quan trọng cuối cùng trong Disciplined Agile. Chúng ta cần quan sát các nhóm DA hoạt động trong hệ sinh thái doanh nghiệp của tổ chức, cũng như tất cả các nhóm khác (không phải nhóm DA). Thông thường, luôn có một vài hệ thống đã hoạt động trên môi trường thực tế, và tối thiểu thì giải pháp của chúng ta không nên gây ảnh hướng tới những hệ thống đó. Tốt hơn hết, giải pháp của chúng ta hy vọng sẽ tận dụng được chức năng và dữ liệu hiện có từ những hệ thống đó. Chúng ta thường sẽ có các nhóm khác làm việc song song với nhóm của mình và chúng ta có thể tận dụng một phần những gì họ đang làm và ngược lại. Nhóm của chúng ta nên đóng góp, cống hiến cho tầm nhìn, sứ mệnh mà tổ chức đang hướng tới, cả về tầm nhìn kinh doanh hoặc tầm nhìn kỹ thuật. Một chiến lược quản trị tồn tại với hy vọng sẽ nâng cao những gì nhóm của chúng ta đang làm.

Trong phần này, chúng ta sẽ tìm hiểu:

• Năm cấp độ nhận thức
• Ý nghĩa của việc nhận thức về doanh nghiệp
• Tại sao nhận thức về doanh nghiệp lại quan trọng
• Những thách thức đối với nhận thức về doanh nghiệp

Năm cấp độ nhận thức
 

Hình 5. Năm cấp độ nhận thức
 

• Cá nhân (Individual): Đây là tất cả về cách một người có thể phát triển bản thân dựa vào việc đạt được các kỹ năng, hiểu biết sâu sắc, kinh nghiệm mới, v.v.
• Nhóm (Team): Ở đây, trọng tâm là nhóm có thể học hỏi và cải thiện cùng nhau. Đây là một triết lý chính của cộng đồng agile, chủ yếu sẽ có lợi nhưng cũng phần nào đó có hại. Các giải pháp được phát triển bởi các nhóm, do đó, bằng cách thúc đẩy sự tập trung nhiều hơn vào nhóm, có thể cải thiện một chút năng suất tổng thể của họ. Tuy nhiên, nếu nỗ lực của nhóm đó không phù hợp với các mục tiêu chung của tổ chức thì sẽ xảy ra tình trạng phản tác dụng. Ví dụ: một số nhóm agile (chỉ đơn thuần là biết riêng nhóm mình) có thể giới thiệu các công nghệ mới mà các nhóm vận hành hệ thống không sẵn lòng hoặc không thể hỗ trợ. Hoặc họ có thể phát minh lại chức năng hiện có. Hoặc họ có thể tạo thêm một tài sản/nội dung khác mặc dù tổ chức đã sở hữu một (hoặc nhiều) cái tương tự. Hoặc họ học được một số kỹ thuật, chiến lược mới phục vụ tốt công việc của họ, nhưng không chia sẻ với những nhóm khác.
• Bộ phận/Phòng ban (Departmental): Mọi người xem xét nhu cầu của cả bộ phận/phòng ban mình, không chỉ là đội nhóm của họ.
• Doanh nghiệp (Enterprise): Mọi người có động lực để xem xét các nhu cầu tổng thể của tổ chức mình, để đảm bảo rằng những gì họ đang làm đóng góp tích cực vào các mục tiêu của tổ chức chứ không chỉ cho các mục tiêu tối ưu của nhóm họ. 
• Hệ sinh thái - Cộng đồng (Ecosystem): Mọi người xem xét nhu cầu của hệ sinh thái tổng thể mà họ thuộc về, làm những gì mà họ có thể như chia sẻ kiến thức hoặc bằng cách nào đó giúp mọi thứ trở nên tốt hơn cho những người khác bên ngoài tổ chức của họ. Đây cũng được gọi là nhận thức xã hội hoặc đôi khi là nhận thức cộng đồng.

Tất nhiên, bất kỳ cá nhân nhất định nào cũng sẽ hoạt động tại nhiều cấp độ hoặc quan điểm cùng một lúc.

Ý nghĩa của việc nhận thức về doanh nghiệp

Nhận thức về doanh nghiệp là một khía cạnh quan trọng của kỷ luật bản thân bởi vì là một chuyên gia, bạn nên cố gắng làm những gì phù hợp với tổ chức của bạn chứ không chỉ những gì thú vị đối với bạn. Các nhóm phát triển riêng lẻ có thể chọn xây dựng thứ gì đó từ đầu hoặc sử dụng các công cụ phát triển khác nhau hoặc tạo các nguồn dữ liệu khác nhau dựa trên các nguồn đã được cài đặt, thử nghiệm, cấu hình và tinh chỉnh thành công đã tồn tại trong tổ chức. Các chuyên gia Disciplined Agile sẽ:

• Làm việc chặt chẽ với các chuyên gia trong doanh nghiệp: Điều này bao gồm hợp tác chặt chẽ với:
  • Các kiến trúc sư kỹ thuật doanh nghiệp (enterprise technical architects) để tận dụng và nâng cao cơ sở hạ tầng kỹ thuật hiện có
  • Kiến trúc sư doanh nghiệp (enterprise architects) và người quản lý danh mục (portfolio manager) để phù hợp với hệ sinh thái kinh doanh tổng thể
  • Quản lý cấp cao để điều hành các nhóm khác nhau một cách thích hợp
  • Nhân viên vận hành để hỗ trợ các nỗ lực phát triển và vận hành tổng thể (DevOps) của tổ chức
  • Quản trị viên dữ liệu để truy cập và cải thiện các nguồn dữ liệu hiện có
  • Phát triển công nghệ thông tin hỗ trợ mọi người hiểu và làm theo hướng dẫn CNTT của doanh nghiệp
  • Các chuyên gia kinh doanh, những người chia sẻ thông tin chi tiết về thị trường, dự báo bán hàng, dự báo dịch vụ và các mối quan tâm quan trọng khác của họ.
  • Nói cách khác, các nhóm nên áp dụng một tư duy “toàn bộ doanh nghiệp - whole enterprise”.
• Áp dụng và làm theo hướng dẫn của doanh nghiệp: Tổ chức của chúng ta có thể có hoặc hy vọng một ngày nào đó sẽ có một loạt các tiêu chuẩn và các hướng dẫn mà tổ chức muốn các nhóm giải pháp áp dụng và tuân theo. Điều này có thể bao gồm hướng dẫn về viết code, phát triển giao diện người dùng, bảo mật và các quy ước dữ liệu. Làm theo hướng dẫn chung sẽ giúp tăng tính nhất quán và khả năng bảo trì của các giải pháp, cũng như nâng cao chất lượng tổng thể của chúng ta.
• Tận dụng tài sản sẵn có của doanh nghiệp: Có ít hoặc nhiều tài sản sẵn có của doanh nghiệp mà chúng ta có thể sử dụng và phát triển. Các nhóm Disciplined Agile cố gắng làm việc với một cơ sở hạ tầng chung; ví dụ: họ sử dụng các công nghệ và nguồn dữ liệu được doanh nghiệp phê duyệt bất cứ khi nào có thể, và tốt hơn nữa là họ làm việc đóng góp cho tầm nhìn “tương lai” cho cơ sở hạ tầng của doanh nghiệp. Nếu tổ chức của chúng ta sử dụng cách tiếp cận tập trung vào kiến trúc có kỷ luật để xây dựng phần mềm doanh nghiệp, thì sẽ có một thư viện ngày càng lớn gồm các thành phần hướng dịch vụ có thể tái sử dụng và cải tiến vì lợi ích của tất cả các giải pháp hiện tại và tương lai. Để thực hiện điều này, các nhóm DA sẽ cộng tác với các chuyên gia của doanh nghiệp trong suốt vòng đời giải pháp và đặc biệt là ở giai đoạn khởi động, lúc hình thành tầm nhìn của giải pháp. Hình 6 tóm tắt mục tiêu của việc Phù hợp với định hướng doanh nghiệp, tóm tắt các chiến lược chúng ta có thể chọn làm theo.

Hình 6. Mục tiêu: Phù hợp với định hướng doanh nghiệp
 

• Nâng cao hệ sinh thái tổ chức của chúng ta: Giải pháp được đưa ra bởi một nhóm DA phải phù hợp tối thiểu với hệ sinh thái tổ chức hiện có - các quy trình kinh doanh và hệ thống hỗ trợ - tốt hơn hết nên tăng cường hệ sinh thái đó. Để làm được điều này, bước đầu tiên là tận dụng tài sản doanh nghiệp hiện có ở bất kỳ đâu có thể như đã mô tả ở trên, thường xuyên làm việc với các kiến trúc sư doanh nghiệp. Ngoài các kiến trúc sư doanh nghiệp, các nhóm DA cũng sẽ làm việc với các nhân viên vận hành và hỗ trợ chặt chẽ trong suốt vòng đời để đảm bảo rằng họ hiểu được trạng thái hiện tại và định hướng của hệ sinh thái của tổ chức. Nhóm DA thường sẽ được hỗ trợ bởi một nhóm kiểm tra độc lập bổ sung, thực hiện kiểm tra tích hợp (giữa nhiều hệ thống với nhau) để đảm bảo rằng giải pháp của chúng ta hoạt động tốt trong môi trường thực tế tại thời điểm triển khai. Hơn nữa, các nhóm DA có kinh nghiệm thậm chí sẽ khắc phục các sự cố mà họ gặp phải thông qua các kỹ thuật tái cấu trúc đã được chứng minh. Hình 7 tóm tắt mục tiêu Tận dụng và nâng cao cơ sở hạ tầng hiện có, tóm tắt các chiến lược về cách các nhóm DA có thể thực hiện điều này.

Hình 7. Mục tiêu: Tận dụng và nâng cao cơ sở hạ tầng hiện có
 

• Áp dụng văn hóa DevOps: Các nhóm DA sẽ làm việc chặt chẽ với bộ phận vận hành và nhân viên hỗ trợ trong suốt vòng đời của giải pháp, đặc biệt là càng gần thời điểm chúng ta đưa giải pháp vào sử dụng thực tế. Văn hóa và chiến lược DevOps được tích hợp sẵn trong DA.
• Chia sẻ kiến thức: Các nhóm Disciplined Agile học tập theo định hướng và một cách để học đó là lắng nghe kinh nghiệm của những người khác. Các nhóm DA sẽ chuẩn bị để chia sẻ những kiến thức của riêng họ với các nhóm khác. Để làm được điều này, các tổ chức có thể hỗ trợ tạo ra các diễn đàn thảo luận về Agile, các bài thuyết trình, các buổi đào tạo từ các thành viên nhiều kinh nghiệm và các hội nghị nội bộ để giới thiệu một số chiến lược.
• Áp dụng các chiến lược quản trị phù hợp: Chiến lược quản trị hiệu quả nên nâng cao những gì đang được quản trị. Cách tiếp cận thích hợp để quản trị các dự án Agile (hoặc các loại khác), là dựa trên việc thúc đẩy và sau đó cho phép mọi người làm những gì phù hợp, đúng đắn với tổ chức của chúng ta. Tất nhiên, điều gì là đúng sẽ rất đa dạng, nhưng điều này thường bao gồm việc thúc đẩy các nhóm tận dụng và phát triển các tài sản hiện có của công ty theo các nguyên tắc chung để tăng tính nhất quán và hướng tới một tầm nhìn chung cho tổ chức của chúng ta. Quản trị phù hợp dựa trên sự tin tưởng và cộng tác. Các chiến lược quản trị phù hợp cần nâng cao khả năng của các nhóm DA trong việc đem lại giá trị cho các bên liên quan của họ một cách hiệu quả về chi phí và kịp thời về thời gian. Thật không may, hiện nay có rất nhiều chiến lược quản trị công nghệ thông tin đang dựa trên cách tiếp cận quan liêu đó là “chỉ đạo và kiểm soát” (command and control) dẫn đến không hiệu quả trong thực tế.
• Giám sát cởi mở và trung thực: Các phương pháp Agile dựa trên sự tin tưởng, còn các chiến lược quản trị thông minh dựa trên tư duy “tin tưởng nhưng cần được xác minh và sau đó hướng dẫn” - trust but verify and then guide. Một khía cạnh quan trọng của quản trị thích hợp là giám sát các nhóm dự án thông qua nhiều phương tiện khác nhau. Một chiến lược dành cho bất kỳ ai quan tâm đến tình trạng hiện tại của nhóm DA chính là có thể tham dự cuộc họp điều phối hàng ngày và lắng nghe họ trao đổi - một chiến lược do cộng đồng Scrum đề xuất. Mặc dù đó là một chiến lược tuyệt vời cần được khuyến khích, nhưng việc mở rộng quy mô của nó không được tốt lắm vì các nhà quản lý cấp cao chịu trách nhiệm quản trị thường là những người bận rộn với nhiều công việc điều hành, sự quan tâm của họ không chỉ dành cho nhóm của chúng ta. Do đó, có thể nghĩ về các chiến lược phức tạp hơn như cách sử dụng dashboard cập nhật thông tin tự động.

Tại sao nhận thức về doanh nghiệp lại quan trọng?

Agile đã thực hiện một công việc tuyệt vời trong việc giúp ngành công nghệ thông tin tái tập trung từ nhận thức cá nhân sang nhận thức nhóm. Nhưng nếu chúng ta muốn trở nên hiệu quả với tư cách là những chuyên gia, ít nhất chúng ta cần phải thúc đẩy triết lý nhận thức về doanh nghiệp, nhằm tối ưu hóa công việc mà chúng ta làm cho tổ chức của mình. Các nhóm agile hiểu rõ về doanh nghiệp sẽ hợp tác chặt chẽ với các chuyên gia doanh nghiệp, chẳng hạn như kiến trúc sư doanh nghiệp và nhân viên vận hành, để đảm bảo rằng họ đang tận dụng và nâng cao cơ sở hạ tầng hiện có một cách tốt hơn. Kiến trúc sẽ phản ánh lộ trình kỹ thuật của tổ chức và từ đó sẽ phản ánh lộ trình kinh doanh của tổ chức. Chúng ta sẽ tuân theo các hướng dẫn phát triển hiện có và nâng cao chúng khi thích hợp.

Bằng cách làm việc theo cách có ý thức về doanh nghiệp, các nhóm DA được có được:

• Mức năng suất cao hơn vì họ ít có khả năng phải phát minh lại những thứ đã có sẵn
• Thời gian triển khai / tiếp thị nhanh hơn vì họ có ít việc phải làm hơn
• Lợi tức đầu tư (ROI) cao hơn vì khối lượng công việc của họ ít hơn
• Mức chất lượng cao hơn thông qua việc tuân theo các quy ước chung và tái sử dụng

Những thách thức đối với nhận thức về doanh nghiệp

Có hai thách thức chính trong việc hỗ trợ nhận thức về doanh nghiệp đối với các nhóm agile. 
-    Đầu tiên là thách thức văn hóa trong cộng đồng agile mà một số “người theo chủ nghĩa agile thuần túy - agile purists” cho rằng điều này là không cần thiết. Những lý do dẫn đến sự hiểu lầm này bao gồm sự thiếu hiểu biết về bức tranh tổng thể của doanh nghiệp hoặc những người này trước đây làm việc với các với các chuyên gia doanh nghiệp gặp khó khăn trong việc áp dụng agile.
-    Thách thức thứ hai là các chuyên gia doanh nghiệp thường không hiểu cách làm việc của các nhóm agile. Đôi khi điều này là do các nhóm agile đã làm việc chưa đủ kỷ luật, nhưng phần lớn là do các chuyên gia doanh nghiệp vẫn chọn cách tiếp cận cũ, cách tiếp cận truyền thống.

Những thách thức này mang bản chất văn hóa và do đó khá khó vượt qua. Những người theo chủ nghĩa Agile thuần túy và các chuyên gia doanh nghiệp cần tôn trọng lẫn nhau và cố gắng tìm hiểu thêm về những gì nhóm kia đang cố gắng hoàn thành. Họ phải cố gắng làm việc và học hỏi lẫn nhau. Hơn nữa, họ phải xây dựng văn hóa cam kết chung và trách nhiệm với tổ chức. Điều này không chỉ có thể mà nó còn rất đáng mong đợi.

Các nhóm Disciplined Agile và quan trọng hơn là những người thực hiện DA là những người có nhận thức về doanh nghiệp. Họ nhận ra rằng các chiến lược nhận thức về doanh nghiệp cải thiện khả năng cung cấp giá trị cho các bên liên quan của họ cả trong phạm vi giải pháp cũng như ở cấp độ tổ chức. Những người áp dụng Disciplined Agile “hành động cục bộ, suy nghĩ toàn bộ” - “act locally and think globally”.

Sự kết thúc của Agile? Không, là sự kết thúc của Undisciplined Agile.

Disciplined Agile là gì? Tại sao nên áp dụng Disciplined Agile?

Hệ tư duy của Disciplined Agile - Disciplined Agile Mindset

8 nguyên tắc trong Disciplined Agile

Tổng quan về Disciplined Agile Delivery - Một phần thiết yếu của Disciplined Agile

Vai trò, quyền và trách nhiệm của đội Disciplined Agile Delivery

DASM ONLINE PRO - CHƯƠNG TRÌNH LUYỆN THI DASM HIỆU QUẢ

DASSM ONLINE PRO - CHƯƠNG TRÌNH LUYỆN THI DASSM HIỆU QUẢ