Trong suốt sự nghiệp, bất kỳ project manager nào cũng sẽ gặp “một developer như thế”. Có thể bạn đã từng: Một developer xuất sắc. Họ làm việc nhanh, trở thành người được tìm đến khi tình hình căng thẳng. Code của họ sạch, logic chặt chẽ, review vừa hữu ích vừa khả thi. Nhưng có một vấn đề: Họ nghĩ agile là trò đùa và từ chối tham gia.

Điều này thể hiện ở việc đến muộn trong standups (nếu họ thèm đến), bỏ qua retros hoặc demos với lý do “ai cũng biết story là gì rồi”. Hoặc họ đảo mắt khi planning, nói rằng nhanh nhất là cứ giao task cho họ rồi để họ đi làm, khỏi mất thời gian trong cuộc họp.

Vấn đề? Họ không hoàn toàn sai.

Ở quá nhiều nhóm, agile có thể trở thành lãng phí thời gian. Nó biến thành cứng nhắc, rườm rà, tập trung vào nghi lễ và quy trình hơn là kết quả thực sự. Có thể trước đây họ từng ở trong một tổ chức nơi stand-up chỉ là công cụ báo cáo trạng thái, hoặc các cuộc họp và retros chỉ là chỗ xả bức xúc mà chẳng có gì thay đổi.

Vấn đề là khi một người chọn không tuân theo nguyên tắc, dù họ có tài giỏi đến đâu, họ cũng tạo ra sự gián đoạn và phân tâm cho cả nhóm. Sự đồng bộ gãy vỡ, niềm tin lung lay, chia sẻ kiến thức cạn kiệt. Dần dần, team velocity và tinh thần giảm sút, “bỏ họp” dẫn đến bỏ lỡ các dependency, và cuối cùng là sự bất mãn từ những người vẫn cố gắng hợp tác.

Agile không nhằm kiểm soát “rockstar”, mà là để cả ban nhạc cùng chơi với nhau. Mục tiêu không phải là hạn chế cá nhân, mà là khai thác nó cho thành công chung. Là một quản lý nhóm agile—dù là product, project hay scrum master—mục tiêu của bạn là thay đổi cách cả nhóm nhìn nhận agile, và đưa những cá nhân xuất sắc trở lại mà không biến nó thành cuộc đấu quyền lực.

Hiểu Nguồn Gốc Sự Chống Đối

Giống như mọi việc khác, trước khi thay đổi hành vi, bạn cần hiểu lý do. Developer có thể không thực sự khó tính hay kiêu ngạo; họ có thể bực bội, từng trải qua kinh nghiệm tồi, hoặc đơn giản là bị hiểu lầm.

Hãy bắt đầu bằng giả định thiện chí, cho rằng sự chống đối xuất phát từ trải nghiệm. Có thể họ từng thấy agile bị áp dụng tệ hại, nơi standups chỉ là báo cáo trạng thái, hoặc nơi sprints tạo thêm hỗn loạn thay vì giải quyết. Nhiều developer gắn scrum với “overhead” hơn là năng suất. Hoặc họ cảm thấy quy trình đang được ưu tiên hơn tiến độ.

Cũng có thể họ nghĩ agile không tôn trọng phong cách làm việc của họ. Một số developer cần những khoảng thời gian tập trung dài, không bị gián đoạn, còn họp hành và check-in chỉ làm phiền. Với họ, các scrum ceremonies là “flow killer” chứ không phải công cụ hỗ trợ, và họ muốn tránh xa.

Đó là lý do bước đầu tiên phải là trò chuyện. Đừng gọi họ ra trước mặt cả nhóm (ít nhất là ban đầu), hãy nói riêng về trải nghiệm của họ. Đặt những câu hỏi như:

• Trải nghiệm của bạn với agile trong sự nghiệp như thế nào?
• Phần nào trong quy trình hiện tại khiến bạn khó chịu nhất?
• Làm sao để việc này hữu ích hơn cho bạn và cho nhóm?

Điều này mang lại hai tác dụng: cho họ tiếng nói, và cho thấy bạn thật sự muốn cải thiện. Nhiều khi chỉ cần được lắng nghe cũng giúp giảm chống đối.

Khi đã hiểu nguyên nhân gốc rễ—dù là agile burnout, sự hoài nghi chung, hay vấn đề thực sự với cách nhóm vận hành—bạn có thể giải quyết cùng nhau thay vì áp đặt.

Chuyển Cuộc Trò Chuyện: Từ Quy Trình Sang Mục Đích

Sai lầm lớn nhất của những người cổ vũ agile là cố thuyết phục bằng cách nhắc lại các yếu tố của framework. Điều này thường thấy ở scrum masters và project managers:

• “Chúng ta làm sprint planning vì không thì lên sprint thế nào?” không phải lý lẽ thuyết phục nếu ai đó vốn không tin vào giá trị của sprint.
• “Chúng ta có daily standup mỗi ngày, nó nằm ngay trong tên rồi!” chắc chắn khiến người ta bực hơn là thuyết phục.

Muốn thay đổi, bạn phải chỉ ra giá trị—không chỉ là nghi lễ hay framework. Developer tôn trọng công cụ giúp họ giải quyết vấn đề, và ghét những thứ chỉ lấy đi thời gian mà chẳng giải quyết gì. Vì vậy, hãy nói về outcomes, không chỉ về overhead.

Ví dụ:

• Thay vì: “Chúng ta cần sprint planning để có sprint đầy đủ”, hãy nói: “Planning giúp bảo vệ thời gian của bạn, để bạn có thể lên kế hoạch 2 tuần tới mà không bị gián đoạn.”
• Thay vì: “Bạn phải tham gia retro vì nó là một phần của quy trình”, hãy nói: “Retro giúp chúng ta tiến bộ, và là cơ hội để bạn chia sẻ mối lo ngại với cả nhóm.”
• Đừng nói: “Bạn cần update ticket mỗi ngày, nó là quy trình”, hãy nói: “Giữ ticket cập nhật giúp tránh việc mọi người liên tục làm phiền bạn để hỏi tiến độ và ngăn ngừa trùng lặp.”

Hãy trình bày quy trình agile như tấm lá chắn, chứ không phải lãng phí thời gian. Giải thích rằng các agile metrics như velocity, WIP limits, story points nhằm giảm hỗn loạn, chỉ ra khối lượng công việc ẩn, và ngăn ngừa developer burnout.

Câu Chuyện Ngắn: Từ Người Hoài Nghi Thành Người Ủng Hộ

Tôi từng làm việc với một backend engineer tên Michael. Anh ta giỏi, nhanh, kỹ lưỡng… và cực kỳ dị ứng với mọi quy trình.

Anh thường bỏ retros, tham gia stand-ups lúc có lúc không (hoặc ngồi đó mà chẳng nghe gì), và chỉ tạo Jira tickets sau khi code xong. Ban đầu tôi cố ép anh dùng framework nhiều hơn; điều đó không hiệu quả, mà còn khiến anh xa cách hơn.

Tôi thử cách khác. Trong một buổi one-on-one, tôi hỏi anh ghét gì nhất ở agile. Danh sách khá dài, nhưng tóm lại: “Tôi ghét nói về công việc hơn là làm công việc.” Khó mà tranh cãi.

Chúng tôi cùng nhau cắt giảm vài cuộc họp, chuyển một số sang ít thường xuyên hơn, và để anh góp ý ngay cả khi đang họp. Tôi cũng chỉ cho anh thấy team front-end đã tạo ticket trùng lặp do anh không mở kịp thời.

Dần dần, anh bắt đầu tin vào outcomes chúng tôi thảo luận—ít blocker, ít hỗn loạn, ít bị gián đoạn. Anh chưa bao giờ chấp nhận toàn bộ framework, nhưng anh thừa nhận một số phần có giá trị, và chủ động đảm bảo nhóm còn lại làm đúng phần việc.

Đó là một chiến thắng nhỏ, nhưng quan trọng.

Người Xuất Sắc Cũng Phải Là Người Đồng Đội

Khi có một thành viên xuất sắc thách thức các chuẩn mực agile, bản năng thường là kéo họ vào hoặc thả cho họ tự do. Cả hai đều không hiệu quả; bạn phải hướng sức mạnh của họ vào trong nhóm—không phải ngoài lề hay đối lập.

Hãy công nhận những gì họ mang lại: nhanh nhẹn, sắc sảo, đáng tin cậy. Nhưng hãy rõ ràng: Tài năng không biện minh cho sự thiếu gắn kết. Collaboration không phải là tùy chọn trong agile; nó chính là cốt lõi.

Một chiến lược mạnh là trao cho họ nhiều quyền chủ động hơn trong nhóm và quy trình. Nếu họ nghĩ standups lãng phí, hãy thách thức họ làm nó hiệu quả hơn. Nếu họ không thích retros, hãy tổ chức một mini-retrospective để cải thiện chính buổi retro. Biến sự chống đối thành đóng góp.

Ngoài ra, hãy cho họ cơ hội làm mentor. Ghép họ với thành viên junior, hoặc với người thuộc lĩnh vực khác. Giao cho họ một research spike, hoặc nhờ họ hỗ trợ teammate khác mà không trực tiếp làm thay. Điều này nhắc họ rằng họ là một phần của nhóm, và không ai có thể giỏi hơn tất cả mọi người cộng lại.

Đồng thời, đặt ra và duy trì ranh giới rõ ràng. Công khai expectation của nhóm: ai cũng phải tạo và update ticket của mình, ai cũng tham gia họp. Điều này giúp mọi người hiểu rằng nghi lễ phải được cải thiện, vì nó vẫn sẽ tiếp tục.

Agile chỉ hiệu quả khi sức mạnh của mọi người được kết nối qua hợp tác. Bạn không yêu cầu họ bớt tài giỏi; bạn yêu cầu họ phát huy tài năng trong bối cảnh nhóm.

Khi người xuất sắc hiểu rằng agile không phải kiểm soát, mà là về sự rõ ràng và cộng tác, họ sẽ ngừng chống đối và bắt đầu tham gia. Không phải vì bị ép buộc, mà vì họ nhìn thấy giá trị.

Kết luận

Agile phát triển nhờ mục đích chung. Ngay cả người hoài nghi nhất cũng có thể trở thành đồng minh mạnh mẽ khi họ cảm thấy được tôn trọng, lắng nghe, và là một phần của điều lớn hơn.

Những điểm rút ra:

1. Luôn giả định thiện chí. Chống đối xuất phát từ trải nghiệm, không phải cố chấp.
2. Tập trung vào outcomes, không phải ceremonies. Cho thấy agile bảo vệ thời gian, tập trung, và giảm burnout. Nếu ceremonies không hiệu quả, hãy thay đổi chúng.
3. Mời gọi đóng góp, không ép buộc. Để người giỏi định hình quy trình, thay vì bị quy trình ép buộc.
4. Đặt kỳ vọng nhóm rõ ràng. Tài năng không phải lý do cho việc không tham gia. Collaboration mới là điều cốt lõi.
5. Agile không phải để kìm hãm rockstars. Quy trình là để cả ban nhạc cùng chơi với nhau.

A A A A

[{"displaySettingInfo":"[{\"isFullLayout\":false,\"layoutWidthRatio\":\"\",\"showBlogMetadata\":true,\"showAds\":true,\"showQuickNoticeBar\":true,\"includeSuggestedAndRelatedBlogs\":true,\"enableLazyLoad\":true,\"quoteStyle\":\"1\",\"bigHeadingFontStyle\":\"1\",\"postPictureFrameStyle\":\"1\",\"isFaqLayout\":false,\"isIncludedCaption\":false,\"faqLayoutTheme\":\"1\",\"isSliderLayout\":false}]"},{"articleSourceInfo":"[{\"sourceName\":\"Bart Gerardi (projectmanagement.com)\",\"sourceValue\":\"https://www.projectmanagement.com/articles/1120502/agile-vs--ego--what-to-do-when-a-team-member-rebels\"}]"},{"privacyInfo":"[{\"isOutsideVietnam\":false}]"},{"tocInfo":"[{\"isEnabledTOC\":true,\"isAutoNumbering\":false,\"isShowKeyHeadingWithIcon\":false}]"},{"bannerInfo":"[{\"isBannerBrightnessAdjust\":false,\"bannerBrightnessLevel\":\"\",\"isRandomBannerDisplay\":true}]"},{"termSettingInfo":"[{\"showTermsOnPage\":false,\"displaySequentialTermNumber\":false}]"}]

Khám phá thêm các chủ đề sau