Por que o P.O não faz parte do time?

Juliano, no Scrum, é absolutamente importante que o PO não entre nesse movimento de opinar tecnicamente. Ele já tem poder demais pois é el quem decide o que deve ser feito. Se ele começar a ter atuação nas decisões técnicas, fica muito desequilibrado para o time.

Geralmente, o P.O. tem muita força dentro das empresas, é frequentemente alguém de escalão mais alto, isso também poderia fazer o time se sentir "acuado" e deixaria de trabalhar.

Facilitei pelo menos dois times em que os P.Os tinham background técnico e queriam ficar dando sugestões de solução.

O time sempre ficava desconfortável para se posicionar em fazer qualquer crítica à ideia dele e na grande maioria das vezes as ideias eram bastante ruins porque a pessoa, por nçao estar conectada no dia a dia técnico, não via uma série de problemas da abordagem, issgo gerava um movimento de começarmos a explicar os problemas para o PO com a visão dele, ele ficava desconfortável, perdíamos tempo produtivo do time e nada melhorava de fato.

O P.O deve discutir produto, funcionalidades, falar sobre as necessidades dos clientes, já tem muita responsabilidade para também querer dar opiniões técnicas.

E no Scrum geralmente "o time" se refere as pessoas que não são o facilitador e o PO, referente ao conjunto responsável pelo desenvolvimento efetivo do produto.

Mas em outras leituras, também se fala "time", se referindo à todos os três papéis. Acho que nesse caso se refere de fato ao time de desenvolvimento, do qual o PO realmente não faz parte.

Pensando na questão dentro da analogia do porco e da galinha:

Basicamente o P.O fez papel de Chicken pois não está diretamente comprometido com o desenvolvimento (papel daquele time), apenas envolvido.

Já o time de desenvolvimento está comprometido com o desenvolvimento e os métodos utilizados, papel do Porco.

Obrigado pelas respostas

@konscia e @gandra-nereu,

A questão da aula é um exercício sobre reunião para criar o contrato de equipe onde pela resposta o P.O não deveria participar. O foco não é sobre definições técnicas e etc.

Existem N "formatos de P.O", vai depender muito da cultura da empresa. Se o seu P.O é um cliente, realmente tem todo sentido ficar de fora do time, pois ele não está no dia a dia. Geralmente ele te contratou e acaba sendo o envolvido (chicken) e não comprometido (porco) , conforme colocado pelo Gandra-Nereu.

Agora existem casos, onde sua empresa é contratada para fazer um software por exemplo, e alguém da sua empresa vai fazer o papel do P.O. Ele vai até o cliente, vai entender o negócio a ponto de conseguir assumir a função de P.O e poder decidir o que é prioritário. Nesse caso, o P.O é funcionário tanto quanto o time de desenvolvimento, ele está tão comprometido, porque se houver alguma falha é rui para os dois. O P.O fica no dia a dia com o time, responde dúvida sobre a sprint etc.

Veja que no scrum guide, ele define o time como “O Time Scrum consiste em um Product Owner, o Time de Desenvolvimento e um Scrum Master. Times Scrum são auto-organizáveis e multifuncionais. Times auto-organizáveis escolhem qual a melhor forma para completarem seu trabalho, em vez de serem dirigidos por outros de fora do Time”

O scrum guide trata o conceito do time como o P.O + Time Dev + Scrum Master.

No meu entendimente, nesse cenário o P.O deveria estar também na reunião pois é time. Dentro do seu cenário um das regras do contrato seria não dominar a reunião e seria ótimo o P.O concordar.

Qual a opinião de vocês?

Juliano, como você destacou, o uso "time" acontece para dois conjuntos:

Time Scrum => Todos

Time de Desenvolvimento => equipe técnica.

Na minha experiência prática Juliano, sempre foi como você descreve, um funcionário da empresa assumindo como PO.

E após alguns anos de prática, eu concordo com a alternativa correta. O PO não deve interferir nas decisões do time (time de desenvolvimento, o técnico), nem tentar opinar.

O PO deve estar 100% focado no que gera mais valor para o cliente.

Geralmente as empresas escolhem seus melhores funcionários como PO's e estes ficam tentados a decidirem sobre o trabalho técnico.

Isso é ruim porque a equipe não consegue se sentir responsável plenamente pela solução, não consegue contestá-lo quando ele está equivocado e bem, como PO ele vai estar mais tempo dedicado ao cliente do que à parte técnica, então, fica ruim.

O que já aconteceu comigo é ter uma situação de atuar com uma equipe muito inexperiente, em que eu era PO e também desenvolvia o software. Aí nesse caso eu dizia que estava usando algumas práticas do Scrum, mas não era Scrum de fato. Nesse caso eu me chamava de "Líder Técnico" e conduzia o desenvolvimento de maneira mais ampla, como analista, PO, facilitador, tudo meio junto. Mas...não era Scrum.