Agile được tạo ra để giúp các nhóm linh hoạt trước sự thay đổi, chứ không phải để đẩy họ vào trạng thái luôn căng thẳng và chạy nước rút liên tục.

Tuy nhiên, trong nhiều tổ chức, “agile” dần bị hiểu sai và dần bị đồng nhất với việc lúc nào cũng bận rộn, gần như không còn khoảng trống để tạm dừng hay để cả đội kịp… thở. Các sprint hai tuần cứ nối tiếp nhau không có điểm dừng. Danh sách công việc trong Backlog luôn trong tình trạng quá tải. Nhóm dự án được khen ngợi vì “luôn bận rộn” và “hoàn thành cam kết”, thay vì vì họ thực sự tạo ra giá trị có ý nghĩa.

Mô hình “Always On” này, nhìn từ góc độ lãnh đạo, có vẻ rất hiệu quả. Mọi thứ đều chuyển động: bảng kéo thả công việc kín tasks, các buổi họp diễn ra đều đặn, số liệu được báo cáo đầy đủ, vận tốc luôn đạt. Bề ngoài, tổ chức trông như đang vận hành trơn tru. Nhưng ẩn dưới bề mặt năng động ấy là một thực tế không hề dễ chịu:

• Các nhóm hiếm khi có thời gian để suy nghĩ, hồi phục hoặc điều chỉnh lại cách làm việc.
• Việc học hỏi bị trì hoãn để ưu tiên cho việc bàn giao kết quả.
• Các vấn đề về chất lượng không được đảm bảo đang dần tích tụ, rồi bùng phát cùng lúc. Thường là khi khách hàng phàn nàn hoặc hệ thống gặp sự cố, hiệu quả sản xuất giảm.
• Sự kiệt sức không xuất hiện như một cú sụp đổ đột ngột, mà là sự bào mòn dần dần về năng lượng, sự tò mò, khả năng học hỏi và phán đoán của các thành viên.

Điều nguy hiểm nhất là mô hình này dần trở nên bình thường hóa. Việc chạy nước rút liên tục được xem là dấu hiệu của sự trưởng thành. Ngược lại, việc giảm tốc bị coi là thiếu kỷ luật, thiếu động lực, thậm chí là hiệu suất kém. Khi vận tốc giảm, phản ứng quen thuộc là tạo thêm áp lực, siết chặt cam kết và cắt bớt các khoảng dừng - chính những điều này đã tạo ra vấn đề ngay từ đầu.

Đây không phải là thất bại của triết lý Agile. Đây là thất bại trong cách hiểu và vận dụng Agile. Sự linh hoạt thực sự đòi hỏi khả năng cảm nhận, thích ứng và đưa ra lựa chọn một cách có chủ đích. Điều đó trở nên bất khả thi khi các nhóm bị mắc kẹt trong trạng thái thực thi liên tục. Thứ trông giống như tốc độ rồi sẽ trở thành lực cản, và cảm giác “có đà” dần biến thành sự mệt mỏi mà ít ai nhận ra.

Chạy nước rút liên tục và ảo tưởng về sự tiến bộ

Việc chạy sprint không ngừng tạo ra một ảo tưởng rất mạnh: khi công việc luôn được đẩy đi và mọi người lúc nào cũng bận rộn, ta dễ tin rằng dự án đang tiến triển. Kế hoạch sprint được lấp đầy, các cam kết được đưa ra, và thành công của đội ngũ được đo bằng việc các user story có hoàn thành đúng hạn hay không.

Dần dần, bản thân sprint trở thành đơn vị đo lường thành công, thay vì giá trị mà nó mang lại. Việc đạt chỉ số velocity bắt đầu quan trọng ngang bằng - thậm chí quan trọng hơn - so với việc mang lại những kết quả thực sự có ý nghĩa.

Sự chuyển dịch này âm thầm làm thay đổi hành vi của các thành viên trong đội dự án. Backlog được sắp xếp để “sẵn sàng triển khai” hơn là để tạo ra tác động có giá trị. Công việc được chia nhỏ không phải vì giúp hiểu rõ vấn đề hơn, mà vì nó vừa vặn với ranh giới của một sprint. Những quyết định khó khăn bị trì hoãn để ưu tiên cho việc “tiến lên từng bước”, ngay cả khi hướng đi đó là sai. Câu hỏi dẫn dắt đội nhóm dần chuyển từ “Chúng ta có kịp hoàn thành việc này trong sprint không?” sang “Chúng ta có nên làm việc này hay không?”

Khi sprint nào cũng mang mức độ khẩn cấp như nhau, việc ưu tiên dần trở nên mất ý nghĩa. Mọi thứ đều quan trọng, nên cuối cùng không có gì thực sự quan trọng. Các nhóm vẫn bận rộn, nhưng ngày càng xa rời kết quả thực tế. Các bên liên quan nhìn thấy đầu ra đều đặn, nhưng giá trị mang lại thì giảm dần. Cuối cùng, tổ chức nhầm lẫn giữa sự ổn định và hiệu quả, giữa năng suất có thể dự đoán được và tiến bộ thực sự.

Agile được thiết kế để tạo ra các vòng lặp phản hồi nhằm cung cấp sản phẩm có giá trị cho khách hàng. Việc chạy sprint liên tục đã nén các vòng phản hồi này đến mức chúng không còn phát huy tác dụng. Không có thời gian để nhìn lại, đội ngũ không thể điều chỉnh hướng đi. Không có không gian để làm rõ các giả định, họ chỉ vô tình củng cố chính những giả định đó.

Cuối cùng, thứ còn lại chỉ là một cỗ máy bàn giao sản phẩm được bổ sung “dầu nhớt” liên tục - chạy rất nhanh, nhưng ngày càng kém hiệu quả, và lao về một hướng… không hề quan trọng.

Kiệt sức là thất bại của hệ thống, không phải của đội nhóm

Trong các môi trường Agile, kiệt sức thường bị chẩn đoán sai là vấn đề cá nhân hoặc của cả nhóm. Do đó, họ thường khuyến khích đội nhóm “kiên cường hơn”, “quản lý căng thẳng tốt hơn”, hoặc “cân bằng công việc - cuộc sống hiệu quả hơn”. Những ý kiến này mặc định rằng vấn đề nằm ở con người. Nhưng trên thực tế, kiệt sức gần như luôn là kết quả tất yếu của một hệ thống đòi hỏi cường độ cao kéo dài mà không cho phép hồi phục.

Lao động trí óc dựa vào khả năng phán đoán, sáng tạo và giải quyết vấn đề - đều là những năng lực không thể hoạt động ở trạng thái tối ưu dưới áp lực liên tục. Khi đội nhóm chuyển từ sprint này sang sprint khác không có khoảng dừng, gánh nặng nhận thức tích tụ. Việc chuyển đổi ngữ cảnh diễn ra thường xuyên hơn. Những thỏa hiệp nhỏ về chất lượng bắt đầu trở nên “bình thường”. Các buổi retrospective, nếu còn diễn ra thì thường chỉ tập trung sửa lỗi mang tính chiến thuật hơn là thay đổi cấu trúc.

Theo thời gian, đội ngũ ngừng lên tiếng vì họ không thấy điều gì thực sự thay đổi. Họ chấp nhận kiệt sức như cái giá phải trả cho sự “đáng tin cậy” của mỗi thành viên. Velocity giảm - không phải vì mọi người bớt quan tâm, mà vì hệ thống đã bào mòn năng lực suy nghĩ rõ ràng và khả năng làm việc bền vững của họ.

Điều gây tổn hại nhất của vòng lặp này là khả năng vô hình của nó. Kiệt sức hiếm khi xuất hiện như một thất bại rõ ràng và nghiêm trọng. Nó biểu hiện qua những quyết định chậm hơn, sự dè dặt trong thử nghiệm và sự ngại ngần âm thầm trong việc quyết định hướng đi. Tổ chức diễn giải điều đó là sự trì trệ, trong khi nó được chẩn đoán chính xác hơn là sự mệt mỏi.

Cho đến khi lãnh đạo thừa nhận rằng kiệt sức là một lỗ hổng trong thiết kế nhịp độ làm việc, thì không một chiến lược “tự thích nghi” hay kỹ năng đối phó cá nhân nào có thể giải quyết triệt để vấn đề này.

Tính linh hoạt bền vững đòi hỏi nhịp độ làm việc có chủ đích

Agile bền vững không có nghĩa là làm việc ít đi, mà là làm việc một cách có chủ đích. Những đội ngũ hiệu quả cao không duy trì cường độ tối đa liên tục. Họ biết điều chỉnh nhịp độ: tạo không gian cho việc học hỏi, hồi phục và tư duy chiến lược, rồi dồn năng lượng tập trung vào những thời điểm thực sự quan trọng.

Nhịp độ có chủ đích đồng nghĩa với việc thừa nhận rằng không phải sprint nào cũng là một cuộc nước rút về đích. Cách tiếp cận này cho phép có buffer về năng lực, thay vì giả định đội ngũ luôn phải hoạt động ở mức 100%. Nó xem các hoạt động khám phá, tái cấu trúc và cải tiến là một phần thiết yếu của công việc, chứ không phải việc “làm thêm nếu còn thời gian”. Quan trọng hơn, nó tách nhịp độ lập kế hoạch ra khỏi áp lực bàn giao sản phẩm liên tục.

Lúc này, lãnh đạo giữ vai trò then chốt để điều hướng đội nhóm. Tại một thời điểm khi sự khẩn trương là yêu cầu cần thiết, đội nhóm cần đáp ứng ràng buộc này. Khi sự tiết chế được thể hiện rõ ràng, các nhà lãnh đạo bảo vệ sự linh hoạt, duy trì sự tập trung và tránh sự cam kết quá mức - nhóm sẽ có được sự cho phép để làm việc bền vững mà không sợ bị coi là thiếu tận tâm.

Cách tiếp cận này không làm giảm trách nhiệm, mà ngược lại còn củng cố hơn. Những đội ngũ có khả năng tạm dừng sẽ thích ứng nhanh hơn các đội bị cuốn vào chuyển động liên tục. Họ đưa ra quyết định tốt hơn, phát hiện vấn đề sớm hơn và duy trì được năng lượng trong dài hạn. Agile bền vững chấp nhận đánh đổi những đợt tăng tốc ngắn hạn để lấy động lực lâu dài - một sự đánh đổi luôn mang lại hiệu quả

Mối nguy của một chuỗi sprint “hoàn hảo”

Ông Gerardi từng quản lý một đội dự án có các chỉ số Agile gần như hoàn hảo. Hai mươi bốn sprint liên tiếp mà không bỏ lỡ bất kỳ cam kết nào.

Mỗi buổi lập kế hoạch đều kết thúc bằng những cái gật đầu đầy tự tin và phạm vi công việc đầy tham vọng. Tốc độ luôn đáp ứng, thậm chí sớm hơn mục tiêu đề ra. WIP (Work in progress) được kiểm soát. Thời gian hoàn thành công việc luôn nằm trong top đầu. Tổ chức của họ có các buổi đánh giá “team hygiene” hằng tháng, và đội của ông dường như không bao giờ được nhắc tên, vì chẳng có gì để chỉ trích. Lãnh đạo thường đưa nhóm ông ra làm hình mẫu cho “agile đúng chuẩn”.

Rồi những vấn đề nhỏ bắt đầu xuất hiện. Một sự cố sản xuất đã xảy ra, một quyết định bị trì hoãn tại đó. Không nghiêm trọng đến mức phải báo động, nhưng đủ để tạo ra ma sát. Và đội phản ứng theo cách duy nhất mà họ biết là làm việc chăm chỉ hơn nữa.

Kế hoạch sprint ngày càng chặt. Định nghĩa về “sự sẵn sàng” trở nên khắt khe hơn. Buổi retrospective biến thành những checklist vội vàng để mọi người nhanh chóng quay lại công việc là bàn giao sản phẩm. Không ít lần, các thành viên đã bắt đầu làm việc cho sprint kế tiếp ngay trong lúc đang retro sprint hiện tại. Điều đó rõ ràng là không tốt.

Điều không bao giờ xuất hiện trên bảng kéo thả tasks là mức độ mệt mỏi của họ. Kỹ sư dần ngừng chất vấn những yêu cầu chưa rõ ràng. Các cuộc trao đổi về sản phẩm trở nên mang tính giao dịch nhiều hơn là hợp tác. Những sự cố sản xuất nhỏ cứ liên tục tái diễn, làm tiêu hao sự tập trung và năng lượng. Công việc vẫn hoàn thành, nhưng không ai tin rằng mọi thứ đang thực sự tốt lên. 

Đỉnh điểm của vấn đề là sprint vẫn diễn ra, nhóm lập kế hoạch mà không có một sự tranh luận nào. User story được chấp nhận không cần bàn cãi. Ước tính bị làm tròn xuống - 5 thành 3, 8 thì bị bẻ nhỏ thành ba lần 2. Rủi ro không được nhắc tới. Theo như kế hoạch, sprint kết thúc đúng hạn và lãnh đạo chúc mừng nhóm. Thực tế, nhóm của họ hoàn toàn có thể mang nguyên mấy chúc item ở đầu backlog vào sprint và kết thúc buổi họp trong vòng năm phút.

Hai tháng sau, một sự cố nghiêm trọng - hoàn toàn có thể tránh được - buộc hệ thống phải dừng lại. Trong báo cáo phân tích sau sự cố, nguyên nhân gốc rễ không phải là kỹ thuật. Nhóm đã biết rõ rủi ro nhưng chọn cách không nói ra. Thậm chí đã có một ticket về rủi ro này nằm trong backlog nhưng không được chỉ định và không được ưu tiên. Nó chưa bao giờ được thảo luận. Vì họ không tin rằng chiếc bảng còn đủ “không gian” để thêm nó vào.

Hệ thống đã huấn luyện họ tiếp tục chạy, nhưng thực chất giảm tốc mới là con đường nhanh nhất và an toàn nhất để cải thiện hiệu suất và phát triển.

Biết “khi nào nên chạy” mới là hình thức Agile bền vững

Agile chưa bao giờ được tạo ra để khiến con người kiệt sức. Lời hứa cốt lõi của Agile là khả năng thích ứng, chứ không phải sự bào mòn. Huyền thoại về một Agile “Always On” vẫn tồn tại vì nó tạo cảm giác an toàn, dễ đo lường và dễ kiểm soát. Nhưng theo thời gian, chính nó lại làm suy yếu những năng lực mà tổ chức phụ thuộc vào.

Sự linh hoạt thực sự không thể hiện qua từng sprint riêng lẻ, mà bộc lộ qua nhiều tháng, thậm chí nhiều năm. Nó xuất hiện ở những đội ngũ có thể giảm tốc mà không bị khựng lại, có thể nhìn lại mà không mất đà phát triển, và có thể tăng tốc khi cần mà không rơi vào kiệt sức. Nhịp độ bền vững không phải là sự nhượng bộ cho sự “thoải mái”, đó là cam kết cho sự lâu dài và điều này vốn đã nằm trong tinh thần cốt lõi của Agile.

Những tổ chức chấp nhận nhịp độ bền vững không phải là những tổ chức phát triển ít hơn. Họ đang phát triển theo cách tốt hơn. Họ bảo toàn khả năng phán đoán, gìn giữ sự sáng tạo và xây dựng những hệ thống có thể tồn tại theo thời gian. Trong một thế giới đề cao khả năng thích ứng, những đội linh hoạt nhất không phải là những đội chạy nước rút không ngừng, mà là những đội vẫn còn đủ tỉnh táo để lựa chọn khi nào nên chạy. 

Tổng kết

Chạy nước rút liên tục không phải là Agile, mà là trạng thái khẩn trương được ngụy trang dưới lớp vỏ kỷ luật. Khi đội nhóm ở trạng thái “Always On”, họ dần đánh mất không gian cần thiết cho việc đánh giá, học hỏi và thích ứng một cách có ý nghĩa.

Tốc độ là thước đo đầu ra, không phải thước đo giá trị. Khi việc hoàn thành cam kết sprint trở thành mục tiêu chính, đội nhóm sẽ ưu tiên sự chuyển động thay vì kết quả. Và cảm giác “tiến bộ” chỉ là một ảo tưởng.

Kiệt sức là thất bại của hệ thống, không phải điểm yếu của đội nhóm. Cường độ cao kéo dài mà không hồi phục sẽ tất yếu làm suy giảm khả năng ra quyết định, chất lượng và hiệu suất dài hạn.

Agile bền vững đòi hỏi tốc độ bền vững. Những đội nhóm hiệu suất cao biết điều chỉnh nhịp độ làm việc, nâng cao năng lực học hỏi và cải tiến, đồng thời tách nhịp độ lập kế hoạch khỏi áp lực bàn giao sản phẩm liên tục.

Đội ngũ Agile cần biết khi nào nên chậm lại. Khả năng tạm dừng, suy ngẫm và điều chỉnh hướng đi chính là điều cho phép tăng tốc nhanh hơn và an toàn hơn khi thực sự cần thiết.

Tác giả: Bart Gerardi | Nguồn: PMI