Há uma importante discussão acontecendo na lista ScrumDevelopment. Há uma dúvida sobre o papel do membro mais importante do time - o product owner. Jean Richardson começou a conversa com a seguinte questão:
Eu estou trabalhando com um cliente que é novo em Scrum. Até agora, eles estão muito anciosos. Nós tivemos e estendemos lições aprendidas na semana passada em um ½ projeto difícil e eles vêem Scrum como a resposta para suas preces. O seu gerente leu /Gerenciamento de Projetos Ágeis com Scrum/, e um dos membros do time está na metade do livro.
Entretanto, o gerente pediu uma reunião comigo no final desta semana em relação a “quem seria o Product Owner.” Eu acho que seu time está empurrando-o para compartilhar esse papel entre todos eles—ou ao menos 3 deles (ele próprio e mais dois). Então, minha questão é, como é que funciona compartilhar esse papel através de duas ou mais pessoas. Será que isso funciona bem? Se sim, o que é preciso para que isso funcione bem? Que tipos de coisas você vê acontecendo?
Isto é, evidentemente, uma questão ou ocorrência comum. A maioria dos conselhos caiu em duas áreas:
Área 1: Você deveria ter somente um product owner. Por exemplo, Dan Rawsthorne sugeriu:
Eu sempre tenho uma resposta simples para "quem será seu product owner". Eu pergunto: "quem deve ser responsável pelo sucesso? Quem tem um alvo em suas costas? Esse é o seu product owner." Na minha experiencia, o PO é normalmente ungido em seu exterior.
Isso trouxe uma série de observações interessantes, uma das quais evocando uma inconsistência na maneira que o product owner é tratado e percebido:
No entanto, isso não traz à tona uma dicotomia interessante para o Scrum? Se o PO é o único com a corda no pescoço da perspectiva de requisitos/ROI, por quê não há uma única pessoa com a corda no pescoço da perspectiva do time?
Eu pergunto porque eu já tive inúmeras conversas com os doutores do Scrum que apontam a falta de responsabilidade no time. Enquanto o time é responsável por tornar-se auto organizado e finalmente fazer o que precisa ser feito, não há nenhuma corda no pescoço quando eles não o fazem. Eu tenho visto os times lutando para se tornar auto organizados. Alguns nunca tem sucesso. É difícil de responsabilizar o time inteiro, especialmente quando muitos membros fazem o seu melhor.
Área 2: No front do "isso depende", o comentário de George Dinwiddie foi exemplar:
Sim, isso pode funcionar bem e ainda dividir a carga de trabalho entre os três. Isso também pode ser um desastre. Eu vi os dois.Eles compartilham a mesma visão do projeto? Se não, qual a visão que os desenvolvedores tem?
Todos os três podem trabalhar na sala com os desenvolvedores? Se não, isso é uma bandeira vermelha para mim.
Os três podem tomar decisões rápidas juntos? Se não, acho que não irá progredir.
Eles podem "falar como uma só voz?" Se não, quem os desenvolvedores vão seguir?
Quando eles discordarem, tem uma maneira segura de resolver o conflito? Se não, quem os desenvolvedores vão seguir?
Para responder adequadamente a questão, deve existir um acordo sobre qual o papel e quais as responsabilidades reais de um product owner. É ser o 'único pescoço em jogo'? Será que as responsabilidades são muito mais abrangentes de forma que não possam ser cumpridas em um grande ambiente? Quais são seus pensamentos e experiências?