O papel do Scrum Master: coaching, facilitação e impedimentos

Pergunte a dez organizações o que os Scrum Masters delas fazem e você vai ouvir respostas que vão de “conduz as cerimônias e atualiza o quadro” a “faz coaching de três times e negocia com o nosso comitê de financiamento”. O próprio framework é sucinto nesse ponto: o Scrum Master é responsável pela eficácia do time e por garantir que o Scrum seja compreendido e praticado, dentro do time e na organização como um todo. Essa única frase contém muito mais trabalho do que uma agenda de reuniões.

Este guia trata da prática, não da definição. Se você procura o framework em si — os eventos, artefatos e compromissos dentro dos quais o papel atua —, comece pelo guia do framework Scrum. Aqui vamos ver com o que um Scrum Master realmente gasta o tempo, os julgamentos envolvidos e as formas como o papel dá errado.

Liderar sem autoridade

O papel não tem autoridade hierárquica. Um Scrum Master não atribui trabalho, não aprova férias, não conduz avaliações de desempenho nem decide prioridades, e toda a influência disponível vem de ser útil. Essa restrição é proposital: um time que recebe ordens de alguém com poder sobre a carreira de cada um não vai se autogerenciar, e a autogestão é justamente o mecanismo que faz os ciclos curtos de feedback valerem a pena.

A diferença fica mais clara no comportamento do que na teoria.

A coluna da direita é mais lenta da primeira vez e mais rápida em todas as seguintes, e essa é toda a aposta. Ela também é frequentemente confundida com passividade. Servir o time não significa concordar com ele: um Scrum Master que vê o time ignorar a definição de pronto por três sprints sem dizer nada falhou pelo menos tanto quanto um que dá ordens.

Facilitar eventos que geram decisões

A facilitação é a parte visível do trabalho e a mais fácil de fazer mal. O teste para qualquer evento é se algo mudou por causa dele.

Sprint planning. A falha comum é uma reunião de quatro horas em que o time discute os itens um a um e nunca chega a uma meta. O Scrum Master intervém exigindo que a meta seja rascunhada antes da seleção dos itens, cortando discussões técnicas sem fim e deixando-as para depois, e fazendo a pergunta incômoda quando o time seleciona mais do que jamais concluiu.

Daily Scrum. A degradação clássica é uma roda de relatos individuais dirigidos ao Scrum Master ou a um gestor. Correções práticas: ficar em frente ao quadro e percorrer o trabalho da direita para a esquerda, em vez de pessoa por pessoa; perguntar sobre a meta da sprint, e não sobre indivíduos; sair da sala de vez em quando para que o time aprenda que o evento é dele. Qualquer assunto que precise de mais de um minuto vira uma conversa depois do evento, só com as pessoas envolvidas.

Sprint review. Muitas vezes é reduzida a uma apresentação de slides. O remédio é um sistema funcionando na frente de stakeholders reais, com o product owner conduzindo a conversa sobre o que fazer em seguida e com a demonstração feita por quem construiu a funcionalidade.

Retrospectiva. É a mais difícil de manter viva. Os sintomas de desgaste são as mesmas três reclamações a cada duas semanas e nenhuma mudança visível. Varie o formato para que as perguntas mudem; coloque a ação da retrospectiva anterior no topo do quadro; limite o resultado a uma ou duas mudanças que o time realmente controla; e separe os problemas que o time consegue resolver daqueles que precisam ser levados para fora, que passam a ser trabalho do próprio Scrum Master.

O refinamento não é um dos cinco eventos, mas na prática consome um tempo considerável. A contribuição do Scrum Master ali costuma ser o time-boxing e as técnicas de quebra de histórias, e não o conteúdo, que cabe ao product owner.

Impedimentos: quando remover e quando não remover

O registro de impedimentos é onde está a maior parte da alavancagem do papel, e o julgamento é sobre quem deve fazer a remoção.

Alguns impedimentos estão claramente fora do alcance do time e cabem ao Scrum Master: um processo de compras que leva seis semanas para adquirir uma licença, um ambiente compartilhado que outro departamento mantém reservado o tempo todo, um comitê de aprovação que se reúne uma vez por mês, uma política que proíbe o time de fazer deploy do próprio código. Eles exigem conversas organizacionais que o time não tem legitimidade para conduzir, e essa é a parte do papel que mais afeta os resultados. Muitos são problemas da esteira de entrega que uma abordagem DevOps existe justamente para eliminar.

Outros impedimentos o time pode e deve resolver. Uma massa de dados de teste que falta, um critério de aceite pouco claro, um colega que não respondeu uma mensagem, um build que está vermelho desde ontem: se o Scrum Master assume essas coisas, o time aprende que atrito é problema de outra pessoa e para de desenvolver esse músculo. O movimento útil é perguntar quem vai resolver e até quando, e depois fazer o acompanhamento.

Uma regra prática: remova os impedimentos estruturais, políticos ou que se repetem entre times; faça coaching do time nos que são técnicos, locais ou pontuais. Na dúvida, faça com o time, e não pelo time, na primeira vez, e deixe que ele faça sozinho na segunda.

Coaching rumo à autogestão

Os times não chegam autogerenciáveis, e o papel muda de forma à medida que eles amadurecem.

No início. O time não conhece o framework e espera respostas do Scrum Master. O trabalho é ensinar: para que servem os eventos, como escrever uma meta da sprint, por que trabalho não terminado não conta, o que a definição de pronto deve conter. Aqui um comportamento diretivo é adequado, e ele deve diminuir de forma visível.

No meio do caminho. O time domina a mecânica, mas evita conflitos, cede à voz mais alta ou carrega trabalho de um sprint para outro sem falar nada. O trabalho agora é facilitação e feedback honesto: trazer à tona o que está acontecendo sem julgamento, ensinar o time a discordar de forma produtiva e ajudá-lo a definir os próprios padrões de qualidade, em vez de aceitar um imposto de fora.

Na maturidade. O time conduz os próprios eventos, levanta os próprios impedimentos e melhora sem precisar ser estimulado. A atenção do Scrum Master se volta para fora — para a relação com os stakeholders, as dependências com outros times, as restrições organizacionais que ainda limitam o time e, muitas vezes, para ajudar times mais novos. Um bom sinal de maturidade é quando os eventos acontecem perfeitamente bem enquanto o Scrum Master está de férias.

A relação com o product owner merece atenção própria o tempo todo. As contribuições práticas incluem ajudá-lo a encontrar técnicas de ordenação do backlog, proteger o tempo de refinamento, prepará-lo para dizer não aos stakeholders e mediar quando o time sente que o backlog é uma lista de desejos que caiu de fora. O que um Scrum Master não deve fazer é assumir em silêncio a ordenação quando o product owner está ausente — isso esconde a vaga em vez de expô-la.

Métricas que valem a pena acompanhar e métricas a recusar

Um Scrum Master precisa de dados para tornar as conversas concretas, e o perigo é que qualquer número publicado vire meta.

A velocidade merece cuidado especial. Ela é um reflexo dos hábitos de estimativa de um time específico, e no momento em que é reportada para cima como produtividade, os times inflam as estimativas e o número deixa de carregar informação. Tudo o que for reportado para fora do time deve tratar de resultados — funcionalidades lançadas, metas atingidas, defeitos escapados — e não de unidades internas.

Antipadrões

• O secretário. Reserva salas, faz as anotações, atualiza o quadro, corre atrás de status. Tudo o que é visível nos eventos está feito, e nada muda na eficácia do time.
• O gerente de projeto disfarçado. Atribui tarefas, acompanha o progresso individual, reporta percentual concluído, negocia escopo em nome do time. O cargo mudou; o modelo de operação, não.
• A polícia do processo. Aplica o framework ao pé da letra, cita o guia a todo momento e trata os eventos como questão de conformidade. Os times obedecem e deixam de ser honestos, o que destrói a transparência.
• O facilitador ausente. Conduz os quatro eventos, não faz coaching de ninguém, não leva nenhum impedimento para fora e chama isso de liderança servidora.
• O ponto único de contato. Toda pergunta dos stakeholders passa pelo Scrum Master, o que parece prestativo e impede que o time construa relacionamentos diretos.
• O fornecedor de métricas. Passa a semana produzindo gráficos de velocidade para a gerência e o resto do tempo defendendo esses gráficos.

O teste mais forte do papel é contrafactual. Se o Scrum Master saísse amanhã, a eficácia do time cairia? Se a resposta honesta é que outra pessoa teria de marcar as reuniões, a responsabilidade nunca foi realmente exercida. Quando vários times estão envolvidos, a metade organizacional do trabalho cresce ainda mais — veja agilidade em escala para os problemas de coordenação que surgem.

Principais conclusões

• A responsabilidade é a eficácia do time, não o bom andamento de quatro reuniões; a facilitação é um meio, não o trabalho.
• O papel propositalmente não tem autoridade sobre pessoas nem sobre prioridades, porque um time que recebe ordens não vai se autogerenciar.
• Facilite para que cada evento gere uma decisão ou uma mudança; um evento cujo resultado é uma atualização de status fracassou.
• Assuma você mesmo os impedimentos estruturais, políticos e entre times; faça coaching do time nos locais e técnicos para que ele desenvolva essa capacidade.
• Ajuste seu comportamento à maturidade do time — ensine no início, facilite no meio do caminho e trabalhe para fora quando o time já andar sozinho.
• Mantenha a velocidade dentro do time, reporte resultados para fora e trate como distorcida qualquer métrica que vire meta.