A relação entre o Product Owner, Scrum Masters e Desenvolvedores é fundamental para o sucesso de uma equipe Agile. É uma relação simbiótica que depende de comunicação clara, objetivos alinhados, transparência e é fundamentada na confiança. Construir um produto que seja amplamente adotado ou a melhoria contínua é o objetivo usual, mas a coesão e a dinâmica da equipe podem determinar o quão suave e sem problemas esse processo será.
Queríamos aprender mais, então fomos procurar um Product Owner para compartilhar seus insights e histórias.
Após sua apresentação do roadmap do produto no Perth Agile MeetUp, sentamos com Adam Mullett, autor do livro From “No” to “How?: Get Buy-in and Lead Change e um Product Owner, para perguntar a ele sua opinião sobre o nível de envolvimento que um Product Owner deve ter em uma Retrospectiva.
O que recebemos foi mais do que apenas uma resposta a uma pergunta, mas uma demonstração do papel do Product Owner e uma renovada apreciação da confiança, transparência e disciplina.
A relação entre Product Owner, Scrum Masters e equipe Agile
Adam pareceu um pouco surpreso quando questionado se um Product Owner deveria estar envolvido na Retrospectiva.
A pergunta surgiu da observação de que algumas pessoas envolvidas em Agile percebiam a presença do Product Owner na Retrospectiva como opcional, ou até mesmo um obstáculo.
Após apenas uma breve pausa, sua resposta foi um enfático “sim!”
Ele continuou explicando o ‘porquê’ –
Um dos aspectos importantes do Agile é que não se trata de ser rápido, mas de ser adaptável – o que leva a mais sucesso, como uma melhor adoção de um produto.
Quando se trata de conduzir as Retrospectivas de uma equipe, não é apenas importante facilitar o processo, mas é igualmente importante gerir a cultura. A equipe depende muito da direção e da contribuição do Product Owner como especialista no assunto. O Product Owner promove um ambiente no qual uma equipe pode se esforçar para ter alto desempenho, sendo responsável pelos resultados e autogerida para que permaneça responsável perante seus stakeholders.
Confiança e transparência
Adam percebe que o fundamento da essência de um Product Owner é a confiança e a transparência.
“Para mim, ser transparente é um presente porque estás compartilhando o que pensas ou o que sabes. Se a equipe não consegue tirar isso de ti, então não estás dando a eles o que precisam para terem sucesso.”
“Não deve haver segredos entre a equipa, o Scrum Master e o PO. Para mim, eu concentraria-me nessas coisas. Prefiro levantar a questão e mergulhar no conflito do que deixá-lo apodrecer.”
“Ser capaz de descobrir algo que está impedindo uma equipe de seguir em frente é realmente valioso.”
Adam ofereceu um exemplo de dois membros de uma equipe que não se falavam em um time que ele treinou uma vez.
“Era inacreditável! Então, se houvesse um comentário relacionado ao problema feito durante a Retrospectiva, eu continuaria mergulhando, investigando o ‘porquê’, até que eles percebessem que a falta de comunicação era o problema.”
Embora a abordagem tenha sido um tanto confrontadora, uma vez que a questão foi trazida à tona, foi mais fácil de resolver, e os membros da equipe ficaram gratos mais tarde por o assunto ter sido resolvido.
“Resolver esses tipos de problemas pode ser tão simples quanto oferecer horários de trabalho diferentes. Não falar um com o outro simplesmente não era um bom motivo para não ser uma equipe de alto desempenho. “
Traz as pessoas para a conversa
Um Product Owner deve manter a colaboração em mente, e é por isso que Adam visa co-criar.
“Se estou fazendo algo, quero fazer com você, não para você. Nenhuma mudança terá sucesso se você estiver fazendo isso sozinho”
“Como a colaboração da equipe é necessária para que a co-criação ocorra, é importante saber como e quando trazer as pessoas para a conversa. Escolher a forma como as conversas acontecem pode fazer uma grande diferença.”
“Por exemplo, é mais fácil mostrar o teu trabalho a alguém do que ter de convencê-lo. Um protótipo de uma hora sobre o qual possas conversar é muito mais eficaz, às vezes, do que uma grande sessão de planejamento onde tentas vender a tua ideia. Outras vezes, pode ser melhor co-criar.”
Sê disciplinado com processos e resultados
Quando a disciplina é vista como uma plataforma de apoio, em vez de uma barreira à flexibilidade, ela pode atuar como um mecanismo de empoderamento da equipe.
A disciplina pode ser tão simples quanto começar uma reunião no horário, terminar no horário e ter uma definição estrita de ‘pronto’ (ready). São os pequenos comportamentos acordados aos quais os membros da equipe aderem com o objetivo de melhorar conscientemente a coesão e o respeito da equipe.
Na visão de Adam, com disciplina, podem ser cultivados hábitos saudáveis que apoiam equipes de alto funcionamento.
“Eu era Product Owner em um projeto onde havia 23 equipes e uma mentalidade geral de apenas terminar este sprint, depois outro sprint, e outro, e assim por diante, apenas terminar o sprint como pudéssemos.”
“Então começamos a ser mais disciplinados no sprint.”
“Sim, foi difícil no primeiro mês porque estávamos tentando fazer duas coisas ao mesmo tempo. Mas depois disso, tudo correu bem. E a equipe conseguiu continuar melhorando e crescendo como um time de alto desempenho. Na verdade, outros na organização queriam fazer parte daquela equipe.”
Também se observou que as equipes que careciam de disciplina enfrentavam problemas.
Então, o que deve acontecer se os membros da equipe não adotarem uma abordagem disciplinada?
“Se alguém chega despreparado, é importante deixar claro o propósito da reunião e como as suas ações não apoiam esse propósito.”
“É uma questão de foco. Durante o refinamento do produto (grooming), por exemplo, se as pessoas começam a falar sobre um ticket específico, trata-se de trazer o foco de volta para o porquê de estarmos nesta reunião e o que pretendemos alcançar como resultado para essa cerimônia.”
Claro, o Scrum Master ajuda a manter essa disciplina.
Em relação à Retro deles, Adam acrescentou que, uma vez que a equipe entende e aprecia a estrutura que sua disciplina construiu, eles tornam-se muito mais focados e eficientes, sem ter que se envolver no pensamento do Sistema 2, conforme descrito no livro Rápido e Devagar de Daniel Kahneman.
“Ter um processo claro mantém as coisas fáceis. As equipes não querem ter que se preocupar com coisas como qual sala ou qual tecnologia estão usando. O foco deles é no problema real.”
Desenvolve a tua equipe enquanto eles desenvolvem soluções
Para Adam, não há falta de clareza quanto ao papel do Product Owner; se és um Product Owner, fazes parte da equipe Agile.
“Sinto que é o papel do Product Owner, com o apoio do Scrum Master, construir a cultura e criar clareza para a equipe.”
“As equipes odeiam não saber para onde estão indo. Elas se viram umas contra as outras, ficam ansiosas, tentam parecer ocupadas e todos os tipos de outras disfunções. Se puderes dar às pessoas um motivo, um ‘porquê’, uma direção estratégica, então elas dirão ‘ok, legal. Entendi!’. Trata-se de ser frouxamente acoplado, mas fortemente alinhado. Dessa forma, todos sabemos para onde vamos e permitimos que a equipe chegue lá.”
Adam trabalhou com equipes totalmente presenciais, remotas e híbridas. Durante 18 meses, trabalhou com pessoas espalhadas de Sydney até a Índia. Independentemente da composição, um dos fatores de sucesso de uma equipe de alto desempenho era a compreensão do que aconteceria a seguir.
“Então, se algo acontece na nossa Retrospectiva, alguém sai para criar um ticket no Jira. As pessoas podiam trabalhar juntas mesmo que nem sempre estivessem na mesma sala. Ter formas sólidas de trabalho ajudou a acomodar isso”.
O papel do Product Owner em uma Retrospectiva Agile
Voltando à questão do papel do Product Owner na Retrospectiva, Adam observou que o Product Owner é um participante.
Na sua opinião, a própria Retrospectiva pode ser conduzida por qualquer pessoa da equipe, sendo a sua preferência que a facilitação seja alternada entre os membros para que essas competências possam ser desenvolvidas e valorizadas pelo time.
“Acho que a equipe quer que o PO seja honesto e aberto ao participar”
Em termos do que um Product Owner espera ajudar a alcançar em uma Retro, a resposta de Adam é simples: é para a equipe melhorar no que está fazendo.
Por quê?
“Porque o PO é responsável pelos resultados perante a organização, desde o tempo que algo levou até os recursos utilizados. A equipe é responsável por entregar os resultados. Portanto, o PO inteligente participará da Retrospectiva para ouvir. Eles não dirão às pessoas o que fazer, ou que devem fazer ‘desta forma’. Se a equipe já soubesse, já o teria feito.”
Adam vê a Retrospectiva como uma oportunidade para a equipe –
- descobrir soluções
- descobrir coisas ao longo do caminho para ser uma equipe de alto desempenho e
- subir na escada da maturidade.
O Product Owner quer ajudar a construir uma equipe de alto desempenho por vários motivos –
- para melhorar a previsibilidade
- para ter uma gestão de user stories boa, sólida e regular
- para melhorar a confiança e a qualidade geral
à medida que as funcionalidades são desenvolvidas ao longo do tempo.
Incentiva e possibilita mudanças em tuas Retros
Então, por que as Retros funcionam?
“Acho que é porque a equipe tem autonomia para propor coisas que pode mudar. Eles podem definir metas SMART que podem colocar em prática nas duas semanas seguintes. Eles mesmos identificam o problema que os afeta, por isso são autodirecionados para a mudança.”
Notou-se que algumas pessoas podem temer a mudança porque algo está sendo imposto a elas, e elas não sentem que têm o controle.
“Algo que menciono em From “No” to “How?”, é a esfera de influência e os locais de controle. É importante ajudar a equipe a focar suas conversas onde reside o seu locus de controle, para que se sintam empoderados e capazes de fazer mudanças.”
“Eles devem sentir que podem contar com o PO para alavancar sua influência ou capital social para influenciar além da esfera de influência da equipe.”
“Enquanto isso, se uma equipe Agile sente que está no controle do seu destino, ela pode mudar o seu mundo e fazer as coisas acontecerem. Eles se sentem mais empoderados para agir e podem, então, seguir em frente e realizar as tarefas.”
Como um Product Owner pode guiar uma equipe para longe da disfunção
Não podíamos deixar o Adam ir sem pedir o seu conselho sobre como fazer a transição de uma equipe da disfunção para o alto desempenho.
As principais lições:
- Garante que todos saibam para onde estão indo, seu propósito, e certifica-te de que todos estejam na mesma página.
- Garante que haja uma boa comunicação; seja de membro da equipe para membro da equipe, ou para o Product Owner e Scrum Master, a comunicação precisa ser aberta e honesta.
- Disciplina! Dá às pessoas a plataforma para a criatividade. Começa no horário, foca no objetivo da reunião. Isso fornece uma estrutura para que as pessoas possam florescer.
- Diz-lhes sempre o “porquê”
- Expõe a disfunção. Identificar problemas, conflitos e erros é ótimo porque algo foi descoberto.
Tens outros insights ou histórias para compartilhar sobre como melhoraste as relações de trabalho entre a tua equipe Scrum e o Product Owner? Adoraríamos que compartilhasses conosco.
Sobre Adam Mullett
From “No” to “How?: Get Buy-in and Lead Change incentiva o compartilhamento de resultados de tentativas de melhoria fracassadas com colegas e com o chefe como uma forma de consolidar a lição e compartilhar o aprendizado com os outros.