9 Perguntas que Scrum Masters e Product Owners deveriam fazer
Antes de me tornar Scrum Master, trabalhei como líder técnico com uma variedade de equipes. Parte desse trabalho era tomar decisões – e acredito que fazia isso muito bem. Capacidade de decisão e assertividade fazem parte das minhas características pessoais.
Essas características, no entanto, não me ajudaram muito quando me tornei Scrum Master. Percebi que, para ter sucesso como Scrum Master, precisava fazer menos afirmações e, em vez disso, fazer mais perguntas. Como isso não correspondia ao meu estilo natural (e não eram essas as características que me trouxeram sucesso até esse ponto da minha carreira), no início foi difícil para mim.
Mas com um pouco de paciência, fui ficando cada vez melhor em fazer perguntas. Algumas das minhas perguntas favoritas
gostaria de compartilhar com você. A maioria das perguntas se aplica tanto a Scrum Masters quanto a Product Owners.
2 Perguntas sobre avaliações
Frequentemente preciso de uma estimativa aproximada de uma equipe. Não vou cobrá-los por isso. (Não estou pedindo um Commitment. Estimativas e commitments não são a mesma coisa.) Eu realmente só quero uma estimativa aproximada. Nesse caso, esta é uma boa pergunta:
"Não preciso de uma estimativa. Mas se eu pedisse uma estimativa, qual unidade viria à mente de vocês? Horas, dias, semanas, meses ou anos?"
Sim, eu sei, essas unidades podem se sobrepor – algumas semanas podem ser mais do que um mês. Mas uma estimativa como "Ah, semanas, algumas semanas." geralmente é suficiente para tomar uma decisão, o que também pode significar decidir pedir à equipe que estime o trabalho com um pouco mais de precisão.
Em situações onde tenho uma estimativa oficial de uma equipe, frequentemente faço outra pergunta:
"Qual o nível de confiança de vocês com essa estimativa?"
Aqui você quer descobrir quão segura é a estimativa e se os membros da equipe concordam entre si. Uma estimativa na qual a equipe tem 90% de confiança será mais precisa do que uma estimativa na qual a equipe no geral não está muito segura e onde as opiniões divergem mais.
Divergências dentro da equipe em relação à estimativa também podem ser um indicador de que a equipe foi precipitada ao dar essa estimativa. Isso não precisa ser algo ruim, mas você deve estar ciente de que a estimativa então não é tão confiável.
3 Perguntas sobre decisões em equipe
Como Scrum Master ou Product Owner, às vezes queremos ter uma noção de quão profundamente a equipe refletiu sobre uma decisão. Aqui estão três perguntas que costumo fazer:
- "Quais outras três opções vocês consideraram antes de tomar essa decisão?"
- "Qual seria a pior coisa que poderia acontecer se continuarmos nessa direção?"
- "O que precisa dar certo para que essa seja realmente a melhor decisão?"
Talvez não seja ideal fazer as três perguntas de uma vez, nem as mesmas perguntas em cada decisão da equipe.
Além disso, como Scrum Master ou Product Owner, você não faz essas perguntas porque pode reverter a decisão da equipe. No entanto, você tem o direito de entender quão confiante a equipe está com a decisão e se houve consenso entre eles.
Essas perguntas servem para revelar esse tipo de divergência. Quando você pergunta "O que precisa dar certo para que essa seja realmente a melhor decisão?" e alguém responde "Tudo!", isso geralmente significa que há um problema.
2 Perguntas sobre Reuniões
Eu não gosto muito de reuniões. Se eu estivesse num corredor com um monte de cobras numa ponta e uma reunião na outra, não saberia para que direção correr.
Por isso, tento ao máximo reduzir o número de reuniões e o número de participantes das reuniões ao mínimo. No início de uma reunião, costumo fazer as seguintes perguntas:
- "Precisamos de todas as pessoas que estão aqui?"
- "Quem mais deveria estar presente?"
A primeira pergunta serve para descobrir se podemos dispensar uma ou outra pessoa. Vejo frequentemente equipas ágeis que exageram um pouco no trabalho em equipa e na colaboração. Os membros da equipa sentem então que precisam participar de todas as reuniões, mesmo quando são completamente irrelevantes para eles. Pode ser, por exemplo, o desenvolvedor JavaScript que participa numa reunião sobre se vale a pena migrar para a nova atualização do fornecedor de base de dados.
Se os membros da sua equipa são um pouco entusiastas demais com reuniões, agradeça-lhes pelo empenho na colaboração, mas transmita-lhes também que não precisam estar em todas as reuniões. Crie a regra de que nenhum membro da equipa deve participar de uma reunião se não puder contribuir o suficiente ou não puder extrair valor suficiente dela.
(Sim, isso pode ser abusado. Talvez precise deixar claro para algumas pessoas que isso não significa que não precisam participar de mais nenhuma reunião. No final, a equipa como um todo deve ter o direito de anular a decisão de uma pessoa de não comparecer a uma reunião.)
Com a segunda pergunta, pretende-se descobrir se alguém que ainda não está presente deveria estar. Mesmo odiando reuniões (provavelmente escolheria as cobras), às vezes precisamos de mais pessoas nas reuniões.
Na dúvida, opte por menos reuniões e menos pessoas, mas algumas reuniões simplesmente precisam acontecer – e essas reuniões são ainda mais valiosas quando as pessoas certas estão presentes.
1 Pergunta para circular pelo escritório
Especialmente quando trabalho como Scrum Master, passo muito tempo participando de conversas no escritório. Isso também é conhecido como Management by Wandering Around (em português: Gestão por Andar por Aí). Por exemplo, quando percebo que um programador e um testador estão tendo uma conversa aparentemente importante, às vezes vou até eles para ver se posso ajudar com alguma coisa.
(Claro que não se deve fazer isso toda vez e também não quando parece ser uma conversa privada!)
Às vezes, as conversas que acabo ouvindo por acaso também são valiosas para outras pessoas. Talvez o Redator Técnico devesse saber o que o testador e o programador decidiram. Por isso, pergunto:
- "Alguém mais deveria saber sobre isso?"
Se for o caso, ofereço compartilhar essas informações, se for possível para mim. Se não, ofereço chamar a pessoa correspondente diretamente.
1 Pergunta para Daily Standups
No Daily Standup, olho para o Burndown Chart da equipe e frequentemente me pergunto como a equipe pretende terminar todo o trabalho até o final do Sprint. Mas quando pergunto a essa equipe se eles acham que vão conseguir, geralmente são muito otimistas.
Quando considero isso irrealista, olho novamente para o Burndown Chart e pergunto:
- "Vocês sabem algo que eu não sei?"
Talvez eu receba como resposta que um dos membros da equipe ainda não atualizou suas horas na ferramenta do time. Ou alguém explica que, embora estejam um pouco atrasados no momento, aprenderam bastante e as coisas estão acelerando novamente. (Raramente acho isso realista, mas ouço com frequência.)
Perguntar à equipe o que eles sabem e eu não, oferece uma ótima oportunidade de sincronizar suposições. Talvez eles assumam que agora tudo vai acelerar novamente, mas eu não penso assim. Por isso, é uma excelente pergunta para revelar suposições diferentes.
Conclusão: Perguntas são melhores do que afirmações
Quando assumi o papel de Scrum Master pela primeira vez, ainda não conhecia o poder das perguntas e perdi muitas oportunidades de aprender mais sobre minha equipe e seu trabalho. Só depois de bastante tempo descobri que aprendo mais quando faço perguntas e realmente escuto as respostas.
Espero que você ache essas perguntas tão úteis quanto eu achei.
Este artigo é do blog de Mike Cohn e foi traduzido por nós para o alemão.
