Polêmica: Product Owner pode participar da Retrospectiva?

Apesar do que se ouve por aí, a resposta é simples: sim, não só pode como DEVE participar! O Product Owner é parte do time de Scrum e como membro do time, deve estar em todas as retrospectivas.

Product Owner é parte do time

O objetivo de uma retrospectiva é permitir que o time avalie o sprint em busca de oportunidades de melhoria nos processos, na comunicação, no relacionamento, na qualidade do produto e também na entrega de valor. Em todos esses aspectos, o Product Owner exerce uma enorme influência e, portanto, se ele não está lá, perde-se uma grande oportunidade de melhoria.  Pior do que isso: cria-se um distanciamento do PO com o resto do time gerando um impacto negativo nas relações do dia a dia. Frases como essas acabam se tornando muito comuns e demonstram a fragilidade das relações:

“Isso é problema do PO!”

“Lá vem o PO de novo trazendo problema pra gente!”

”Olha aí o PO fazendo a mesma besteira de novo!”

“A culpa é do PO!”

Transparência, inspeção e adaptação são os pilares do Scrum, e isso vale para todos. Sentir-se parte do time é importante, mas ser parte do time é ainda mais.

Colaboração é chave

Os melhores times com os quais trabalhei entendiam perfeitamente a importância de se ter um Product Owner, não só próximo, mas presente no dia a dia do time. Isso é fundamental para que se possa criar um ambiente colaborativo, onde desenvolvedores e Product Owner trabalham juntos para garantir entregas de alto valor, o que por sua vez garante o sucesso do projeto.

E quando o Product Owner é o cliente?

Um cenário em que a participação do Product Owner na retrospectiva acaba gerando desconforto é quando o PO é o próprio cliente. Nem todo mundo curte a ideia de ter o cliente na sala no momento em que nossas fragilidades e problemas são levantados, mesmo que seja com o objetivo de melhorar sempre. Tratei desse tema em outro post – Polêmica: o melhor PO não é o cliente!

Princípios Ágeis

Um dos princípios Ágeis fala em “aproximar pessoas de negócio e desenvolvedores”. Isso vale para todos os momentos: bons e ruins. Feedback frequente e transparente formam o combustível de equipes de alta qualidade. Então não se esqueça: Product Owner, ScrumMaster e Desenvolvedores estão no mesmo barco, ou seja, jogam no mesmo time. Ir na direção contrária é ir contra o próprio conceito de Agilidade.

Click here to read this post in english.

Marcos Garrido, Sócio-fundador e Trainer na K21

Sobre o autor(a)

Co-fundador da K21, Nower e Wbrain

Marcos Garrido, co-fundador da K21, é Certified Enterprise Coach (CEC), Certified Scrum Trainer (CST) e Certified Team Coach (CTC), fazendo parte do seleto grupo no mundo que possuem as três certificações mais importantes da Scrum Alliance. Com grande atuação internacional, possui larga experiência em Transformação Digital e Gestão de Produtos.

Artigos relacionados

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Sabe quando você tem uma ideia brilhante para um produto, mas todos os times de desenvolvimento estão atolados até o pescoço? A janela de oportunidade é agora… mas a fila é de três meses para começar qualquer coisa. E se…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Há pouco tempo fiz duas mudanças na minha vida. A primeira foi mudar de apartamento na egrégia cidade do Rio de Janeiro. O apartamento é maior, estou mais perto de serviços e, além disso, a entrada do metrô fica literalmente…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

O Kanban Maturity Model (KMM) é um modelo de maturidade que fornece parâmetros para que organizações possam avaliar e avançar na adoção do Kanban para melhor gerir seus fluxos de trabalho. Ele permite que as equipes entendam sua situação atual…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

No meu último artigo, escrevi sobre o funcionamento do upstream e os possíveis resultados que um item de trabalho pode receber nessa parte do fluxo de trabalho. Eles são: descartar o item porque não é interessante, viável ou rentável; continuar…