Atualmente nas empresas que estão passando por um processo de transformação organizacional, querendo sair da inércia, de quebrar o paradigma do caminho hierárquico e dos silos departamentais, acabam não dando todos os subsídios para que os profissionais possam exercer suas funções em plenitude. Vemos cada vez mais, gerentes de áreas de negócio, analistas de requisitos ou “hard users” dessas mesmas áreas assumirem um papel de Product Owner, simplesmente por que de um dia para outro a empresa falou que serão ágeis. Nesse contexto, frequentemente esses profissionais nem conhecem e nem sabem de fato o que precisam fazer, realizando um trabalho aquém do esperado e sem trazer eficácia na entrega e na qualidade dos produtos.

Segundo o Scrum Guide (http://scrumguides.org/scrum-guide.html):

Product Owner é responsável por maximizar o valor do produto e o trabalho do time de desenvolvimentoO Product Owner é a única pessoa responsável por gerenciar o backlog do produtoO Product Owner pode representar os desejos de um comitê no backlog do produto, mas aqueles que desejam alterar a prioridade de um item no Backlog devem recorrer ao Product Owner.”

E agora P.O.?

No contexto descrito anteriormente, o que acontece em muitos casos? Os Product Owners não sabem a dimensão do seu trabalho, não tem a mínima ideia de como escrever histórias e nem definir as prioridades de um produto, consequentemente mal conseguem responder aos inúmeros questionamentos que são feitos pelo time de desenvolvimento.

Isso também, quando não são abordados por gerentes, diretores, CEO, entre outros que fazem todos os tipos de solicitação, nesse caso, o Product Owner submetido por pressão ou intimidação, acabam “tirando o pedido”, sem nenhum critério, criando uma alta expectativa para quem realizou essa solicitação. Podendo com isso gerar um PBI (Product Backlog Item) para adicioná-lo no planejamento de uma próxima Sprint, ou até mesmo inseri-lo indevidamente na Sprint atual.

Por não fazer perguntas poderosas, esse Product Owner acaba sendo um mero repassador de problemas e não entendendo se a demanda solicitada vai atender ou não a real necessidade do cliente, podendo até gerar um novo problema.

Dado esse contexto, onde entraria o Agile Coach nesse cenário?

Um Agile Coach seria de extrema importância para atuar em conjunto com o Product Owner, que dada a situação encontra-se totalmente perdido, desde que consentido por ele, para realizar um forte trabalho, fazendo com que o PO entenda e consiga enxergar alternativas e métodos para mudar essa situação.

O primeiro ato desse Agile Coach seria ter uma conversa de coaching com o Product Owner, identificando o seu momento atual e qual é de fato o seu nível de conhecimento sobre o papel que ele desempenhará para a empresa e para o time, podendo assim treiná-lo minimamente sobre o que é esperado na sua posição de PO, repassando conceitos básicos de SCRUM, ensinando técnicas preliminares de como se comportar e agir diante das mais variadas solicitações que ele receberá.

Após entender a situação atual e trazer o PO para um novo nível de conhecimento, será muito importante o Agile Coach acompanhar e apoiar esse Product Owner para que aos poucos ele vá se engajando melhor e possa realizar de forma eficaz o seu trabalho.

É válido orientar o Product Owner na busca de conhecimento complementar através de cursos e certificações existentes no mercado.

O Agile Coach deve estabelecer um prazo junto com o PO para medir os seus avanços e identificar junto com ele novas necessidades de melhorias no seu trabalho.

O Product Owner deverá imergir profundamente nas solicitações que ele receber e entender qual é de fato o problema que precisa ser resolvido. Qual o retorno que essa demanda terá para a organização? Diminuição de custos? Aumento de receitas? Diminuição de reclamações de clientes? E assim escrever histórias completas, detalhadas e com um nível pré-acordado (Definition of Ready) com o time para que seja possível realizar de forma mais assertiva as suas estimativas.

Essas são algumas questões que o Agile Coach pode trabalhar com o Product Owner para melhorar o refinamento do backlog do produto, melhorar a qualidade da escrita das histórias que serão priorizadas e assim poder repassar para o time de desenvolvimento nas reuniões de Sprint Planning o real motivo da inclusão desse PBI e o quanto de valor e benefício será gerado no final dessa Sprint, fazendo com que o time de desenvolvimento esteja sempre engajado, mais motivado e contextualizado com o valor que será obtido com os esforços que serão dispendidos.

Concluindo

O papel do Product Owner é importantíssimo, pois ele traduzirá as necessidades estratégicas das empresas em desenvolvimento de novos produtos, melhorias de produtos existentes e também para passar de forma mais detalhada possível as informações para o time que fará “a mágica” acontecer. Esse é um papel que o Agile Coach precisa sempre acompanhar de perto e auxiliar sempre que possível para ter uma melhor integração e obtenção dos melhores resultados.

 

Sobre o autor: Ricardo Bruno

Ricardo Bruno Alves da Silva

Ricardo Bruno, tem mais de 20 anos de experiência com tecnologia. Foi sócio fundador de 2 startups, trabalhou em empresas de médio e grande porte, como provedor de internet, indústria, varejo e serviços. Amante de frameworks ágeis como Scrum, Kanban, Lean, XP e Lean Inception. Hoje é Agile Coach de uma fintech em grande crescimento. Além de Agile Coach (CAC) certificado é também:
Leader Coach
Certified Scrum Master (CSM)
Certified Scrum Product Owner (CSPO)
CLF® – Certified Lean Inception Facilitator

https://www.linkedin.com/in/ricardo-bruno-alves-silva/