Scrum Master é um nome que sugere ser o guardião do processo Scrum. Ele é um agente de mudança que apoia sua equipe ao mesmo tempo em que ensina e socializa o Scrum por toda a organização. Ele garante o bom andamento das atividades da equipe erradicando os impedimentos e mantendo a equipe protegida de distrações externas. Entretanto, em certos cenários, equipes ágeis sentem que o Scrum Master em si é o maior impedimento.
Siddharta descreveu um cenário, que ele acreditar prevalecer em equipes offshore devido à cultura hierarquizada e à estratégia de comunicação tradicionalista. Aqui, o Scrum Master acaba se tornando um gargalo entre a equipe e o cliente.
Segundo Siddharta,
Muitas equipes não possibilitam acesso dos membros do time ao cliente ou mesmo ao Product Owner (especialmente se estes não estão fisicamente disponíveis, mas apenas remotamente). Assim, o fluxo de informação é algo como
Você <-> ScrumMaster <-> Product Owner <-> Cliente
Tobias Mayer reagiu a isto sugerindo que se o Scrum Master estiver se tornando um intermediário para a equipe, então a causa do problema é outra.
[Isto é] um estilo simplificado de comando e controle. Chamar alguém de Scrum Master não faz dele um verdadeiro Scrum Master, especialmente se ele estiver profundamente impregnado com o "pensamento arcaico" e não teve treinamento para mudar essa mentalidade.
Jaibeer Malik, compartilha do argumento de Tobias quando menciona que a causa parece se a maneira como Agile está sendo implementada e seguida.. Ele ressalta que a comunicação é a questão fundamental de um processo ágil e que todos os membros da equipe devem ser capazes de se comunicar com qualquer pessoa da equipe sem o intermédio do Scrum Master.
Já Roberto Fasciolo apontou outras razões pelas quais os ScrumMasters estão caindo nos velhos problemas do pensamento tradicional. Ele observou as seguintes armadilhas,
- Scrum Master se comprometendo com o sprint backlog – Isto ocorre particularmente quando o Scrum Master é também um membro da equipe. O time simplesmente aceita o que ele tem a dizer.
- Scrum Master indicando ao time sobre o que fazer ao invés de orientar a auto-organização – Isto acontece muitas vezes quando o Scrum Master é um ex gerente de projetos. O efeito disto é que o time pode se tornar completamente dependente de seu Scrum Master.
- Scrum Master agindo como um proxu entre o time e o Product Owner – – Isto é semelhante ao cenário descrito por Siddharta e é prevalente em equipes offshore distribuídas.
Mike Cottmeyer complementa que se o Scrum Master estiver apenas mantendo registro de impedimentos, então ele é o impedimento. Um bom Scrum Master não deve apenas ser capaz de registrar e remover impedimentos, mas também deve ser um Antecipador que pode antever os problemas e trabalhar com o time para não permitir que as coisas deem errado.
Cesario Ramos descreveu uma situação interessante na qual o Scrum Master também está tão envolvido com o time que suas próprias tarefas de Scrum Master se tornam um impedimento por estarem no caminho crítico.
A questão aqui é que o Scrum Master está fazendo tarefas de projeto “de valor”. Ele ou ela está tentando fazer coisas de que os outros membros da equipe dependem para fazer suas tarefas. Isto pode até chegar ao ponto em que o Scrum Master sente que não conseguirá ter uma sprint concluída sem que ele/ela busque remover todas estas tarefas importantes/difíceis.
Boris Gloger, também tem uma história parecida para contar quando fala que o SM de Scrum Master não significa (S)uper (M)an. Um Scrum Master que não esteja fazendo seu papel adequadamente ou que esteja tentando incorporar múltiplos papéis além de seu papel principal é, na verdade, um impedimento para o time.
Por isso, há muitas situações em que um Scrum Master pode impedir, conscientemente ou não, as atividades do time. A chave aqui está em identificar estas situações o mais cedo possível e tomar as ações corretivas enquanto ainda há esperança para o projeto.