Os 4 Erros Fatais de um Scrum Master

Um desabafo sobre práticas terríveis do mercado que precisam parar

Nessas minhas caminhadas trabalhando com agilidade tenho visto muitos profissionais com a responsabilidade de conduzir a adoção do framework Scrum junto aos seus times e companhias que, confesso eu, tenho ficado preocupado com alguns acontecimentos.

Alguns receberam por “imposição” esta tão dura missão. Digo dura, pois aprendi na prática o que está escrito no Scrum Guide: o Scrum é leve, fácil de entender mas difícil de dominar.

Não é fácil ouvir do chefe: “agora você vai tocar o tambor”, “ditar o ritmo” ou “fazer com que o time entregue”, “queremos o dobro do trabalho na metade do tempo”…

Digo que recebem por imposição pois algumas empresas, no processo de transformação ágil, fazem a revolução de mudança de estrutura nos cargos, então o Líder de Projetos se torna um… adivinhem… SCRUM MASTER!!!

“Parabéns você ganhou uma nova função, mas tome aqui o seu ‘chicote’ não deixe de continuar mantendo o cronograma atualizado com as horas despendidas em cada tarefa, fazendo assim aquela ‘boa’ e velha micro-gestão”.

Nasce então uma nova “inconformidade” no mundo da agilidade. Algumas das consequências disso tudo podem ser:

O Scrum não adotado por completo que gera descredibilidade sobre os reais benefícios do Scrum ou de qualquer outro método ágil, desmotivação do time, colapso processual de execução das demandas, baixa produtividade e qualidade, atrasos constantes nas entregas, procura por “culpados” e, por fim, demissões.

Tudo isso causado pelo mal entendimento do papel do Scrum Master.

Eu poderia escrever esse artigo tentando explicar o que é ser um Scrum Master mas, visando ser mais prático e direto ao ponto preferi iniciar focando em pontos que estamos falhando e subir o alerta para a comunidade. Vamos ao que interessa!

1 – Scrum Master NÃO É CHEFE e NÃO TEM O CHICOTE na Mão

Alguns sinais para detectar se o time está nos vendo como chefe são:

• O clima do ambiente de trabalho muda para algo mais sério quando estamos próximos;
• O time não discorda de nossas sugestões mas às “seguem à risca”;
• O time aguarda dizermos o próximo passo;
• O time só produz com o microgerenciamento e quando impõem-se datas às demandas;
• O daily acontecer apenas se o Scrum Master estiver presente.

É muito comum em empresas que estão em processo de transformação ágil a gestão “exigir” do Scrum Master o “relatório” do que cada membro do time está fazendo no dia.

CUIDADO, essas são algumas armadilhas que estão presentes em equipes (não times) com baixo nível de confiança.

É função sua (Scrum Master) trabalhar com sua gestão para ensiná-la que em ambientes ágeis as pessoas:Constroem projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiança que farão o seu trabalho. (5º princípio do Manifesto Ágil).

2 – Scrum Master NÃO DELEGA tarefas

Existe uma dificuldade com times que estão iniciando na prática Scrum ter a proatividade de dizer “deixa que essa ou aquela demanda eu pego para fazer” e nós como Scrum Master somos “tentados” a determinar o que cada um dos membros do time devem “atacar” afinal, “entregar a Sprint” é a nossa responsabilidade não é?

Muito cuidado quando essas “vozes de chefe” gritarem na sua mente, aproveite a oportunidade para ensinar ao time que eles são os donos do Sprint Backlog e os responsáveis por transformá-lo em entregáveis e que o exercício dessa responsabilidade começa com a proatividade de escolha de uma demanda mais prioritária.

Dica: Se o Time tem dificuldade de definir o que deve ser iniciado primeiro, melhore o Sprint Planning, talvez o time está saindo da cerimônia sem o Objetivo da Sprint está claro para todos e como este objetivo será alcançado.

3 – Scrum Master NÃO ESTIMA e NÃO DIZ COMO ALGO TEM QUE SER FEITO

Sim, eu também já levantei a cartinha do planning poker durante a cerimônia de planejamento até que um membro do time me lançou a seguinte questão: Scrum Master também estima?

Sim, se o mesmo também fizer parte do Time de desenvolvimento, o que não era meu caso na época!

Dica: No lugar de tentar exercer o papel de Time de desenvolvimento, experimente ajudar o time a melhorar a estimativa e o padrão de tamanho de histórias que entram no fluxo de trabalho, isso poderá te dar uma uniformidade no Leadtime e, consequentemente, o time terá mais previsibilidade quanto às entregas.

Segundo o Scrum Guide: O Time de desenvolvimento é auto-organizado e ninguém (nem mesmo o Scrum Master) diz a eles como transformar o Backlog do Produto em incrementos de funcionalidades potencialmente liberável.

4 – Scrum Master NÃO FORÇA O TIME

“O projeto está atrasado, temos que entregar mais pontos ou histórias”, “sei que estamos no meio da Sprint, mas preciso que você inclua mais essas funcionalidades para a próxima review”.

Quem nunca ouviu essas palavras no momento quem que o projeto está “pegando fogo”. Já ouvi um caso de “Scrum Masters” que realizaram a estimativa das histórias por conta própria, sem consultar o Time de desenvolvimento e enviou para o Gerente de Projetos e depois trabalhou com o chicote forçando o Time de Desenvolvimento a entregar porque ele (Scrum Master) já havia se comprometido. Sim, isso é real e mais comum do que imaginamos!

Sim, sei que existe uma tendência natural à busca do conforto, sendo assim, “naturalmente”, times de desenvolvimento tendem àquela “gordurinha” nas estimativas para que venham a se comprometer com menos histórias.

Isso é característica de Times com falta de comprometimento, fuga de responsabilidade e com desatenção aos resultados.

Seu papel como Scrum Master não é “empurrar goela abaixo” uma pontuação mínima para a sprint ou uma quantidade X de histórias a atacar.

Esse é o momento de exercer a liderança, puxar o Time para a realidade e as consequências para o negócio de uma não entrega, encorajar ao Time a ousar e/ou sair da zona de conforto.

Isso não é fácil de fazer, mas é o necessário e é seu papel, caso você não queira uma equipe ressentida com o Scrum Master que a “forçou” a se comprometer com o que ela não estava disposta!

Quer gerenciar alguma coisa? Gerencie seu estoque. Gente não se gerencia, lidera-se.” Ross Perot

Se o projeto está atrasado, seu papel é ensinar ao Time a levar este ponto para a Retrospectiva e entenderem juntos os motivos do problema.

Isso fará com que o Time melhore o processo e encontre uma solução para uma negociação de escopo mantendo ainda o valor para o negócio, o importante é descobrirem juntos como saírem da crise!

Por fim… Desculpem o desabafo, mas, este é um sinal de alerta para puxarmos o “freio de mão” e repensarmos sobre as atitudes tomadas durante o dia-a-dia nas sprints.

Eu gostaria de saber o que você tem visto acontecer que, na sua visão, não é papel do Scrum Master, abra o coração! 🙂

Um forte abraço e seja ágil!