Hiện nay, các quy trình Agile đã được chấp nhận là những giải pháp thay thế hiệu quả cho các quy trình phát triển phần mềm truyền thống. Hầu hết những người áp dụng Agile đã thấy được những ích lợi của việc chuyển giao nhanh hơn, chất lượng cao hơn, sản phẩm đáp ứng tốt hơn nhu cầu người dùng, v.v.
Không phải tất cả mọi người đều yêu thích Agile. Nhiều người vẫn ái ngại với việc áp dụng Agile dù đó là quyết định từ các sếp hay quyết định tự phát của những người trẻ xông xáo muốn đổi mới. Việc chuyển sang Agile thường xung đột với các mục đích cá nhân như giữ nguyên hiện trạng, không muốn rủi ro nghề nghiệp, không muốn làm việc quá mức cần thiết, hoặc duy trì quyền lực dưới hình thức báo cáo trực tiếp.
Bài viết này gồm những lời khuyên dành cho những người như vậy, những người phải trở nên Agile nhưng không muốn. Đừng lo. Chúng tôi sẽ không cố gắng dụ dỗ bạn dùng thử Agile, thuyết phục bạn về những lợi ích của Agile hay nói cho bạn cách để thành công. Không, chúng tôi sẽ giúp bạn đảm bảo Agile bị thất bại. Sau đó bạn có thể trở lại với vùng an toàn của mình.
Dù có nhiều cách để phá hoại một dự án Agile, để thuận tiện chúng ta sẽ nhóm chúng lại thành bốn danh mục: các vấn đề về quản lý, vấn đề về nhóm, vấn đề về Product Owner và các vấn đề về quy trình. Trong mỗi danh mục, chúng tôi sẽ đưa ra một ví dụ về người đã làm cho Agile thất bại, đưa ra danh sách các hướng dẫn chung cho thất bại mà ví dụ đã thể hiện ra, và danh sách những kĩ thuật thay thế khác bạn có thể thử để tái tạo lại thất bại đó. Chúng tôi hi vọng cách này sẽ giúp bạn thất bại nhanh hơn và tránh được những thành công tiềm ẩn.
Drew đã thấy các trào lưu quản lý đến và đi. Trong suy nghĩ của Drew, Agile cũng vậy. Là một người học nhanh, anh đã đọc vài cuốn sách và thậm chí còn học một lớp về Agile. Anh không tin Agile, nhưng là người có tinh thần đồng đội, anh có nghĩa vụ phải thử Agile một lần.
Drew chọn các thành viên cho nhóm và yêu cầu họ “hãy Agile”. Drew yêu cầu nhóm cần họp hàng ngày, ước lượng công việc, và mỗi tháng làm ra được một phiên bản của sản phẩm (một công cụ cơ sở dữ liệu để lưu trữ tác phẩm nghệ thuật).
Bởi vì Drew không tin Agile và khả năng của nhóm, anh ta tham gia tất cả các phiên Scrum Hằng ngày, hết sức để ý và chỉ ra điều gì nhóm làm đúng, điều gì làm sai. Cuộc họp hàng ngày nhanh chóng trở thành một phiên bản mẫu mực để sửa lỗi về cách làm và ngôn từ. Do đó, không ai nói về các vấn đề – đặc biệt là trước mặt Drew. Drew đã thành công làm theo hướng dẫn đầu tiên để làm Agile thất bại của chúng tôi.
Hướng dẫn 1: Đừng tin vào nhóm hay Agile. Hãy quản lý vi mô tất cả thành viên nhóm và quy trình.
Không ngoài dự đoán của mọi người, nhóm không tạo ra được những kết quả ấn tượng. Nhóm không đạt được các mục tiêu phân đoạn và không năng suất hơn trước kia. Drew tổ chức các buổi Cải tiến mà không tìm thấy vấn đề nào anh ta có thể sửa được. Kết quả là Drew quẳng hết sách mà anh ta đã đọc về Agile đi và bảo nhóm quay lại cách cũ để phát triển dự án. Drew đang làm theo hướng dẫn số 2.
Hướng dẫn 2: Nếu Agile không phải là viên đạn bạc, hãy đổ lỗi cho Agile.
Trong khi Drew quản lý vi mô nhóm một cách cực đoan, có một cách cực đoan ngược lại là không hướng dẫn nhóm một chút nào. Nhớ rằng: dù nhóm Agile tự tổ chức đồng thời cũng tự quản lý, họ không tự lãnh đạo. Một nhóm Agile cần kiểu lãnh đạo đưa ra được tầm nhìn và động lực để đạt được tầm nhìn đó. Một lãnh đạo Agile giỏi, thường là một Product Owner, sẽ biết cách tạo động lực cho nhóm bằng cách miêu tả về một sản phẩm cực kỳ đáng mơ ước vượt qua tưởng tượng của nhóm. Khi nhóm tự mình theo đuổi mục tiêu đó đồng thời liên tục được Product Owner định hướng, nhóm Agile có thể đạt được năng suất siêu cao. Đừng để nhóm có được cơ hội đó! Nếu quản lý vi mô không phải kiểu của bạn, hãy làm theo hướng dẫn số 3.
Hướng dẫn 3: Đánh đồng tự quản lý với tự lãnh đạo và không chỉ dẫn nhóm bất kỳ điều gì.
Dù được các cấp cao nhất trong công ty ủng hộ, việc áp dụng Agile thường sẽ được nhóm Agile tự mình triển khai. Đừng lo. Bạn vẫn có nhiều cơ hội để làm cho Agile thất bại, đặc biệt nếu bạn là quản lý. Bạn có thể bắt đầu bằng cách ngầm phá hoại người tiên phong trong nhóm – người đã đọc tất cả các cuốn sách về Agile và đang tận dụng các cơ hội để quảng bá cho Agile. Bỏ qua tất cả các quy tắc mà anh ta yêu cầu bạn tuân theo. Gián đoạn Scrum Hằng ngày với những chỉ thị mới. Thay đổi thứ tự ưu tiên của các mục tiêu trong phân đoạn. Những việc này được thực hiện khi làm theo hướng dẫn số 4.
Hướng dẫn 4: Phớt lờ các quy tắc của Agile.
Chúng không áp dụng cho việc quản lý. Nếu bạn muốn đảm bảo Agile không bén rễ trong công ty, hãy nói thẳng với các thành viên nhóm Agile rằng bạn nghĩ Agile chỉ là một trào lưu. Vài người từ đầu đã hoài nghi rồi, vì vậy không tốn nhiều công sức để thuyết phục họ phớt lờ các kĩ thuật Agile. Nhớ rằng, giống như Barney Fife, bạn có quyền lực để diệt Agile từ trong trứng nước. Chỉ cần làm theo hướng dẫn số 5.
Hướng dẫn 5: Ngầm phá hoại niềm tin của nhóm về Agile.
Không phải tất cả chúng ta đều là quản lý. Đừng lo, dù không phải quản lý chúng ta vẫn có thể tạo ảnh hưởng phá hoại cả nhóm. Hãy xem trường hợp của nhóm Agile NotQuite, được giao phát triển phần mềm quản lý kho hàng. Nhóm cho thấy sức mạnh của tính kiên định trong việc làm đổ bể một dự án phần mềm. Trong phân đoạn đầu tiên, NotQuite cam kết hoàn thành 6 hạng mục trong Product backlog; nhóm đã hoàn thành 4. Vì trong phân đoạn đầu tiên, hầu hết mọi người đều cam kết quá nhiều, nên Product Owner không chỉ trích nhóm nhiều lắm. Điều này không làm nhóm NotQuite lo lắng.
Đến phân đoạn thứ hai, nhóm vẫn lên kế hoạch hoàn thành 6 hạng mục; nhóm đã hoàn thành được 5. Sự cải tiến nhẹ này ru ngủ Product Owner vào cảm giác an toàn giả tạo. NotQuite tiếp tục cam kết quá sức, chậm tiến độ trong các phân đoạn thứ 3, 4, 5. Product Owner sớm thấy rằng không thể tin được nhóm, điều này ngầm phá hủy bất kì khả năng thành công nào của Agile. Đây quả là một trường hợp tuyệt vời làm theo hướng dẫn số 6 .
Hướng dẫn 6: Liên tục không chuyển giao được điều bạn đã cam kết khi lập kế hoạch cho phân đoạn.
Khi chậm tiến độ, đừng mắc sai lầm làm hết sức mình trong mọi phân đoạn, lần nào cũng kiệt sức khi đến ngày cuối cùng. Một nhóm như vậy hầu như luôn được tha thứ dù không bao giờ chuyển giao được đúng kế hoạch. Lý do chính trong sai lầm của NotQuite là thái độ ung dung với những cam kết không đạt được. Thành viên nhóm tỏ rõ rằng việc hoàn thành công việc đúng ngày cam kết hay chậm vài ngày là việc bình thường. Bạn bè với nhau thì vài ngày có là gì? Nhớ rằng, vài ngày nhiều lần gộp lại sẽ thành khá nhiều. Nếu một nhóm Agile liên tục không thực hiện được cam kết, Product Owner không thể lập kế hoạch và không thể cam kết gì với bên ngoài. Điều này dẫn tới hướng dẫn số 7 để làm Agile thất bại.
Có lẽ cách tốt nhất làm cho một dự án Agile thất bại là làm theo hướng dẫn số 8.
Hướng dẫn 8: Đừng lập nhóm liên chức năng. Hãy để tất cả kiểm thử viên vào một nhóm, tất cả lập trình viên vào một nhóm khác.
Merrilynn có thể dùng hướng dẫn này để hủy diệt dự án thử nghiệm Agile của công ty cô. Đó là dự án phát triển một chương trình có hai ứng dụng máy khách(client) tách riêng cho Windows và Web. Là giám đốc phát triển, Merrilynn có quyền chia nhóm và đã tạo ra ba nhóm riêng biệt: một nhóm Windows, một nhóm Web, và một nhóm kiểm thử. Cấu trúc nhóm này trái ngược với các mục tiêu của Agile. Nếu Merrilynn muốn thành công, cô lẽ ra phải tạo ba nhóm mà mỗi nhóm đều có người với đủ các kĩ năng Windows, Web và kiểm thử. Bởi vì Merrilynn tách riêng các nhóm, cô khiến cho mỗi nhóm không thể chuyển giao được phần mềm hoàn chỉnh mà một nhóm Agile có thể chuyển giao mỗi cuối phân đoạn. Giỏi đấy, Merrilynn.
Một lựa chọn khác cho Merrilynn là đặt toàn bộ 20 người vào một nhóm. Điều này sẽ trái với lời khuyên chuẩn của Agile là một nhóm chỉ có từ 5 đến 9 người. Cô có thể giải thích với người thắc mắc về quyết định này bằng cách nhấn mạnh vào tính duy nhất của 2 ứng dụng máy khách trong sản phẩm của nhóm mình. Nếu cô chọn cách tạo một nhóm lớn thay vì 3 nhóm cỡ hợp lý, Merrilynn sẽ khiến tốn quá nhiều thời gian dành cho giao tiếp trong nhóm. Làm cho tiến độ bị chậm lại và khiến mọi người phàn nàn rằng việc giao tiếp trong Agile là một gánh nặng khổng lồ. Nếu phân tách nhóm quá khó để giải thích, bạn có thể cản trở một dự án rất dễ dàng bằng hướng dẫn số 9.
HƯỚNG DẪN 9: Dự án lớn cần nhóm lớn. Mặc kệ những nghiên cứu nói rằng năng suất trong nhóm lớn bị giảm do thời gian cho giao tiếp tăng lên. Bởi vì mọi người cần biết về mọi thứ, hãy mời tất cả 50 người tham gia phiên họp đứng hàng ngày.
Như bạn có thể thấy, Product Owner có thể dễ dàng làm cho Agile thất bại bằng cách giao tiếp sai lệch, không quan tâm đến tiến độ nhóm, và thiếu đào tạo.
Nếu bạn không thể làm theo những hướng dẫn về nhóm và quản lý, bạn có thể làm theo hướng dẫn cho Product Owner. Một Product Owner có rất nhiều lựa chọn trong thẩm quyền của mình để đẩy một dự án Agile đến bờ vực.
Hãy xem ví dụ về Kathy, Product Owner của một nhóm làm về video game. Nhóm đang đạt được tiến độ tuyệt vời qua mỗi phân đoạn(Sprint) và mỗi lần đều có thêm những niềm vui cho người chơi. Kathy để thành viên nhóm nghĩ rằng đó là tất cả những gì họ cần làm. Cô không bao giờ tham gia các buổi Sơ kết, hiếm khi dùng thử trò chơi, và đặt ra những story đẩy trò chơi đi theo hướng mà cô tưởng tượng. Nếu như vậy vẫn chưa đủ, Kathy không chia sẻ tầm nhìn của mình với nhóm hoặc với những khách hàng mà cô có trách nhiệm báo cáo (ví dụ bên marketing).
Sau một năm phát triển, trò chơi được trình diễn cho một nhóm điều hành rồi làm họ choáng váng về hướng phát triển của trò chơi. Đó không phải điều họ muốn đưa ra thị trường. Liên kết rời rạc giữa Kathy, nhóm và quản lý cấp cao làm cho dự án chậm tiến độ 6 tháng. Làm tốt lắm, Kathy!
Kathy đã minh họa cho vài hướng dẫn làm thất bại dự án Agile trong tay một Product Owner.
Hướng dẫn 10: Đừng giao tiếp tầm nhìn về sản phẩm cho nhóm Agile hay các bên liên quan khác.
Hướng dẫn 11: Đừng quan tâm đến tiến độ mỗi phân đoạn và đánh giá khách quan tiến độ chung.
Hướng dẫn 12: Thay thế tài liệu kế hoạch bằng một kế hoạch “trong đầu bạn” mà chỉ mình bạn biết.
Một trong những nguyên lý cơ bản của phát triển theo phân đoạn lặp là thấy được các chức năng đóng góp giá trị gì trong toàn bộ hệ thống. Đây là lý do mỗi phân đoạn đều tạo ra một phiên bản có thể phát hành của sản phẩm. Điều này tương phản hoàn toàn với các dự án phát triển theo kế hoạch cố định, trong đó các nguồn lực được tính toán để tạo ra được sản phẩm khi kết thúc kế hoạch. Khi một Product Owner không thay đổi cách làm đó, nhóm Agile sẽ nhanh chóng thất bại. Việc đào tạo Product Owner cũng quan trọng như đào tạo nhóm. Nói chung, nếu bạn muốn đảm bảo Agile thất bại nhanh chóng, hãy tránh xa hoàn toàn khỏi đào tạo.
Vai ác của Product Owner thường được cân bằng bởi ScrumMaster hoặc huấn luyện viên của nhóm. Trong những dự án thành công, luôn có một sự căng thẳng nhất định giữa Product Owner và ScrumMaster. Một Product Owner luôn muốn thêm nhiều chức năng hơn nữa. Ngược lại, huấn luyện viên có trách nhiệm theo dõi sức khỏe của nhóm. Nếu nhóm bị ép quá mức và bắt đầu uể oải vì mệt, huấn luyện viên sẽ đẩy lui mong muốn nhiều hơn nữa của Product Owner. Một cách tốt để làm Agile thất bại là loại bỏ sức ép kéo-đẩy giữa huấn luyện viên và Product Owner theo hướng dẫn số 13 dưới đây.
Hướng dẫn 13: Để một người làm vai trò của cả ScrumMaster (Agile coach) và Product Owner. Thực tế, người này cũng làm một thành viên trong nhóm phát triển.
Như bạn thấy, Product Owner rất dễ làm cho Agile thất bại bằng cách giao tiếp lỗi, không để ý đến tiến độ nhóm, và chưa được đào tạo. Nếu cần bạn có thể gộp những điều trên lại bằng cách để một người đồng thời làm những vai trò vốn được thiết kế để cân bằng lẫn nhau. Làm chính xác theo những hướng dẫn trên là cách tuyệt vời để thất bại.
Thay vì điều chỉnh linh hoạt lương, thưởng, chức vụ, thăng tiến theo Agile, hãy thưởng cho từng cá nhân để ngầm phá hoại tinh thần làm việc nhóm và chịu trách nhiệm chung.
Nếu các cách trên không thành công, xử lý sai các vấn đề về qui trình có thể làm thất bại hầu hết các dự án Agile. Jon là một ví dụ kinh hoàng về cơn ác mộng qui trình, và anh ta tạo ra những sự phá hoại lớn nhất mà không biết mình chính là nguyên nhân. Jon là trưởng nhóm lập trình của một nhóm ở Chicago đang phát triển phần mềm để chấp nhận hay từ chối các khoản vay. Ngoài việc làm trưởng nhóm, anh ta còn làm ScrumMaster (hãy xem lại hướng dẫn 13, riêng điều này cũng có thể gây ra thảm họa).
Nhóm Jon mới áp dụng Agile và nôn nóng muốn bỏ bớt những phần không cần thiết. Nhóm ngay lập tức hủy bỏ họp đứng hàng ngày, lấy lý do rằng nhóm ngồi cùng một khu vực, mọi người có thể nghe được hầu hết các cuộc nói chuyện qua vách ngăn 1,8m.
Họ cũng quyết định rằng các kiểm thử đơn vị tự động là không cần thiết. Bởi vì họ làm một chương trình mới, không có code cũ để mà làm hỏng, và do mọi người đều để ý code mới nên cũng ít khả năng làm hỏng code mới. Tuy nhiên, Jon và đồng nghiệp vẫn áp dụng tái cấu trúc và sở hữu tập thể mã nguồn.
Họ đặt qui tắc là ai cũng có thể thay đổi code của người khác bất kì lúc nào. Họ sớm nhận ra việc tái cấu trúc và sở hữu tập thể mã nguồn có thể rất nguy hiểm nếu không có lưới an toàn của các kiểm thử đơn vị tự động để đảm bảo bạn không làm hỏng điều gì trong khi cải tiến mã. Jon và nhóm đã vô tình làm theo hai hướng dẫn làm cho Agile thất bại dưới đây.
Hướng dẫn 14: Tùy chỉnh một qui trình Agile trước khi hoàn toàn tuân thủ qui trình đó.
Hướng dẫn 15: Bỏ qua và tùy chỉnh những kĩ thuật Agile quan trọng trước khi hoàn toàn hiểu rõ chúng.
Một cách thay thế cho những hướng dẫn trên là áp dụng các kĩ thuật mà không hiểu tại sao phải làm vậy. Là huấn luyện viên, chúng tôi đã gặp nhiều nhóm học/làm một kĩ thuật do người khác yêu cầu và những người tiếp tục làm kĩ thuật đó dù họ đã không cần nó nữa. Điều này làm ta nhớ đến câu chuyện nàng dâu mới phải cắt hai đầu tất cả các miếng thịt trước khi cho vào chảo mà không biết tại sao phải làm vậy.
Khi người chồng hỏi tại sao cô tỉa miếng thịt như vậy, cô không có câu trả lời; cô làm vậy vì đó là cách mẹ cô làm. Tò mò về thói quen của mẹ mình, cô vợ gọi điện và hỏi tại sao bà lại dạy cô cắt phần đuôi miếng thịt như vậy. Mẹ cô bảo rằng do bà cô dạy như vậy. Cô vợ trẻ lại gọi bà và hỏi tại sao bà lại cắt phần đuôi của mọi miếng thịt. Bà nói với cô: “Bởi vì chảo rán thịt của bà quá nhỏ. Miếng thịt không vừa”. Câu chuyện này tương tự với hướng dẫn tiếp theo làm Agile thất bại.
Hướng dẫn 16: Mù quáng làm theo các kĩ thuật Agile mà không hiểu rõ các nguyên lý phía dưới.
Nếu bạn không thể thực hiện hướng dẫn từ 14 đến 16 và dự án Agile của bạn đang thành công dù bạn rất cố gắng, bạn có thể làm ngừng một dự án thành công bằng cách không thay đổi gì cả. Gì cơ? Không thay đổi gì cả? Theo dõi ví dụ của nhóm StatusQ. StatusQ có nhiệm vụ phát triển mới một hệ thống đặt chỗ trên nền tảng web, đã có một khởi đầu tốt đẹp. Các thành viên nhóm đều mới làm quen với Agile nhưng đã nghiên cứu kĩ và thậm chí còn gửi vài người đi học để trở thành ScrumMaster có chứng chỉ.
Dự án rất nhanh đạt được lợi ích từ phương pháp mới. Trong một tháng, StatusQ đã chạy được một trang web đơn giản và trình diễn vài giao diện chính khiến cho khách hàng tự tin rằng sẽ có được hệ thống đặt chỗ mạnh mẽ và tiện dụng trong tương lai.
StatusQ không bao giờ tổ chức một buổi Cải tiến khi kết thúc Sprint. ScrumMaster không ép mọi người thực hiện Cải tiến vì anh ta không thấy cần phải làm. Mọi thứ vẫn đang diễn ra rất tốt đẹp. Bạn có thể khuyến khích việc này bằng cách lớn tiếng phàn nàn ScrumMaster và các thành viên nhóm nếu họ cố tổ chức một buổi Cải tiến. Bảo họ rằng việc ngồi cùng nhau để bàn về một dự án đang chạy tốt là một việc lãng phí thời gian. Bảo họ rằng buổi Cải tiến chỉ cần thiết nếu có vấn đề không ổn xảy ra.
Dần dần, công việc của StatusQ bắt đầu chậm lại. Tốc độ phát triển và lượng mã lớn dần tạo ra các vấn đề về bảo trì. Mã nguồn không theo kịp các yêu cầu thay đổi từ khách hàng. Mã trở nên kém ổn định đến nỗi dự án dường như đi lùi. Cuối cùng ban quản lý của công ty quyết định dừng phát triển dự án và kết thúc hợp đồng với nửa giá.
Nhóm StatusQ đã vô tình minh họa cho hai hướng dẫn tiếp theo làm Agile thất bại.
Hướng dẫn 17: Đừng cải tiến liên tục.
Hướng dẫn 18: Đừng thay đổi các kĩ thuật thực hành.
Các vấn đề về qui trình của công ty dường như không liên quan gì đến dự án lại có thể tạo ra ảnh hưởng xấu đến tinh thần và động lực. Hãy xem xét trường hợp của Dave, một nghệ sĩ tháo vát làm việc cho một công ty phát triển game di động. Anh rất hào hứng khi công ty áp dụng Agile bởi vì anh rất thích Agile. Nhóm Agile mới gồm các lập trình viên, nghệ sĩ, nhà thiết kế và cơ số người với các chuyên ngành khác. Mọi người dựa vào nhau làm việc để hoàn thành các phân đoạn khi phát triển game. Nếu người nghệ sĩ làm tốt thì cả nhóm đều tốt. Dave thường dừng việc mình đang làm để giúp đồng đội hoàn thiện phần nghệ thuật của game. Tuy khiến cho việc của mình bị ảnh hưởng, nhưng với Dave, mục tiêu nhóm là ưu tiên hàng đầu.
Nhóm của Dave đã hoàn thành xuất sắc công việc và làm ra một tựa game đình đám bán được hàng nghìn bản giúp công ty kiếm được lợi nhuận lớn.
Đến cuối năm, Dave tham gia buổi đánh giá năng lực với trưởng ban nghệ thuật của công ty. Dave choáng váng khi biết rằng tiền thưởng cuối năm của mình rất ít. Dave được thông báo nghệ sĩ cấp cao đánh giá Dave không đạt được các mục tiêu sản phẩm nghệ thuật của mình. Hóa ra, người nghệ sĩ cấp cao đếm số thẻ tác vụ mà Dave hoàn thành mỗi phân đoạn để đánh giá năng lực thay vì lượng công việc thực tế mà Dave hoàn thành.
Thất vọng, Dave trở lại nhóm và thề rằng sẽ đảm bảo công việc của mình được ưu tiên hơn nhu cầu của nhóm. Bạn có thể dùng hướng dẫn 19 dưới đây làm kế hoạch dự phòng để đối phó với những người nhiệt huyết với Agile trong công ty mình.
Hướng dẫn 19: Thay vì điều chỉnh linh hoạt lương, thưởng, chức vụ, thăng tiến theo Agile, chỉ thưởng cho từng cá nhân để ngầm phá hoại tinh thần làm việc nhóm và chịu trách nhiệm chung.
Một nguyên lý cơ bản được chia sẻ bởi tất cả các qui trình Agile đó là công việc được ưu tiên dựa trên giá trị của mỗi chức năng. Những yếu tố khác như rủi ro và kiến tạo tri thức cũng được xem xét, nhưng lượng giá trị chuyển giao vẫn là yếu tố quyết định. Một cách chắc chắn để đảm bảo Agile thất bại là phớt lờ nguyên lý này và làm theo hướng dẫn số 20.
Hướng dẫn 20: Thuyết phục bản thân rằng bạn có thể làm được tất cả các công việc được yêu cầu, vì vậy thứ tự công việc không quan trọng.
Tất nhiên có những cách khác để thất bại ngoài 20 cách trên. Khi bạn cố gắng ngầm phá hoại một dự án Agile, có lẽ bạn đã khám phá ra vài cách của riêng mình. Tất nhiên bạn sẽ giữ riêng cho mình bởi vì âm mưu phá hoại không thể bị tiết lộ trước khi hoàn thành. Chúng tôi tự tin rằng nếu chịu khó áp dụng những hướng dẫn này kết hợp với những điều bạn đã biết, bạn có thể từ từ làm dự án Agile sắp tới sụp đổ và đảm bảo Agile thất bại.
Nguồn: Mountain Goat Software
Người dịch: Nguyễn Trung Tuyến
