Scrum không phải là lý do để bỏ qua những tình huống khẩn cấp

Trong Scrum, Product Owner chịu trách nhiệm tối đa hóa giá trị sản phẩm cho khách hàng. Đó là trọng tâm của toàn bộ Scrum framework, nơi giá trị được chuyển giao thường xuyên và tăng dần theo từng Sprint.

Tuy nhiên, đôi khi khách hàng sẽ có những yêu cầu công việc không cần thiết hoặc khi có một trường hợp khẩn cấp chen ngang vào giữa Sprint. Như vậy, chắc chắn mục tiêu chung của Sprint sẽ ảnh hưởng và giá trị mà cả nhóm đang cố gắng để chuyển giao sẽ có thể bị ảnh hưởng, thậm chí có thể Sprint sẽ bị huỷ bỏ bởi những điều đó từ khách hàng.

Vậy, Product Owner và Scrum Team phải làm thế nào để xử lý các yêu cầu bất ngờ đó từ phía khách hàng?

Chuyển giao giá trị trong các Sprint

Đầu tiên, hãy nhanh chóng đánh giá lại cách chúng ta chuyển giao giá trị như một Scrum Team. Việc đánh giá lại cách chuyển giao giá trị trong Scrum có thể giúp Scrum Team thấy được mục tiêu và cách thức để đạt được mục tiêu đó.

Trong Scrum, các lập trình viên làm việc cùng nhau để cung cấp giá trị trong các Sprint chính là cách mà Scrum Team hoạt động. Scrum Team tập trung vào cung cấp giá trị sản phẩm và mỗi Sprint có mục tiêu cung cấp một phần giá trị được hoàn thiện. Sprint thì thường sẽ kéo dài từ 1 đến 4 tuần, thời gian của môi Sprint là cố định và kế hoạch cho các công việc trong Sprint được định nghĩa trong sự kiện Sprint Planning.

Trong sự kiện Sprint Planning, Scrum Team chọn các mục trong Product Backlog để hoàn thành, tạo kế hoạch để thực hiện công việc và thiết lập một mục tiêu mô tả giá trị họ sẽ cung cấp trong Sprint đó. Các lập trình viên hằng ngày gặp nhau để theo dõi tiến độ, điều chỉnh kế hoạch và đảm bảo rằng mục tiêu được đạt được. Cuối cùng, Scrum Team xem xét kết quả và đánh giá để cải thiện trong Sprint tiếp theo. Nhịp đập của Sprint là trái tim của Scrum và đảm bảo sự nhất quán và đồng bộ trong hoạt động của Scrum Team.

Nhưng nếu khách hàng có tình huống khẩn cấp hoặc yêu cầu gấp đột xuất giữa Sprint, thì điều gì sẽ xảy ra? Liệu Scrum Team sẽ bỏ qua nó cho đến sự kiện Sprint Planning kế tiếp không? Không, Scrum không yêu cầu nhóm bỏ qua một tình huống khẩn cấp được xác định giữa Sprint. Thay vào đó, Product Owner sẽ có một số lựa chọn:

1. Trì hoãn công việc

• Product Owner là người đại diện cho khách hàng và các bên liên quan, có trách nhiệm quản lý Product Backlog và định hướng cho Scrum Team phát triển sản phẩm.
• Khi nhận được yêu cầu khẩn cấp hoặc gấp đột xuất giữa Sprint, Product Owner có thể quyết định trì hoãn công việc đó để không làm gián đoạn Sprint và tốc độ cung cấp giá trị. Việc này sẽ được thêm vào Product Backlog và được thực hiện trong các Sprint kế tiếp.

2. Thêm vào Sprint hiện tại

• Nếu công việc được xem là quan trọng và ảnh hưởng đến mục tiêu của Sprint, Product Owner có thể xem xét việc thêm nó vào Sprint hiện tại.
• Tuy nhiên, việc thêm công việc mới vào Sprint có thể ảnh hưởng đến tốc độ cung cấp giá trị và Goal của Sprint hiện tại. Do đó, Product Owner cần cộng tác và trao đổi với nhà phát triển để xác định xem công việc có thể được thêm vào mà không làm gián đoạn Sprint Goal.
• Quá trình này có thể đòi hỏi thỏa thuận giữa nhà phát triển và Product Owner, và có thể dẫn đến việc loại bỏ các công việc ưu tiên thấp hơn ra khỏi Sprint để tạo chỗ cho yêu cầu mới này.

3. Huỷ bỏ Sprint hiện tại

• Trong một số trường hợp đặc biệt, Product Owner có thể quyết định hủy bỏ Sprint hiện tại vì tình huống mới ảnh hưởng đến giá trị của Sprint Goal và không còn phù hợp nữa.
• Ví dụ được đưa ra để minh họa tình huống trong đó Sprint Goal của Scrum Team không còn phù hợp nữa do thay đổi không ngờ trên thị trường, và nhóm cần phải xem xét lại hướng đi của công việc hiện tại.
• Tuy nhiên, việc hủy bỏ Sprint hiện tại là một phương án cuối cùng và chỉ được thực hiện trong trường hợp đặc biệt và cần thiết.

Nâng cao chất lượng để giảm tần suất các tình huống khẩn cấp

Nếu sản phẩm của bạn gặp tình huống khẩn cấp thường xuyên, nhóm Scrum cần xem xét các giải pháp để giảm thiểu tần suất này trong buổi Sprint Retrospective. Điều này có thể bao gồm thêm các mục trong Product Backlog để cải thiện chất lượng sản phẩm hoặc cập nhật định nghĩa hoàn thành để thêm các bước kiểm thử.

Các phương án khác có thể là cải thiện quá trình làm mịn (Refinement) hoặc tiến hành khảo sát người dùng để xác định nguyên nhân gốc rễ của các tình huống khẩn cấp.

Kết luận

Nói tóm lại thì, trong bất cứ trường hợp nào việc huỷ bỏ Sprint hiện tại chỉ có Product Owner là người có quyền quyết định và hãy chắc chắn rằng chỉ khi nào cảm thấy giá trị của sản phẩm đang phát triển bắt đầu trở nên lỗi thời hoặc không còn phù hợp với hiện trạng thì hãy đi tới quyết định này nhé.

Hỡi các Product Owner, hãy cộng tác và trao đổi thường xuyên hơn với Scrum Team để có những quyết định đúng đắn nhất, cùng nhau tìm ra giải pháp để dù cho trong trường hợp nào thì Sprint Goal cũng sẽ không bị ảnh hưởng và giá trị đem lại cho khách hàng luôn luôn là cao nhất.

Các ông có thấy Scrum dễ hiểu không? Trên lý thuyết thì tưởng chừng như mình có thể làm được ngay và làm thật tốt là đằng khác. Nhưng mà thực sự thì rất là khó để thành thạo luôn. Đó là bởi, Scrum đòi hỏi sự can đảm và tập trung vào những vấn đề khó khăn, đồng thời yêu cầu những quyết định khó khăn. Việc xử lý yêu cầu của khách hàng giữa các Sprint cũng là một thách thức và việc quyết định lựa chọn một trong rất nhiều lựa chọn khác có thể được coi là nghệ thuật của Scrum framework.

Nguồn: https://www.rebelscrum.site/post/scrum-is-not-an-excuse-to-ignore-an-emergency