Việc phát triển sản phẩm trong một môi trường phức tạp luôn tiềm ẩn một số rủi ro do tính chất không thể đoán trước. Có rất nhiều sự bất ổn có thể xảy ra về kinh doanh, thị trường, công nghệ, kiến ​​trúc, tích hợp, tiền tệ, tài chính, tiếp thị ….

Đối mặt với một số lượng lớn rủi ro trong việc phát triển cung cấp sản phẩm là điều không thể tránh khỏi. Và việc chúng ta cần làm là quản lý rủi ro để đối ứng với sự bất ổn này.

Trong thực tế, nhiều người nghĩ rằng rủi ro không phải là mối quan tâm đối với các dự án sử dụng các phương pháp Agile. Hoặc rủi ro chỉ xuất hiện trọng các dự án sử dụng Waterfall, do đó các dự án Waterfall mới phải thực hiện quản lý rủi ro. Hoặc, dự án chúng tôi Agile, chúng tôi làm Scrum, vì vậy không có rủi ro.

Do đó, mọi người có xu hướng quên đi việc quản lý rủi ro khi làm việc với Scrum. Hoặc, họ có xu hướng sử dụng hỗn hợp các phương pháp quản lý rủi ro truyền thống và Scrum. Kết hợp này có thể không hiệu quả và hữu ích.

Do vậy làm sao để quản lý rủi ro hiệu quả đối với dự án sử dụng Scrum?

Câu trả lời ngắn gọn đó là dùng 3 trụ cột Scrum: Transparency, Inspection, and Adaptation và sử dụng chủ nghĩa thực nghiệm (Empiricism).

Thông thường, xét về quy trình quản lý rủi ro, Sau khi đã xác định và lập danh sách rủi ro, ta cần phân loại rủi ro, phân tích xác xuất và tác động của mỗi rủi ro, sau đó đưa ra các phản hồi tương ứng cho từng rủi ro. Khi làm cách này, ta cần thực hiện các hành động đưa ra và phải update thường xuyên danh sách này.

Tuy nhiên đối với dự án sử dụng Scrum, thì việc quản lý rủi ro dựa trên chủ nghĩa thực nghiệm và thông qua các Sự kiện trong Scrum. Bằng cách này, rủi ro sẽ được quản lý một cách tự nhiên và ‘vô thức’ chứ không phải tuân theo một quy trình định nghĩa trước. Cụ thể hơn:

• Trong sự kiện Daily Scrum, Scrum team sẽ tìm ra rủi ro khiến ta không đạt được Sprint Goal, rủi ro không hoàn thiện các hạng mục công việc. Sau đó, team sẽ tìm cách để đối phó với các rủi ro này.
• Trong buổi Sprint Planning, Scrum team sẽ dự đoán các items sẽ được thực hiện, cùng nhau tạo ra Sprint Backlog và mục tiêu Sprint. Scrum cũng dự đoán những vấn đề gặp phải trong việc hoàn thiện các items, do đó rủi ro cũng được xác định. Do đó trong sự kiện này, việc xác định và đánh giá rủi ro cũng được thực hiện.
• Trong sự kiện Sprint Review, Scrum team và stakeholder cũng đánh giá về các rủi ro về Business và Technology khi đánh giá và thảo luận về Phần tăng trưởng trong Sprint đó, và triển vọng khi deliver phần tăng trưởng này.
• Trong sự kiện Sprint Retrospective, team sẽ thảo luận về các vấn đề trong Sprint vừa qua về quy trình, công cụ, con người… Đây cũng là cơ hội để cải tiến và giảm thiểu rủi ro cho các Sprint sắp tới.

Ngoài các sự kiện đề cập ở trên, các hoạt động khác trong Scrum đóng góp trong việc quản lý và giảm thiểu rủi ro:

Product Backlog Refinement là một cơ hội tuyệt vời để Nhóm Scrum và các bên liên quan thảo luận về rủi ro. Trong khi order các items trong Product Backlog, thì cũng xác định Items nào rủi ro nhưng vẫn có giá trị? Yếu tố nào rủi ro và không mang lại giá trị đáng kể? Nó có đáng để giữ nó trong Product Backlog không? Chúng ta cần chạy thử nghiệm nào để xác thực các giả định của mình?

Các tạo tác trong Scrum hỗ trợ trong việc quản lý rủi ro như thế nào?

• Chiến lược phát hành và Phần tăng trưởng đều liên quan đến quản lý rủi ro. Bạn có thể giảm thiểu rủi ro bằng cách cung cấp các items thực sự thỏa mãn Định nghĩa hoàn thành. Định nghĩa Hoàn thành phản ánh về sản phẩm đã đạt chất lượng và “sự sẵn sàng phát hành” của Phần tăng trưởng (đã hoàn thành, tích hợp, có khả năng phù hợp).
• Với Product Backlog được quản lý bởi PO, thì PO cũng phải xác định các rủi ro giá trị của các items, và sự phụ thuộc giữa các items với nhau
• Sprint backlog thường cập nhật hàng ngày để đạt được Sprint Goal, trong Sprint Backlog còn có các rào cản, WIP, .. mà team có thể đánh giá để quản lý rủi ro.

Trong Scrum Team, việc quản lý rủi ro được thực hiện hàng ngày bởi tất cả các thành viên thông qua rất nhiều thứ (ví dụ: Sự kiện Scrum, Phần tạo tác, Metrics…). Với mỗi rủi ro được xác định, team cần có chiến lược giảm thiểu rủi ro, các hành động tương ứng cần thực hiện và thường xuyên xem sự hiệu quả của các hành động đã thực hiện. Nên đưa rủi ro là một hạng mục trong Product Backlog (có thể để riêng hoặc mỗi items tương ứng với một vài rủi ro), như vậy sẽ tăng tính minh bạch.