Last updated on | Product Owner

20 Product Owner Anti-Patterns

by Luís Gonçalves
product owner antipatterns

Durante toda a minha vida profissional, as pessoas passaram horas a falar-me a importância de bons padrões de design. Acho que todos já compramos livros sobre padrões de design, livros de receitas ou outro tipo de livros que fornecem as boas práticas da indústria.

Não tenho nada contra isso e como poderia? Eu próprio, escrevi sobre Agile Retrospectives tools box :). Todos esses livros são úteis e necessários, mas durante a minha carreira, compreendi que escrever sobre boas práticas não é o suficiente. Temos de escrever sobre o que não devemos fazer, os anti-padrões, os cheiros como gosto de chamar.

Durante as próximas semanas, vou ter algum tempo para escrever sobre este tópico. Vou escrever vários blog posts sobre os cheiros de diferentes papéis em Scrum e sobre vários erros que as empresas cometem, quando implementam scrum. Vou começar esta série com os Anti-Padrões de Product Owner. 

Nenhum Product Owner numa equipa

Vejo este fenómeno a acontecer com bastante frequência em organizações que implementaram o SAFe (Scaling Agile Framework) no passado, desistiram e e voltaram ao  Scrum simples. No SAFe framework, existem duas funções: Product Manager e Product Owner. O Product Manager é o que pensa de forma mais estratégica; o Product Owner é o que pensa mais acerca das atividades do dia-a-dia. Quando as empresas voltam ao Scrum já não existem duas funções, só a de Product Owner, mas as empresas não querem despedir ninguém, então têm de atribuir dois product owners à equipa, mesmo que ainda usem o mesmo mindset: nomear uma pessoa para a parte estratégica e outra para as atividades do dia-a-dia. Vejo isto como uma falha.

Acredito que seja difícil trabalhar neste cenário; tens de ter uma única pessoa responsável pelo produto inteiro, “one single neck”, como um amigo meu costumava dizer.

Solução:

As empresas têm de compreender que não é possível ter este cenário e têm de proporcionar um ambiente em que cada equipa tem um único product owner.

Interferência com o trabalho diário

Vi isso acontecer em várias organizações, principalmente devido a duas causas significantes. Primeiro, porque o Product Owner, no seu passado, foi um project manager típico, onde andava atrás das pessoas para que estas fizessem o seu trabalho. A segunda razão repousa no facto de o Scrum Master não estar ativo, e o Product Owner tem de se chegar à frente e fazer muitas das atividades Scrum Master, levando o papel demasiado a sério, acabando a controlar e a interferir mais do que ajudar.

Nesta situação é normal ver o Product Owner a tomar um papel bastante ativo nas tarefas diárias, manipulando o processo normal. Outro problema que eu vejo com frequência repousa no facto dos Product Owners seguirem o que os developers estão a fazer.

Vi vários exemplos de Product Owner a falarem diretamente com os developers, perguntando o que estão a fazer porque não lhes foi atribuída nenhuma tarefa. Agora, imaginem o que sentem os developers com este tipo de controlo.

Solução:

Acredito que a solução, para este caso, é encontrar um Scrum Master forte e experiente. Um Scrum Master experiente compreende bem ambas as funções (Scrum Master e Product Owner) e pode formar o Product Owner, de modo a permitir à equipa assumir responsabilidades nas suas tarefas.

Um dos papéis dos Scrum Masters é proteger a equipa de intrusões, tendo um master forte e experiente dentro da equipa permite que esta se mantenha isolada e protegida de interferências não desejadas, e, ao mesmo tempo, vai permitir aos Product Owners serem formados nos comportamentos corretos.

Stories construídas em volta de product layers

Este é um tópico complicado. Nos últimos meses, tenho estado a trabalhar com equipas que não têm apresentado resultados tão rápidos quanto poderiam se usassem outras abordagens. Cometem um erro bastante típico; têm user stories que são construídas em volta de product layers.

Como resultado, as user stories dependem umas das outras, causando muitos atrasos na entrega de um produto que pode ser utilizável pelo cliente.

Solução:

Em geral, uma boa user story devia ser escrita abrangendo todos os product layers. Deve ser uma end to end user story. A solução para este problema é formar o Product Owner e a equipa nesse sentido.

Para mim, funciona muito bem quando explico aos developers que não interessa se entregamos 200 back end user stories, quando na realidade o cliente não as pode usar sem a parte front end. Em baixo, uma imagem de Ángel Medinilla mostra de uma ótima forma como devem ser construídas as stories.

product owner antipatterns

Sem projeção sobre o product backlog

Geralmente, o Scrum Master produz gráficos mostrando como correu o sprint. Isto é muito comum, o que não é tão comum é o Release/Program burn down ou burn up. Este é um problema muito comum em muitas das organizações para as quais trabalhei.

Não possuir este tipo de informação torna a vida do Product Owner mais difícil, porque se torna mais difícil saber se a equipa está a cumprir ou não.

Com este tipo de informação disponível, o Product Owner pode tomar melhores decisões sobre o âmbito da entrega do produto a tempo, trazendo o maior valor possível ao cliente. 

Solução:

A solução aqui é muito simples. O Product Owner deve construir um produto burn down/burn up, exatamente como faz o Scrum Master, mas em vez de estar focado no sprint, o Product Owner concentra-se no lançamento. Um exemplo possível pode ser observado em baixo.

product owner antipatterns

O Backlog é cheio de uma série de “Strings”, e não user stories em si

Este problema é, de longe, um dos mais comuns que observei durante os últimos anos. Na maioria das vezes, o product owner não escreve as stories num formato próprio, apenas escreve algumas palavras-chave e fica-se por aí. O problema com esta abordagem tem a ver com o facto de que só quem está na cabeça do Product Owner vai compreender de que se trata a user story. E, para ser honesto, vi alguns exemplos em que nem o product owner sabia o que queria resolver com algumas das user stories que escreveu.

Solução:
Para apontar para a solução, estou a usar um blog post do Roman Pichler. “10 Tips to write good user stories“. 

O Product Owner não tem poder suficiente e não age como o guardião do backlog

Vi esta situação a acontecer em algumas das empresas em que trabalhei. Infelizmente, as empresas não se capacitam de como é perigoso. Nestas empresas, o product owner não tinha o poder de decidir o que quer que fosse e os gestores podiam mudar o backlog como bem entendessem.

Esta situação leva a que os Product Owners não queiram saber mais do produto. Começam por não se interessar pelo ROI, e perdem completamente todo o seu comportamento empreendedor.

Geralmente, isto acontece com uma administração tradicional, onde querem controlar tudo que faça parte do Product Backlog, não dando nenhuma liberdade ou confiança ao Product Owner.

Solução:

A minha experiência diz que esta situação é bastante difícil de resolver, porque, na maior parte do tempo, este problema vem dos gestores acima do Product Owner.

Neste caso, o Scrum Master ou Agile Coach tem um papel fundamental. Ele é responsável por falar com a administração (ou com quem esteja a exercer essas funções) e explicar como esse comportamento tem impacto na empresa e na qualidade do produto.

Eu testemunhei várias situações onde o Agile Coach conseguia explicar à Administração Sénior o que estava a acontecer e era capaz de ajudar a administração a mudar o seu comportamento.

O Product Owner que usa estimativas para definir deadline demos para clientes

Aqui temos o problema típico que é comum em pessoas que não entendem as coisas básicas de software development. Isto é muito mais profundo do que o Agile software development. As pessoas que fazem isto não compreendem como o software development funciona, as suas estimativas são apenas um cálculo aproximado; não garantindo que tudo será feito numa dada data.

Solução:

Muitas pessoas abordam-me dizendo que, por vezes, não escolhemos as datas de lançamento e temos prazos a serem cumpridos. Portanto, não há forma de nos comportarmos de maneira diferente neste tipo de configuração; os clientes só querem ter o seu produto.

Para aqueles que não me conhecem, trabalhei numa grande empresa de fabrico de telemóveis durante anos, por isso, compreendo o que significam as datas definidas pelo mercado.

Todos os anos, tínhamos vendas de Natal em que os telemóveis precisavam de estar cá fora; não havia outra solução, como é que podíamos gerir isso? A resposta é simples: seguir princípios agile básicos.

Product Owner tem de educar o cliente para que depois de cada sprint a equipa tenha algo para mostrar (com isto o Product Owner obtém as suas demos). Durante a demo/review do sprint, o cliente tem a oportunidade de dar feedback sobre o que foi entregue.

E mais importante tem a oportunidade de selecionar as coisas mais importantes que estão no backlog, permitindo à equipa proporcionar mais valor ao cliente.

Ao mesmo tempo (e esta é uma das práticas mais esquecidas), o Product Owner verifica o estado do lançamento geral usando Releases Burn Downs. Esta prática permite ao Product Owner saber exatamente onde a equipa vai aterrar, e iniciar uma discussão com o cliente sobre do que pode desistir, se a equipa não conseguir entregar a tempo.

Se o cliente não estiver aberto a todas estas sugestões, a empresa deve começar a reconsiderar se o cliente é alguém com quem a empresa gostaria de trabalhar no futuro. Os problemas que se vão levantar em interações futuras serão tão complexos que a relação não beneficiará nenhuma das partes.

O Product Owner está muito ocupado para a equipa; ele tem muitas equipas

Eu vejo este problema com uma certa regularidade, Product Owners que estão completamente atolados em trabalho: o Product Owner sobrecarregado.

Solução:

Um Product Owner não deve ter mais do que duas equipas. Claro, que esta é uma regra geral, e pode ser possível ter mais, mas se ele/ela tiver mais do que isso, pode ser difícil dar um apoio total às mesmas.

O Product Owner está muito ocupado para a equipa. Ele passa muito tempo em reuniões com clientes

Este caso é um bocado diferente do anterior, mas o resultado é o mesmo (para a equipa). Em ambos os casos, a equipa não tem o apoio do seu Product Owner, tornando a tarefa de desenvolver o software correto bastante difícil.

Solução:

O trabalho de um Product Owner não é simples; é um trabalho tremendamente complexo, muitas vezes o produto é tão complexo que uma só pessoa não consegue fazer a gestão de tudo.

Vi algumas empresas que trouxerem business analysts para a equipa; estas pessoas tinham a responsabilidade de falar com os clientes para ver as necessidades do mercados, deixando a responsabilidade do produto técnico para o Product Owner. Assisti a esta técnica em várias empresas, e resultou muito bem.

O Proxy Product Owner

Esta pessoa funciona como um placeholder para o product owner. Tal pode levar a decisões atrasadas ou mesmo conflitos. O autor de Agile Product Management with Scrum, Roman Pichler, refere-se a um caso onde o PO estava muito ocupado para exercer a função. Por isso, a equipa arranjou um representante de PO.

No final, houveram vários conflitos porque o proxy PO não tinha o poder de tomar decisões, já que todas as decisões eram supostamente feitas pelo PO oficial que nunca estava disponível.

Solução:

Cada caso é diferente, mas como uma solução geral, acredito que podemos tentar usar a mesma abordagem como no primeiro exemplo. Ter um business analyst dentro da equipa pode ajudar o Product Owner a ter mais tempo para ajudar a equipa a entregar o produto certo.

Comunidade de Product owners

Isto acontece e, empresas que criam um comité responsável pelo produto. Quando não há uma única pessoa responsável por um produto, as decisões podem atrasar. Muitas vezes, a maioria das pessoas envolvidas quer chegar a um acordo entre todas as partes, e isso vai levar a reuniões longas sem nenhum resultado em concreto. Este é um caso típico de “muitos chefs na mesma cozinha”. Isto é bastante semelhante a um dos problemas que levantei acima.

Solução:

Cada produto só deve ter um Product Owner. A experiência diz-me que, se eu tiver muitas pessoas responsáveis por um produto, não tenho nenhuma. Nunca atribuir mais do que um Product Owner a um produto. Se tem vários produtos que estão ligados entre si, pode precisar de ter um programa.

Nesse caso, deve ter um Program Manager ou um Chief Product Owner como algumas empresas o chamam, mas nunca mais do que uma pessoa responsável por um produto.

O Product Owner sacrifica a qualidade do produto para o entregar mais rapidamente

Eu vejo isto acontecer com bastante frequência, especialmente quando um Product Owner está sob pressão externa. As partes interessadas pressionam a lançar o produto mais rápido, mesmo que a qualidade não seja a melhor.

Claro, esta abordagem vai prejudicar a empresa ao longo do tempo; todos sabem que software de pobre qualidade, mais cedo ou mais tarde, cria problemas e danifica a reputação do fornecedor.

Solução:

Este problema é bastante sério e, na minha opinião, é algo que faz parte da cultura de uma empresa (não se interessar pela qualidade). O método que acho mais útil para reduzir este problema é a presença de uma Definition of Done Checklist.

Definition of Done Checklist é uma lista simples de tarefas definidas pela equipa que representa todas as atividades que têm de ser feitas antes de uma story ir para produção.

Sem uma Definition of Done Checklist, é mais fácil o Product Owner levar a equipa a economizar; se esta lista estiver lá, por outro lado, é possível aos developers mostrar que uma story não está feita até todas as tarefas que fazem parte da Definition Of Done estejam completas. A minha experiência diz-me que isso ajuda a reduzir o problema.

Se estiver interessado em saber como pode Melhorar a Sua Definition Of Done, veja este blog.

Confundir a função de um Product Owner com a função de um Scrum Master

Vi isto acontecer muitas vezes em empresas onde os Scrum Masters eram passivos, durante uma ou duas semanas. Nesta situação, os Product Owners não têm o apoio necessário do Scrum Master, e começam a tomar conta de todas as atividades dentro da equipa.

A um dado momento, o Product Owner já não sabe qual é o seu papel e qual é o papel do Scrum Master. Isto leva a muita confusão e, pior do que tudo, conflitos e falta de confiança podem ocorrer entre o Product Owner e o Scrum Master.

Solução:

A solução aqui é muito simples, mas não é fácil de implementar de todo. Neste caso, é extremamente importante ter um Scrum Master forte e com experiência. Grandes Scrum Masters podem fazer o seu trabalho bem, mas ainda mais importante podem treinar outros nos seus trabalhos.

Grandes Scrum Masters são também grandes coaches, ter um Scrum Master forte e competente, nesta situação é fundamental para melhorar estes problemas.

O Product Owner que espera um compromisso alargado “baseado na sua experiência não deve demorar muito.”

É bastante comum ver este comportamento em Project managers old school, onde os compromissos foram quase forçados pelos Project managers ou partes interessadas. Outra causa possível repousa no facto de que os Product Owners serem ex-tech leads ou arquitetos.

Nesta situação, a equipa está a lidar com alguém que tem grandes competências técnicas e que espera que esta resolva os problemas de uma forma mais rápida.

Solução:

Em ambas as situações o trabalho de um Scrum Master é muito importante; ele tem de proteger a equipa. Tem de explicar ao Product Owner que a equipa tem as suas estimativas. São aqueles que decidem quanto é necessário para entregar aquela quantidade de trabalho e não há muito que ele possa fazer.

O Scrum Master tem de explicar ao Product Owner que os membros da equipa estão a dar o seu melhor e ele precisa de confiar neles.

Ser Product Owner porque se é um gestor de departamento. 

Em algumas empresas, a função de Product Owner traz uma situação de poder, e muitas pessoas vão tentar agarrar esta posição mesmo que não tenham nenhum interesse no produto em si. Vão usar esta posição como uma plataforma para aumentar o seu poder político.

Como pode imaginar, a maioria das vezes o resultado disto é pobre e com falta de qualidade, levando a situações frustrantes.

Solução:

Neste caso, acredito que não há muito que eu possa sugerir; a administração tem de perceber que um Product Owner é extremamente importante para a empresa e só as pessoas que entendem os clientes e o mercado é que podem fazer um bom trabalho.

Atribuir posições a quem não entende o mercado ou os clientes é a receita para o desastre. Só posso sugerir que a administração atribuía tarefas às pessoas com base na sua qualidade, e não em interesses políticos.

O Product Owner que acha que não faz parte do seu papel manter o backlog ou que delega a escrita de User Stories para a equipa e para o Scrum Master  

Durante a minha carreira, não vi isto a acontecer com muita frequência (felizmente), mas ainda assim acontece. Este tipo de Product Owner acha que o seu trabalho é apenas despejar ideias no backlog e que outra pessoa qualquer deve fazer o trabalho aborrecido de transformar as ideias em stories. Este tipo de Product Owner acha que este trabalho é muito importante para ser desperdiçado com tarefas secundárias.

Solução:

Acredito que o Scrum Master e que a equipa ela própria têm aqui um papel importante. Juntos têm de explicar ao Product Owner que o mencionado anteriormente é o seu trabalho. Têm de explicar que sem um backlog apropriado, a equipa não pode realizar as suas tarefas.

As stories devem ser discutidas entre o Product Owner e a equipa. O Product Owner é a pessoa que, em última instância, é responsável por manter o product backlog em bom estado.

O Scrum Master e a equipa têm de mostrar ao Product Owner que é extremamente difícil fazer qualquer trabalho se o backlog do produto não for mantido. Uma boa story tem de ser clara, escrita de forma otimizada e no formato INVEST (Independent, Negotiable, Valuable, Estimable, Scalable and Testable), com Critérios de Aceitação adequados.

O Product Owner que acha que um Scrum Master é apenas um project manager cujo papel é chatear as pessoas para que estas façam o seu trabalho

Infelizmente, ainda há muitas pessoas que não percebem nada sobre o comportamento humano. Ainda há muitas pessoas que pensam que castigos e pressão funcionam muito bem para motivar as pessoas.

Muitos destes Product Owners ainda acreditam que as pessoas são preguiçosas e precisam de project managers para os manter na linha, e claro, o Scrum Master serve perfeitamente para este trabalho (de acordo com este ponto de vista).

Solução:

A solução aqui não é de todo fácil de conseguir. Acredito mesmo que terá mais a ver com o mindset do que com qualquer processo agile. Sugeria levar este Product Owner a uma boa sessão de formação agile, para me certificar que ele entende quais são os papéis no Agile software development.

Para complementar, levava-o a uma boa ação de formação sobre motivadores intrínsecos para o ajudar a compreender o que leva as pessoas a fazerem um bom trabalho. Se ele não gostar de ir a nenhuma destas sessões de formação, talvez oferecesse o livro Drive do Daniel Pink. Com sorte, irá perceber que o castigo ou a pressão nunca irão motivar pessoas.

O Product Owner que se recusa a escolher entre cinco prioridades top

Vejo muito isto; o Product Owner chama um Must à story mais importante, depois aparece outra story e ele diz que é mais importante, torna-se uma Must-Must story, e por aí em diante. Isto mostra claramente que o Product Owner não entende qual é a coisa mais importante que tem de ser atingida durante o sprint seguinte.

Ter as equipas a trabalhar em vários assuntos importantes é um fator perigoso. Não há muito tempo, algumas das minhas equipas estavam a trabalhar em diferentes objetivos a serem atingidos num único sprint. O resultado foi pobre, não havia foco, e enquanto todos trabalhavam em tudo, as equipas falhavam constantemente os seus objetivos.

Solução:

Aqui é muito importante que o Product Owner entenda quais são as coisas mais importantes que têm de ser entregues aos clientes.

Os Product Owners têm de entender que uma equipa não pode entregar tudo ao mesmo tempo, portanto, têm de entender qual é a prioridade top que pode ser atingida durante o sprint seguinte.

Quando aplicámos esta regra em algumas das minhas equipas, estas ficaram extremamente concentradas e começaram a entregar muitas mais stories por sprint. Mas, mais importante que isso, começaram a entregar funções completamente implementadas que podem ser enviadas ao cliente.

Antes, as equipas estavam a entregar uma série de coisas, mas nenhuma das suas funcionalidades estava preparada, bloqueando assim o lançamento para os clientes.

O Product Owner que insiste na arquitetura do design da solução

Mencionei atrás que, por vezes, o Product Owner é um ex-arquiteto ou um ex-tech líder. Como resultado, é normal ter este tipo de anti-padrões. O Product Owner quer ser responsável pela arquitetura do produto, levando a equipa à loucura.

Solução:

Scrum Master e a equipa têm de explicar ao Product Owner que o design da arquitetura não é da sua responsabilidade. Gosto sempre de dar esta explicação: o Scrum Master e a equipa são responsáveis por “Como”: Como o produto é feito.

Product Owner é responsável pela parte “O quê”, significando que o Product Owner devia ser aquele a dizer o que deve ser construído.

O Product Owner que não se vê como um membro da equipa

Não vejo este Anti-padrão de Product Owner com muita frequência, mas várias pessoas já mo mencionaram. Por isso, eu estou a adicioná-lo à lista. Como o nome sugere, o Product Owner não se sente ele próprio parte da equipa. Ele sente que só deve ser responsável por fornecer as stories e nada mais.

Como pode imaginar, a cooperação entre os membros da equipa e os Product Owners não será a melhor, e a um certo ponto, a colaboração tornar-se-á muito difícil.

Solução:

O Guia Scrum diz:

“A equipa Scrum é composta por um Product Owner, a equipa de Development e um Scrum Master.”

Mas só porque o Guia Scrum diz isto não há, claro, garantia, que o Product Owner se considerará ele próprio parte da equipa—Mas, eu acho que isto pode ser um bom começo, de qualquer das formas.

Scrum Master ou a equipa devem-lhe explicar que, de acordo com o manual, o Product Owner faz oficialmente parte da equipa.

Para além deste argumento, a equipa e o Scrum Master podem explicar ao Product Owner que não podem fazer um trabalho fantástico a menos que o Product Owner comece a estar mais ligado a eles. Este pode ser um bom tópico para uma das Retrospetivas.

ORGANISATIONAL MASTERY SCORECARD

Desenvolvi um teste grátis que o vai ajudar a identificar que areas da sua organisação precisam de mais ajuda para alcançar excelência no seu processo de Product Development

Faça O Teste
Luís Gonçalves

About Luís Gonçalves

https://plus.google.com/u/0/+LuisGonçalves1979

Luis Gonçalves is an Entrepreneur, Author & International Keynote Speaker. He works with Senior Executives to implement his ‘Organisational Mastery’ system so they can greatly increase the effectiveness and efficiency of their organisations; enabling them to become recognised and highly rewarded Leaders.

Comments

Share your point of view

X