Lorem ipsum dolor sit amet, conse ctetur adip elit, pellentesque turpis.

Image Alt

Scopphu

  /  Artigo   /  Os desafios de um Product Owner

Os desafios de um Product Owner

Porque haveria o Product Owner de impedir a entrega de valor? A resposta é simples: não deveria, mas é um problema recorrente.

É uma situação comum e vê-se frequentemente em equipas que funcionam com Scrum, sem o mínimo de intenção por parte do Product Owner.
Maarten Kossen (PST e Agile Coach) deixou-nos com 4 observações sobre o funcionamento (e impedimento) do Product Owner, bem como sugestões de melhoria.

1. O Sprint BackLog é o plano da equipa de Desenvolvimento

Um dos maiores erros cometidos pelos Product Owners é de dar demasiado enfoque ao que está e não está no sprint backlog.
Imaginemos que contratamos o serviço de um experiente motorista privado para completar uma viagem através do país, do Algarve ao Porto. Será que vamos dar-lhe instruções ao longo do caminho? Vamos monitorizar todos os detalhes da viagem, o itinerário, a velocidade, a postura e o estilo de condução? Ou vamos simplesmente encostar-nos no lugar do pendura, relaxar, e esperar até que cheguemos ao nosso destino?
Como Product Owner, estará provavelmente mais focado no que está no sprint backlog e menos focado no objetivo do Sprint, que deveria ser o cerne da sua atenção.
O teu objetivo é que a tua equipa entregue valor. Se queres chegar ao Porto, não importa muito qual o itinerário que o condutor escolheu. O foco é sempre ter um objetivo (ou sprint goal) o mais palpável e concreto possível, de forma a que a equipa saiba qual a direção certa a seguir. O caminho escolhido é o menos importante, confia na tua equipa para levar-te ao destino, pois mesmo que eles se deparem com algum trânsito, vão encontrar forma de o contornar ao fazer pequenas alterações ao sprint backlog de forma a garantir que chegaram ao Porto.

No final do sprint, pouco interessa se o caminho escolhido pela equipa de desenvolvimento foi a A1 ou A8, desde que todos cheguem ao Porto.

2. Coisas que não são o Sprint Goal

Apesar de ser um tópico abrangente a todas as funções do Scrum, é de especial interesse aos Product Owners já que estes têm uma autoridade adicional sobre qual a direção que o sprint goal deve tomar. Para além disso, devem dar o exemplo à Dev. Team ao expor um claro objetivo de negócio para trabalhar.

Ter um único sprint goal para focar irá melhorar a entrega de valor e assegurar o foco da equipa de desenvolvimento.

Imaginemos que estamos a conduzir do Algarve para o Porto, Braga, Guimarães e Aveiro, tudo ao mesmo tempo. Não vamos chegar a lado nenhum. O senso comum diria para irmos primeiro à cidade mais próxima, depois para a seguinte e por ai além.
No entanto, a maioria dos Product Owners não vê os sprint goals assim, acreditam que as equipas de desenvolvimento conseguem entregar mais valor, ou valor mais rápido se estiverem a trabalhar em várias coisas ao mesmo tempo. No final de contas a entrega será de objetivos meio-completos, e ninguém quer pagar por uma viagem até ao Porto e ficar por Lisboa.
Ciclos de entrega curtos e com um foco bem definido entregam mais valor que ciclos longos e sem definição. Ajuda a tua equipa, tem a certeza que o sprint goal está bem definido e que representa valor concreto.

3. Não dês Importância ao trabalho Importante

Todos nós conhecemos este tipo de trabalho, as entregas de elevada importância, datadas para ontem, os assuntos que não podem esperar e que aparecem espontaneamente ao longo do sprint.
No entanto, vemos muito poucos Product Owners a desafiar a verdadeira importância destes assuntos, permitem que a pressão leve a melhor e acabam por sacrificar o objetivo global por detalhes que acabam por não ser tão importantes como os pintam.

Mantém-te crítico em relação aos assuntos que são “para ontem” e questiona rigorosamente se vale realmente a pena interromper o trabalho desenvolvido pela equipa. Qualquer interrupção pode facilmente custar pelo menos um membro da equipa por um dia, provavelmente mais. Consulta a equipa no momento certo com este tipo de problemas. Discutam, procurem soluções inteligentes e soluções alternativas e, às vezes, decide que algumas coisas simplesmente não serão concertadas.

4. Micro-gestão não é a solução

Se a tua equipa de desenvolvimento não está a fazer progressos ao ritmo esperado, a micro-gestão não vai melhorar o seu trabalho. Podes saber mais sobre os problemas inerentes na formação de Management 3.0.

Interrupções irão abrandar os processos independentemente das tuas boas intenções. Tem a certeza que a equipa sabe que estás disponível para ajudar e pronto a socorrer a qualquer altura. Não tentes apressar uma solução, mesmo que resulte uma vez, a micro-gestão não é uma solução universal e a longo-prazo trará mais problemas que benefícios. 

Se estás preocupado com a tua equipa, fala com os elementos durante o Sprint Retrospective ou fala com o Scrum Master.
Procura também aprofundar os teus conhecimentos com as certificações que a Scopphu tem para te oferecer. Como por exemplo a formação de Professional Scrum Product OwnerTM. A formação combina exercícios práticos com casos reais para que cada participante desenvolva e solidifique a sua aprendizagem como Product Owner.

 

fonte: Scrum.org

Publicar um comentário