10 sai lầm thường gặp khi áp dụng SCRUM và cách phòng tránh

Scrum thường là loại practice Agile dễ bị lạm dụng nhất, bởi vì nó có thể được xem như là một cách dễ dàng khi làm Agile architecture. Khi hầu hết mọi người nghĩ đến Agile, họ nghĩ đến "Scrum". Scrum là khái niệm đơn giản nhưng có thể rất khó thực hiện tốt. Dưới đây là 10 lỗi phổ biến khi áp dụng Scrum và cách tránh chúng:

Thông thường, mọi người mới bắt đầu với Agile hoặc Scrum sẽ làm như sau, bắt đầu thu thập các requirement, chia nhỏ chúng ra thành cái họ gọi là user story, bắt đầu daily meeting, phát triển phần mềm trong 2-3 tuần sprint, và sau đó tự gọi mình là Agile. Dễ dàng, đúng không? Họ có thể sẽ thấy một số cải thiện về khả năng phản hồi của họ đối với thay đổi và thậm chí có thể cung cấp phần mềm làm việc nhanh hơn - trong một thời gian. Tuy nhiên, nó sẽ không được lâu dài đâu, cho đến khi các value của Agile trở nên ít rõ ràng hơn, team sẽ phải gắng gượng để theo kịp tốc độ. Và chính lúc như thế này sẽ phơi bày sự thật rằng phần mềm của họ không phải luôn luôn phù hợp với mong đợi của người dùng, và tất nhiên ngay sau đấy Agile được coi là một thất bại. Sự chuyển đổi sang Agile đòi hỏi thời gian và hầu như luôn luôn bắt đầu rất lộn xộn. Sự chuyển đổi thực sự sẽ làm lộ các vấn đề công ty và văn hoá hiện tại cần phải được giải quyết - các vấn đề như giao tiếp kém, thiếu trách nhiệm giải trình, không tin tưởng ...Chuyển đổi Agile hiệu quả thường là sự thay đổi toàn bộ văn hoá. Hãy dành thời gian, và sẵn sàng vượt qua sự mất mát và những thay đổi văn hoá. Phải tiếp cận theo thái độ "thà một lần đầu", và tất nhiên đấy không phải là chuyện của "ngày một ngày hai".

Những điều dễ dàng như thực hiện các cuộc họp của Scrum, có đầy đủ các role trong Scrum, và sử dụng các artifacts của Scrum thích hợp là tốt, nhưng đó chỉ là một nửa (hoặc thậm chí là một phần) của Scrum. Các principle của Agile là để đảm bảo cho các practice của nó hoạt động tốt và làm cho chúng bền vững về lâu về dài. Các principle khó kết hợp hơn nhiều so với practice, đó là lý do tại sao nhiều công ty rơi vào tình trạng thất bại sớm - vì họ không làm những phần khó. Sử dụng các kỹ thuật mà không hiểu tại sao bạn đang làm chúng thì chỉ có thể dẫn đến thất vọng. Agile là về con người, tương tác, và văn hoá chứ không phải là các quá trình, practice và công cụ.

Làm mọi thứ bạn có thể để giữ cho Agile khởi động đơn giản. Các dự án Agile có thể thành công mà không có công cụ hợp tác hay vòng đời mới nhất, cool nhất. Sticky trên tường, task trong một bảng tính đơn giản, và một biểu đồ burn-down được tạo ra bằng tay, đơn giản như vậy là đủ để bạn hoàn thành công việc của mình. Dành thời gian quý báu cho một công cụ để điều hay, chia task thay vì khiến mọi người làm việc cùng nhau chính là bạn đang tập trung vào điều không đúng. Tuyên ngôn Agile là mang lại giá trị cao hơn cho các cá nhân và tương tác hơn là về quy trình và công cụ. Thoả mái khi bắt đầu với Agile/Scrum, đừng gò bó quá, quan trọng là cuối cùng bạn hoàn thành xuất sắc công việc của mình với Agile mindset.

Tư duy "chỉ huy và kiểm soát" bị phản đối kịch liệt trong khuôn khổ Agile. Một leader phân task và nỗ lực sai khiến người khác là một mô hình lỗi thời và đi ngược lại với quan điểm của Agile. Một team Agile tuyệt vời chính là một team tự tổ chức, Scrum Master là một leader kiểu đầy tớ (servant leader), và team học cách làm việc tốt hơn và mang lại giá trị lớn hơn hiệu quả hơn thông qua việc kiểm tra và thích ứng thường xuyên. Thông thường thì việc phát triển bản thân dựa vào kinh nghiệm (kinh nghiệm tốt hoặc xấu) thì vẫn hơn là chỉ được chỉ bảo phải làm gì bởi một ai đó. Cho phép team Scrum tự tìm ra vấn đề và tự giải quyết cho chính mình, tự mắc sai lầm và học hỏi từ sai lầm đó, và để đạt được sự hài lòng khi trở thành một team có productivity cao theo đúng cách của họ. Mindset ở đây là hãy để team xây dựng và phát triển theo tự bản thân của team, chứ không phải là bị chỉ huy kiểm soát.

Một product backlog chưa sẵn sàng chính là một trong những lý do phổ biến cho sự thất bại của sprint và của team không có motivation. Đây cũng là nguyên nhân chính của việc delivery chậm và không có value cao. Hầu hết những Product Owner (PO) mới đều không sẵn sàng cho việc tự mình tăng productivity. Họ cần hướng dẫn, huấn luyện và nắm bắt cho những lần chạy Sprint đầu tiên khi họ học cách phát triển và maintain số lượng tồn đọng sản phẩm có đủ các tính năng có value ước tính ở mức cao và được ưu tiên bởi bussiness value. Chuẩn bị backlog tốt trước khi Sprint tiếp theo bắt đầu là điều bắt buộc. Bạn không bao giờ muốn team mình lại hết công việc để làm, và công việc đó phải có giá trị cao nhất vào thời điểm đó theo sự ưu tiên của PO. Là PO có thể tốn nhiều thời gian. Đặt đúng kỳ vọng, cung cấp tất cả các khóa đào tạo và giúp PO giữ cho flow của của product chạy đúng, thì các value tiếp theo sẽ dần đi vào ổn định. Quan trọng hơn cả khi là PO của một project Agile, là bạn phải sẵn sàng và improve bản thân sớm để có thể adapt cho project, nhằm mang lại value sớm nhất có thể cho sản phẩm.

Một điều tôi thấy khá thường xuyên trên các team Scrum mới là người ta sử dụng Scrum Master (SM) để gửi thông điệp của họ cho người khác. Ví dụ: dev có câu hỏi về một user story nào đó; thay vì trực tiếp đến PO để hỏi, anh / cô ấy sẽ gửi email cho SM để lấy thông tin. Sai rồi, rõ ràng là team này đang làm sai Agile, một nguyên tắc chính Agile là giao tiếp trực tiếp bất cứ khi nào có thể. Thay vì dành thời gian để soạn email, hãy dùng nó để hỏi trực tiếp PO, như vậy thực sự tốt hơn rất nhiều phải không nào. Về mặt principle là vậy, tuy nhiên có một điều không thể không công nhận là việc thực hiện face-to-face giao tiếp đối với những người làm kỹ thuật như developer (có thể là cả tester) là điều không hề dễ dàng gì. Đây là vấn đề về văn hoá và tính cách cần phải vượt qua. Nó làm lãng phí thời gian và, quan trọng hơn, làm tăng nguy cơ misscommunication, mà điều này thì hậu quả của nó ai cũng rõ.

Như đã nói ở trên, để là một PO có thể sẽ phải tốn rất nhiều thời gian. Nhiều người mới làm vai trò này thường chưa sẵn sàng cam kết, hoặc chỉ là không biết rằng họ cần phải tham gia như vậy. Hợp tác là điều rất quan trọng trong thế giới Agile. Người kinh doanh và nhà phát triển phần mềm cần làm việc cùng nhau để sản xuất ra phần mềm mà doanh nghiệp muốn. Điều này xảy ra thông qua liên lạc thường xuyên, hợp tác và chu kỳ nhận feedback ngắn để xác nhận hoặc thực hiện sửa đổi cần thiết. Một practice mà tôi rất thích thấy, và tất nhiên cũng đã từng trải nghiệm là PO liên quan đến hoạt động hàng ngày của team development, và Sprint Review hoàn toàn là hình thức thôi vì thực tế PO đã nhìn thấy qua các Sprint làm việc cùng team và đã hướng dẫn team để xây dựng chính xác những gì doanh nghiệp muốn. Đó là một điều tuyệt vời.

Về một vài khía cạnh thì daily stand-up meeting là rất quan trọng. Nó put mọi người phải face-to-face mỗi ngày trong 15 phút, communicate và hợp tác, cung cấp sự rõ ràng và minh bạch cho dự án. Đối với một cuộc họp quan trọng như vậy, điều quan trọng là phải cho các team member thấy được sự quan của cuộc họp để team thực hiện nó nghiêm túc. Điều này có vẻ là ép buộc, nhưng đúng vậy, việc tham gia vào daily stand-up không phải là tuỳ chọn. Bắt đầu đúng giờ và kết thúc đúng giờ. Thực tế, tôi cũng đã từng gặp một team như thế này, thực ra lúc bắt đầu như team đang làm rất tốt, mọi người setup meeting vào sáng sớm, đúng giờ, mọi thứ hoàn hảo. Tuy nhiên thực ra việc này không duy trì được lâu, vì làm một cách không chặt chẽ, nên sau một thời gian, team không còn đúng giờ nữa; rồi không còn đủ team member tham gia; và tất nhiên cuối cùng là bỏ daily stand-up vì nó không còn hiệu quả nữa. Trong daily stand-up meeting thì, không cho phép đối thoại bên lề, thảo luận, hoặc giải quyết vấn đề trong khi đứng; Tất cả những gì có thể được thực hiện sau khi stand-up kết thúc. Đây cũng là nguyên nhân chính mà team tôi có nói ở trên thực hiện daily stand-up fail. Vì thực thế khi đem đối thoại bên lề hay thảo luận vào meeting này thì cuộc meeting sẽ bị xao lãng, value của cuộc họp dần bị ít đi, và không đúng như ban đầu. Một trong những value rõ ràng của việc daily stand-up ngắn gọn chính là làm cho team theo phương thức tôn trọng mọi người trong team và thời gian của người khác, và họ học cách giao tiếp tốt hơn bằng cách gắn bó với các mục tiêu và được ngắn gọn.

Như đã biết thì daily stand-up meeting cung cấp cơ hội mỗi ngày để truyền đạt những problem để thực hiện công việc của chúng ta. Một trong những việc chính của Scrum Master là loại bỏ những problem để nhóm có thể tập trung vào việc phát triển phần mềm; nhưng rõ ràng nếu những problem không được raiser lên, thì Scrum Master không thể giúp loại bỏ chúng. Problem cần được raise càng sớm càng tốt, vì nếu để lâu thì quá muộn để có thể giải quyết cũng như hậu quả lớn. Cho đến khi các thành viên trong team quen với việc raises problem một cách kịp thời, hãy nhắc nhở team vào đầu mỗi lần daily stand-up để đưa ra những trở ngại tiềm ẩn, hay bất kỳ việc gì đó có thể trì hoãn công việc của team, ảnh hưởng đến Sprint commitment.

Một trong mười hai nguyên tắc đằng sau Tuyên ngôn Agile là "Đều đặnt, team sẽ phải phản ánh về làm thế nào để trở nên hiệu quả hơn, sau đó điều chỉnh hành vi cho phù hợp". Thật không may Sprint Retrospective thường được đối xử như một phần phụ trong Scrum, và chỉ thực hiện "nếu có thời gian". Về ý tưởng, Agile rất đề cao việc điều chỉnh và đáp ứng thay đổi. Thật khó để điều chỉnh và thay đổi nếu chúng ta không dừng lại để tìm ra thay đổi hay điều chỉnh ở đâu là cần thiết? Tóm lược, Agile không phải là một status, nó là cải tiến liên tục.