Scrum, nghệ thuật của việc ra quyết định

Có nhiều câu hỏi và mối quan tâm về việc quản lý rủi ro xoay quanh việc trao quyền cho Scrum Team như:

Làm thế nào để đảm bảo thành công cho Product nếu Product Owner không hiểu nhiều về Product hoặc chưa đủ kỹ năng? Làm sao Product Owner quyết định được Business Value nào sẽ là trong 20% mang lại 80% giá trị? (80/20 - Pareto Principle)

Việc trao quyền cho Development Team dẫn đến nhiều rủi ro tiềm ẩn? Làm sao Development Team biết nên làm gì và làm thế nào để tạo ra Done Increment?

Ordering the Product Backlog helps to avoid "The Undisciplined Pursuit of More"

​Những suy nghĩ đó là những lo lắng thường thấy, khi bạn đang quen với việc quản lý rủi ro bằng command và control. Trong những tổ chức được xây dựng trên việc phân cấp quản lý, nơi mà những kế hoạch dài hạn được lập nên rất kỹ để đảm bảo không có bất kỳ sự cố nghiêm trọng nào xảy ra trong tiến trình phát triển sản phẩm. Việc này không sai và việc quản lý rủi ro là cần thiết.

Nhưng với những thay đổi liên tục từ thị trường đòi hỏi doanh nghiệp phải nhanh hơn đối thủ của mình, thì việc phân cấp quản lý và lên kế hoạch mọi thứ lại làm mất đi khả năng uyển chuyển thay đổi, đội nhóm phụ thuộc vào việc phân cấp, nơi quyền quyết định thường được phải qua nhiều tầng lớp (Silo) hay người đứng đầu. Thêm nữa quyết định từ người đứng đầu hay quản lý lúc này lại thiếu sự đối thoại với thị trường, hay người dùng, nơi mà người trực tiếp làm việc với khách hàng lại có cơ hội hiểu được người dùng nhiều hơn.

Lúc này, Trao Quyền để tăng khả năng uyển chuyển và sáng tạo để phát triển nhưng vẫn đảm bảo rủi ro được quản lý, những sai lầm vẫn được chấp nhập trong một khuôn khổ cho phép, hay nói khác đi là self-organize trong một ranh giới với một mục tiêu rõ ràng là vô cùng cần thiết.

Tôi tin rằng Scrum có thể giải quyết những vẫn đề trên rất tốt. Bằng cách tạo ra một không gian hỗ trợ Scrum Team học làm sao để đưa ra quyết định đúng, hay còn gọi là làm việc một cách thông minh hơn là làm việc nhiều hơn:

• Bằng cách sắp xếp Product Backlog, và hiểu rõ trên cùng của Backlog là những giá trị có thể được phát triển vào Sprint kế tiếp. Product Owner có thể nói “Không” với những lãng phí, và tập trung vào việc xác định và xây dựng giá trị cho người dùng, tránh việc bị rơi vào “Những mong muốn nhiều hơn nữa một cách vô thức” (“The Undisciplined Pursuit of More”).

 

• Nên nhớ chúng ta đang đối mặt với những thứ phức tạp, nơi mà chúng ta không biết rõ điều gì là đúng. Do đó một vòng lặp ngắn của Sprint là chìa khoá giúp quản lý rủi ro. Nếu sai giá phải trả sẽ nhỏ, ngoài ra bằng việc tạo được một vòng lặp quán tính (Momentum) cho việc học hỏi từ thất bại, Scrum Team có thể xác định tiếp được nên làm gì và có được quyết định đúng hơn tiếp theo.

 

• Những sự kiện trong Scrum tạo ra cơ hội để inspect và adapt, nó có time-box vừa đủ, không nhiều hơn. Điều này giúp team có cơ hội để xem lại và cập nhật kế hoạch của mình, cho phù hợp và đúng với tình hình thực tại, qua đó có thể đạt được mục tiêu của Sprint (Sprint Goal)

 

• Sprint Goal cho Team một mục tiêu rõ ràng, làm kim chỉ nam, giữa cho team không mất đi sự tập trung, qua đó có thể tự quản lý được kế hoạch, tự ra quyết định và giải quyết những vấn đề gặp phải trong Sprint. Ngoài ra với mục tiêu rõ ràng và tập trung, đội sẽ có thể dành tất cả khả năng tại thời điểm đó để đạt được mục tiêu với chất lượng tốt nhất, thay vì quá nhiều mục tiêu làm cho nỗ lực và công sức bị phân tán. 

 

• Time-box giúp team tập trung vào việc tìm kiếm những giải pháp và ra quyết định tốt nhất có thể trong bối cảnh hiện tại cho phép, thay vì lãng phí thời gian trong những buổi họp dài.

 

Power of Less but Better - "Essentialism" of Greg Mckewn

• Và hơn hết, Scrum không yêu cầu phải thay đổi những phân cấp trong tổ chức hiện tại của bạn. Để làm được điều này, phải có sự khéo léo trong việc cân bằng giữa hai cấu trúc cùng lúc, và vai trò Scrum Master là cần thiết. Scrum Master sẽ support Developement Team, Product Owner. Tổ chức áp dụng Scrum và tối ưu hoá được giá trị Scrum mang lại, đảm bảo sự tin tưởng giữa các Team với nhau, transparency luôn được giữ, từ đó Scrum Team có thể có được những quyết định đúng, nên làm gì và vào thời điểm nào là tốt nhất. (Last Responsible Moment)

​
Kết Luận

Scrum như một ngôi nhà, với trụ cột là chủ nghĩa kinh nghiệm, và những giá trị của Scrum sẽ tồn tại trong ngôi nhà đó. Ngôi nhà đó sẽ tạo ra một vùng an toàn vừa đủ giúp cho Scrum team có thể tự quản công việc của mình, và mỗi ngày sẽ một làm tốt hơn. Với cách tiếp cận đó Scrum Team có thể từng bước, thử nghiệm để khám phá rằng điều gì là nên làm, và khi nào là thời điểm thích hợp để làm. Với Scrum chúng ta học cách làm việc thông minh hơn thay vì làm rất nhiều nhưng rơi vào sự hỗn loạn và lãng phí. Scrum là nghệ thuật của việc ra quyết định - Làm ít hơn (Nghĩ nhiều hơn) nhưng tốt hơn.

Scrum on!