Có thể thực sự bỏ vai trò Chủ sở hữu sản phẩm không?

Đây là phản hồi cho bài viết của Mike Cohn. Đã đến lúc không còn vai trò Chủ sở hữu sản phẩm của Scrum? Nó không yêu cầu bạn phải đọc bài báo của Mike trước.

Ba tuần sau khi thảo luận về tính chất bắt buộc của Sơ kết Sprint , Mike Cohn đã thả một quả bom khác: anh ta đặt câu hỏi liệu vai trò Chủ sở hữu sản phẩm có còn được yêu cầu hay không . Thay vào đó, nhóm Phát triển có thể chia sẻ trách nhiệm. Đối với thảo luận về Sơ kết Sprint, anh ấy không phải là người đầu tiên đưa ra vấn đề này. Nhưng Mike là một tên tuổi lớn trong Scrum và đây là lý do tại sao điều này có tác động nhiều hơn nếu những người từ bên ngoài thế giới của Scrum tuyên bố nó.

Mike có những lý do sau để đưa ra điều này:

• Không có gì trong vai trò ngăn cản nó trở thành một trách nhiệm chung cho một nhóm;
• Các nhóm Agile tuyệt vời chia sẻ trách nhiệm của họ (như viết mã, thử nghiệm). Điều này cũng có thể đúng với các quyết định về sản phẩm;
• Các đội tự tổ chức chọn cách tốt nhất của riêng họ với các lựa chọn kiến ​​trúc. Điều tương tự cũng có thể áp dụng cho các quyết định về sản phẩm;
• Một nhóm luôn biết nhiều hơn một Chủ sở hữu sản phẩm tận tâm.

Không phải là công việc của Product Owner sẽ trở nên lỗi thời. Ngược lại, nó vẫn quan trọng. Tuy nhiên, Mike gợi ý rằng Nhóm Phát triển có thể có trách nhiệm này. Nó cũng giống như việc bạn có trách nhiệm thực hiện kiến ​​trúc, xây dựng phần gia tăng, thử nghiệm phần gia tăng - có các nhóm thực sự đa chức năng.

Không nên nhầm lẫn một nhóm đa chức năng với ' mọi người đều làm mọi thứ '. Mặc dù đây là một cách khả thi để làm việc theo nhóm, nhưng nó không cần phải theo cách đó và nó thường không như thế này. Thường thì bạn có những người (nhiều hơn) chuyên về xây dựng trong khi những người khác (nhiều hơn) chuyên về thử nghiệm. Mike lập luận rằng bạn có thể có ai đó (hoặc nhiều người) trong nhóm chủ yếu chuyên về quản lý sản phẩm, lãnh đạo / hướng dẫn nhóm. Tuy nhiên, cô ấy / anh ấy / họ nên hiểu rằng cả nhóm có thể và nên quyết tâm khi đưa ra quyết định về sản phẩm.

Các vấn đề có thể xảy ra

Mike nêu một số điều kiện tiên quyết (cảm ơn Sjoerd Nijland đã giải thích chúng) về cơ bản liên quan đến sự trưởng thành của một đội:

• Các thành viên của Nhóm Phát triển cần rời khỏi trách nhiệm giải trình tập trung vào chuyên gia của họ và chấp nhận trách nhiệm giải trình sản phẩm đầy đủ. Không còn “Tôi chỉ là một nhà thiết kế nên tôi chỉ thiết kế”.
• Các thành viên của Nhóm Phát triển cần có quyền sở hữu - không còn phải “nói cho tôi biết chính xác những gì phải làm”.
• Các thành viên của Nhóm Phát triển nên '' mang hết trái tim và đam mê của họ ”.
• Không nên có nhiều quyết định ở cấp độ cá nhân. Không chỉ không có Product Owner là người duy nhất đưa ra quyết định về sản phẩm. Điều này cũng áp dụng cho nhà thiết kế, người thử nghiệm, kiến ​​trúc sư, kỹ sư. "Chiếc cổ có thể vắt được" sẽ đi ra ngoài cửa sổ. " - Mike Cohn

Có một vấn đề tương tự nếu Nhóm phát triển không thực sự tự tổ chức. Để làm cho nó hoạt động, điều quan trọng là Nhóm Phát triển xác định thứ tự của Product Backlog, chọn Mục tiêu Sprint và xác định những hạng mục họ sẽ chọn trong một Sprint.

Điều gì tạo nên Scrum Scrum?

Một số người có thể nghĩ rằng bằng cách loại bỏ Product Owner, Scrum thực sự dừng lại là Scrum. Nhưng Product Owner không phải lúc nào cũng là một phần của Scrum. Vai trò được giới thiệu để giải quyết vấn đề mà nhiều người đang giải quyết cho Nhóm Scrum với các yêu cầu. Một người nào đó đã phải thực hiện trật tự này, do đó Product Owner đã được giới thiệu.

Cốt lõi của Scrum là:

“… Một khuôn khổ để phát triển, phân phối và duy trì các sản phẩm phức tạp.” - Hướng dẫn Scrum 2017

Scrum sử dụng chủ nghĩa kinh nghiệm - minh bạch, kiểm tra, thích ứng - để giải quyết các sản phẩm phức tạp. Công việc được thực hiện bởi các nhóm chức năng chéo, tự tổ chức.

Scrum như một khuôn khổ để giải quyết các sản phẩm phức tạp, sử dụng chủ nghĩa kinh nghiệm, được thực hiện bởi các nhóm tự tổ chức và các nhóm chức năng chéo luôn là điều Scrum hướng tới.

Sự ra đời của Product Owner là một giải pháp cho một vấn đề. Khi một vấn đề nhất định không tồn tại nữa, lý do cho Chủ sở hữu sản phẩm cũng có thể biến mất.

Nó chỉ phù hợp khi Scrum cũng đã thích ứng , ví dụ:

• Scrum ban đầu không có Scrum Master, Sprint Retrospective, Product Owner, Định nghĩa “Hoàn thành”;
• Scrum bỏ yêu cầu cho ba câu hỏi trong Scrum Hằng ngày, Scrum bỏ từ “chải chuốt”;
• Scrum Master đã thay đổi từ trưởng nhóm thành huấn luyện viên.

Một sản phẩm với nhiều nhóm

Tôi tin rằng có một bắt được. Có vẻ như lập luận để loại bỏ vai trò Chủ sở hữu sản phẩm của Scrum dựa trên ý tưởng rằng có mối quan hệ 1-1 giữa Chủ sở hữu sản phẩm và Nhóm phát triển. Tuy nhiên, điều này là không đúng sự thật:

“Nhiều Nhóm Scrum thường làm việc cùng nhau trên cùng một sản phẩm. One Product Backlog được sử dụng để mô tả công việc sắp tới trên sản phẩm. ” - Hướng dẫn Scrum 2017

Có mối quan hệ 1-1 giữa Product Backlog và Product Owner. Do đó, có một mối quan hệ một-nhiều giữa Chủ sở hữu sản phẩm và Nhóm phát triển .

Ai chịu trách nhiệm về Product Backlog này khi không còn Product Owner nữa? Tất cả các Nhóm Phát triển cùng nhau? Điều này có khả thi không? Tôi lập luận rằng trong những trường hợp này, bạn không thể yêu cầu các Nhóm Phát triển thực hiện việc sắp xếp các Hạng mục tồn đọng.

Kết luận - ý tưởng hấp dẫn nhưng có vấn đề

Ý tưởng của Mike Cohn để loại bỏ vai trò Chủ sở hữu sản phẩm thật hấp dẫn. Tôi tin rằng có những lợi ích to lớn khi có trách nhiệm của Chủ sở hữu sản phẩm được chia sẻ bởi Nhóm phát triển, có chuyên môn về quản lý sản phẩm trong Nhóm phát triển.

Tôi luôn thích điều đó khi Chủ sở hữu sản phẩm cộng tác với Nhóm phát triển theo cách mà cô ấy / anh ấy về cơ bản là một phần của nhóm này. Tôi cũng thấy rằng Chủ sở hữu sản phẩm tách rời khỏi nhóm đã không thành công như những người thuộc nhóm như thế nào.

Tuy nhiên, tôi cũng thấy các vấn đề với cách tiếp cận này, đặc biệt là trong môi trường mà Scrum không được hiểu đầy đủ hoặc nơi các nhóm không thực sự tự tổ chức và chức năng chéo. Thêm trách nhiệm của Chủ sở hữu sản phẩm cho Nhóm phát triển đang gặp khó khăn trong việc tự tổ chức sẽ chỉ khiến mọi thứ trở nên tồi tệ hơn.

Một vấn đề khác mà tôi thấy là trong trường hợp có nhiều nhóm làm việc từ một Product Backlog, một thực tiễn mà - tôi tin rằng - là một sắc thái quan trọng trong Scrum. Tôi không thấy nhiều Nhóm phát triển chịu trách nhiệm về một Product Backlog này. Mike tuyên bố rằng không có gì trong vai trò Chủ sở hữu sản phẩm ngăn cản nó trở thành trách nhiệm chung cho một nhóm. Tôi cho rằng thực tế là một chủ sản phẩm có thể làm việc với nhiều đội không ngăn chặn nó.

Tôi tò mò liệu ý tưởng này từ Mike có nhiều hơn một ý tưởng hay không. Có lẽ đó là một dấu hiệu của những gì sắp đến. Rốt cuộc: trang giọng nói của người dùng Scrum Guide đã bị đóng trong khi “Hướng dẫn Scrum mới đang được phát triển”. Nhưng ý tưởng này thực sự phải được thực hiện đúng cách.

Cảm ơn Maarten Dalmijn và Marty de Jonge về phản hồi của bạn.