APRENDER. PRATICAR. EVOLUIR.1. Identificar a ajuda que está a ser pedida
Uma equipa fictícia prepara automatização de deployments para aplicações financeiras. Duas pessoas conhecem as opções técnicas, mas não conseguem comparar os riscos numa conversa produtiva. Outra pessoa desconhece a Definition of Done. Uma terceira quer melhorar a forma como pede ajuda. Estas necessidades justificam intervenções diferentes. A primeira pode beneficiar de facilitação, a segunda de ensino e a terceira de uma conversa de coaching. Começa por clarificar o resultado pretendido e o conhecimento já disponível. A escolha da intervenção não depende apenas do cargo de Scrum Master; depende do problema, da relação e das capacidades necessárias. Estes modos de apoio complementam as responsabilidades definidas em Scrum, sem criar novos cargos obrigatórios.
2. Tornar explícita uma mudança de abordagem
Quando facilitas, ajudas as pessoas a estruturar a conversa e a construir uma decisão. Se tens uma opinião técnica forte, reconhece esse interesse e evita apresentá-la como conclusão inevitável do grupo. Numa conversa de coaching, perguntas abertas podem ajudar a pessoa a observar a sua experiência e escolher um próximo passo. Se for útil partilhar experiência ou conselho, explicita a mudança e confirma se a pessoa quer ouvi-los. Ensinar Scrum exige apresentar corretamente os seus conceitos; neutralidade no processo de facilitação não obriga a tratar uma regra incorreta como igualmente válida. A clareza sobre a intervenção permite aos participantes compreender quem está a explorar, aconselhar ou decidir.
3. Criar espaço para contributos distintos
Numa reunião remota em inglês, rapidez de resposta pode ser confundida com conhecimento ou concordância. Três pessoas escrevem observações importantes no chat, enquanto duas dominam a discussão oral. Uma experiência possível é começar com escrita silenciosa, agrupar observações e depois discutir diferenças. Esta técnica é uma opção de facilitação, não uma regra obrigatória de Scrum. Explica o objetivo, dá tempo suficiente para compreender a pergunta e permite que os participantes esclareçam os seus próprios contributos. Não assumes que silêncio significa concordância. Antes de concluir, verifica se existem objeções ou dados que alterariam a decisão. O resultado desejado é compreensão partilhada e participação útil, não uma distribuição artificialmente igual de segundos de fala.
4. Usar factos para explorar divergências
Após uma falha de deployment, operação e desenvolvimento atribuem a causa um ao outro. Uma retrospetiva útil começa por separar observações de interpretações. Reconstrói a sequência com registos temporais, decisões conhecidas e lacunas de informação. Um registo às 14:02 mostra um evento; não demonstra sozinho a causa fundamental. Convida as pessoas a explicar que informação tinham quando decidiram. Isto ajuda a identificar condições que podem repetir-se, como um alerta sem destinatário claro ou uma verificação que ocorre tarde. Respeitar as pessoas não impede discutir escolhas e responsabilidades. Permite fazê-lo com evidência, sem transformar a reunião numa votação sobre quem merece culpa ou num exercício de defesa de departamentos.
5. Agir sobre barreiras fora da equipa
Um pedido de ambiente aguarda há três dias porque uma regra exige aprovação de alguém fora da equipa. Os Developers já avaliaram alternativas e não têm autoridade para alterar essa regra. O Scrum Master pode ligar o impacto observado à pessoa que consegue decidir, esclarecer opções e acompanhar a resposta. Não precisa de executar pessoalmente todo o trabalho técnico para promover a remoção do impedimento. Também não deve interpretar autogestão como autorização para contornar controlos. Mantém visíveis responsável pela decisão, próxima ação e momento de acompanhamento. Enquanto isso, os Developers adaptam o seu plano. Depois de resolver o caso, inspeciona se o mesmo mecanismo cria atrasos recorrentes que justificam uma melhoria organizacional.
6. Praticar uma intervenção e inspecionar o efeito
Escolhe uma situação fictícia: uma pessoa monopoliza a discussão, existe uma dependência externa ou a equipa não compreende uma regra de Scrum. Escreve o resultado pretendido, a intervenção escolhida e um sinal observável de melhoria. Para participação, verifica se apareceram perspetivas relevantes antes ausentes. Para uma dependência, acompanha tempo de espera e capacidade de decidir. Para ensino, pede aplicação do conceito num exemplo novo. Uma única reunião bem avaliada não prova uma mudança sustentada. Regista o que aprendeste e decide se deves manter ou alterar a experiência. O resumo desta aula é escolher ajuda adequada, tornar a abordagem compreensível e devolver à equipa capacidade de agir com conhecimento.
Exemplo fictício: o pedido de ambiente E17 está bloqueado há três dias. Os Developers adaptam o plano; o Scrum Master facilita uma conversa com o responsável pela regra, levando impacto, opções e uma decisão concreta.
Armadilhas comuns
Esconder conselho em perguntas, tratar silêncio como concordância, confundir respeito com evitar problemas e fazer do Scrum Master o único intermediário de todas as decisões.
Tópicos relacionados: Autogestão com responsabilidades claras · Review, retrospetiva e aprendizagem utilizável
A intervenção deve corresponder à necessidade: compreender, aprender, decidir ou remover uma barreira. Explicita a abordagem e inspeciona se aumentou a capacidade de ação da equipa.
Referência: Comparing Facilitation, Coaching, Mentoring and Teaching · PSM I; Scrum Guide November 2020; no public numbered exam revision