Làm gì khi team SCRUM của bạn không hoàn thành công việc trong Sprint vừa rồi

Một trong những vấn đề lớn với các team Agile mới là không có khả năng hoàn thành công việc trong Sprint. Mỗi team là duy nhất. Tuy nhiên, tôi đã nhìn thấy những nguyên nhân này thường xuyên nhất:

• Team members multitask, vì vậy họ không hoàn thành công việc của mình Sprint. Tôi đã gặp phải vấn đề này khi các thành viên trong team làm quá nhiều user story cùng một lúc và khi các nmanagers yêu cầu các thành viên trong team PHẢI làm việc cho nhiều dự án.
• Mọi người làm việc như các expert, cross cả architecture, dù họ không phải là một team architecture. Nguyên nhân này thường tạo ra WIP (Work in Progress). Khi mọi người làm việc trên toàn bộ kiến ​​trúc, họ thường tạo ra "UI user story", "Middleware user story", "user story" và "testing user story". Đó là tuyệt vời cho hiệu quả tài nguyên. Bạn có thể cho mọi người thấy mọi người đều được tận dụng. (Có, một chút mỉa mai ở đó.) Tuy nhiên, trong ngành phần mềm, đặc biệt là với cách tiếp cận Agile, là về flow hiệu quả, nơi mà mọi người làm việc như một đội team hoàn thành một user story cùng một lúc.
• User story quá lớn. Team không thể hoàn thành một user story, không quan tâm họ đã estimate như thế nào, bên trong một Sprint. Những user story quá lớn có nhiều nguyên nhân có thể xảy ra. Tôi đã gặp trường hợp này khi một PO không tìm kiếm giá trị đầu tiên có thể có trong tập hợp tính năng. Tôi cũng đã nhìn thấy điều này khi các team không biết trạng thái của code hoặc test và problem là quá phức tạp để hoàn thành trong vòng chưa đầy một vài tháng. Đôi khi, user story quá lớn vì code không có unit test để hỗ trợ thay đổi. Tức là khi requirement change, thì viết lại unit test là điều không thể, quá lớn, quá nhiều để cover.

Bạn có thể làm gì nếu team của bạn không hoàn thành công việc trong Sprint? Đây là ba lời khuyên:

• Làm việc theo nhóm. Tôi đang nói về việc pairing, swarming, và mobbing, và đó là bởi vì team tập trung vào việc move một user story sang DONE. Điều đó giải quyết được vấn đề quá nhiều vấn đề trong status IN PROGRESS. Và nếu người quản lý yêu cầu bạn làm việc về cái gì khác, bạn có thể nói không. Đó là bởi vì team của bạn phụ thuộc vào bạn để làm việc với họ.

• Đảm bảo rằng mọi người (đặc biệt là các leader and manager) hiểu về flow hiệu quả. Tôi thích theo dõi luồng tích luỹ để mọi người có thể xem bản kiểm kê những công việc chưa hoàn thành. (Xem hình dưới đây.)
• Đánh giá liệu user story này là một user story nhỏ hay là tập các chức năng. Bạn có thể muốn sử dụng Bản đồ Câu chuyện của Người dùng của Jeff Patton hoặc có thể Khám phá Khám phá của Ellen Gottesdiener. Xem loạt bài về Chủ sở hữu sản phẩm và Học tập để biết thêm chi tiết về cách bạn có thể cân nhắc việc lập kế hoạch và tổ chức các câu chuyện.

Đây là biểu đồ luồng tích lũy từ một dự án thực. Trong dự án này, PO đã cố gắng "đi trước" team. Ông đã thành công. Anh đã "hoàn thành" việc tạo ra những user story mà team phát triển không bao giờ đụng tới. Tôi gọi đó là lãng phí.

Còn team đã làm một công việc khá tốt trong việc phân tích các user story, nhưng có một chút rắc rối với các developer có WIP. Các developer đã có WIP bởi vì đôi khi các nhà quản lý của họ kéo họ vào các dự án khác. Lúc này team sẽ cảm thấy không còn interested về swarming hay mobbing, vì vậy các nhà quản lý cảm thấy như thể họ có thể kéo mọi người ra.

Team này về cơ bản là không hoàn hảo và họ không nhất thiết phải như thế. Họ hình dung rằng công việc của họ có thể bị phê bình, đánh giá, nên họ đã quyết định dừng việc multitasking lại. Và, khi team đến Sprint thứ 11, họ đã có ít WIP hơn.

Dưới đây là những điều team này đã cố gắng:

• Theo dõi tiến độ của user story thông qua team.
• Theo dõi luồng tích luỹ. Hình dung bất kỳ công việc "khác" mà bất kỳ thành viên trong team nào có trong khi mọi người được cho là làm việc về một user story cụ thể.
• Chọn user story nhỏ nhất bạn có. Làm việc trên nó như một team SCRUM thực thụ. Vâng, hãy làm việc trên cùng một user story tại một thời điểm.

Bạn có thể phải giải thích với các manager của bạn rằng bạn đang thử nghiệm để bạn có thể tăng velocity của cả team mình. Hãy nhớ rằng velocity là năng lực, và bạn đang học về velocity của bạn để bạn có thể estimate tốt hơn.

Nếu team của bạn không thể hoàn thành công việc trong Sprint hiện tại, đừng tự động mang theo phần công việc này cho Sprint tiếp theo. Hình dung công việc hiện tại đang ở đâu, chọn công việc được xếp priority cao nhất, và làm việc trên nó, từng user story một, theo nhóm (pair/whole team).

Tăng giới hạn WIP của bạn chỉ sau khi team kết thúc Sprint thành công. Vấn đề của bạn có thể không nằm trong các user story hoặc teamwork, nhưng có thể là ở một nơi nào đó trong hệ thống dự án của bạn.

Khi team không hoàn thành công việc của họ trong Sprint, đó là một vấn đề của hệ thống dự án. Đó là một dấu hiệu cho thấy hệ thống phải thay đổi. Sử dụng tất cả các công cụ định tính và định lượng của bạn (bao gồm cả retrospective) để chẩn đoán và thử nghiệm với nhóm của bạn.