No Scrum, por que as funções Dono do Produto e ScrumMaster não devem ser combinadas?

19

Nos projetos mais tradicionais em que trabalhei, o gerente de projetos (e, em projetos maiores, pode haver gerentes associados / adjuntos / assistentes de projeto caso uma pessoa não esteja disponível) é a pessoa responsável pela comunicação com o cliente, recebendo o projeto atualizações de saúde e status, determinando programação e orçamento, gerenciando o processo, garantindo que a equipe tenha o que precisa para concluir tarefas e assim por diante.

No Scrum, no entanto, essas responsabilidades são divididas entre o Dono do Produto e o ScrumMaster. O Dono do Produto é a voz do cliente. Eles interagem diretamente com o cliente, criam histórias de usuários, organizam e priorizam o backlog do produto e outros problemas enfrentados por usuários / clientes. O ScrumMaster lida com o processo, supervisionando reuniões (incluindo estimativa e planejamento), removendo impedimentos e monitorando a integridade geral do projeto, fazendo os ajustes necessários.

Li em várias fontes, incluindo a Wikipedia , que o papel do ScrumMaster e Product Owner deve ser exercido por duas pessoas diferentes. Eu não apenas li sobre, mas trabalhei em projetos bem-sucedidos de estilo "tradicional", onde as atividades de ambos eram conduzidas por um único indivíduo. De fato, faz mais sentido que uma a três pessoas seja responsável pelo gerenciamento de tarefas de projeto (incluindo recursos humanos / equipe) e de nível de processo, pois elas geralmente andam de mãos dadas. As mudanças no processo têm impacto no cronograma, orçamento, qualidade e outras metas no nível do projeto, e as mudanças no projeto têm impacto no processo.

Por que o Scrum exige o isolamento dessas atividades em duas funções? Que vantagens isso realmente oferece? Alguém já participou de um projeto Scrum de sucesso em que o Product Owner e o ScrumMaster eram o mesmo indivíduo?

— Thomas Owens
fonte

Além disso, juro que essa pergunta já foi feita, mas não consigo encontrá-la e não a marquei como favorita. Muitas perguntas sobre definições de função aqui, mas não estou vendo a PO / SM que tenho certeza de que li.

— Thomas Owens

Você está pensando nesta pergunta ?

— Adam Lear

@ Anna Isso parece familiar, mas na verdade não parece ser uma duplicata. Eu acho que essa pergunta específica pode não ter sido feita antes.

— Thomas Owens

E esse aqui ? :)

— Adam Lear

1

Eu recomendo ler Sucesso com o Agile, onde isso é discutido em mais detalhes.

— Ladislav Mrnka

17

Eles podem (e geralmente são) combinados e executados por uma única pessoa (não há regra contra isso (afinal de contas).

MAS você precisa equilibrar cuidadosamente a responsabilidade pela diferença, pois os dois papéis têm agendas e concorrentes (e é preciso uma pessoa especial para poder fazer as duas coisas simultaneamente). Eu já vi muitas tentativas, mas poucas conseguiram por um longo período de tempo (é uma posição estressante).

Para ser o SM, você precisa de mais conhecimento técnico do que o PO (pois estará ajudando a organizar a equipe de desenvolvimento). É preciso um conhecimento detalhado do produto para poder extrair itens do backlog do produto para o backlog da primavera (às vezes você simplesmente não pode puxar os itens principais 'n', pois isso pode ser contraproducente).
O PO requer mais compreensão do usuário final da equação do que SM. Isso não precisa ser tão técnico, mas exige conhecimento de como o produto será usado no mundo real e a direção que o cliente deseja levar o produto.

Se você puder encontrar uma pessoa que possa desempenhar as duas funções, não vejo razão para impedir isso.

Podem surgir problemas quando a OP está sendo puxada pelo cliente em uma direção que está causando conflitos significativos aos desenvolvedores (porque eles precisam construir alguma outra infraestrutura primeiro). O trabalho da SM não é seguir os caprichos do cliente, mas proteger os desenvolvedores de seus caprichos. Fazer isso objetivamente é difícil.

— Martin York
fonte

1

Sim, a meu ver, é o conflito de interesses que causa o problema. O proprietário do produto deseja o máximo possível, o scrum master precisa gerenciar as expectativas do proprietário do produto.

1

Sua descrição do SM está errada. Você está descrevendo algo como líder de equipe, não SM.

— Ladislav Mrnka

1

Eu discordo totalmente disso. PO e SM são dois empregos realmente diferentes. borisgloger.com/2009/12/07/...

@Pierre Esse link foi postado em uma resposta. Como eu disse em uma resposta a essa resposta, todos, exceto 3, têm contra-argumentos que posso apresentar aqui e agora, e 3 é tão geral que se aplica a todos os cargos de todos os tempos.

— Thomas Owens

3

Verifique também este post que fala especificamente sobre isso: blog.mountaingoatsoftware.com/… . Se a mistura dos papéis funcionar para você, prometo que lhe enviarei uma caixa de chocolates belgas.

4

Não sou especialista, mas acho que o Scrum Master deve ser o advogado / facilitador da equipe. A voz do cliente deve ter em mente os interesses do cliente. O Scrum Master deve ajudar a equipe a obter o que precisa para ter um sprint bem-sucedido.

— Amy Anuszewski
fonte

1

Além disso, lembre-se, na maioria das vezes, de que você não está trabalhando em um cliente por vez. Os proprietários do produto podem gerenciar vários clientes e podem se concentrar nessa parte do negócio, e o ScrumMasters pode se concentrar no desenvolvimento do projeto.

Como muitos disseram, ambos os papéis têm interesses distintos, mas um objetivo comum e diferentes habilidades para adquiri-lo.

— AJC
fonte

Isso pode ser verdade. Em todos os lugares em que trabalhei, a equipe do "nível do projeto" (o equivalente a OPs e SMs) foi dedicada a um único projeto, portanto esse é o único quadro de referência que tenho. A equipe de desenvolvimento pode ser atribuída a vários projetos, mas normalmente até um desenvolvedor é atribuído a um projeto em tempo integral e a funções de suporte em uma ou duas outras.

— Thomas Owens

0

Se a mesma pessoa representa a equipe de desenvolvimento e os usuários / clientes, o único recurso que você tem em uma disputa é observar o contrato. Embora possa eventualmente chegar a isso, é melhor que um representante de ambos os lados com igual poder possa chegar a um acordo.

— JeffO
fonte

Se o pedido não for da organização do cliente (que é, no meu entender, frequentemente o caso), você ainda precisará examinar o contrato se houver uma disputa entre a organização em desenvolvimento (incluindo o pedido) e o cliente.

— Thomas Owens

1

Isso é verdade, mas ter um advogado do cliente na equipe pode ser capaz de lidar com um desentendimento antes que ele volte ao cliente. Se ambos discordam do cliente, isso é outro problema.

— JeffO 9/09/11

0

As pessoas nas funções de Product Owner e Scrum Master podem ter desejos, metas, requisitos e restrições conflitantes, mais do que 2 programadores aleatórios. Os seres humanos podem ou não ser capazes de valorizar igualmente objetivos conflitantes e podem ter mais chances de cometer erros de julgamento quando confrontados com objetivos conflitantes. Duas pessoas com focos ou vieses ligeiramente diferentes podem ser menos propensas a cometer os mesmos erros ou o mesmo grau de erros de julgamento.

Duas pessoas também podem alocar mais horas-homem totais para focar em cada aspecto diferente do problema / projeto (por exemplo, os objetivos dos 2 papéis diferentes).

— hotpaw2
fonte