O que é Scrum Master?

O papel de Scrum Master existe desde a primeira formulação do Scrum, por Ken Schwaber e Jeff Sutherland, apresentada em 1995 e detalhada nas versões do Scrum Guide a partir de 2010. Desde o início, o papel foi desenhado como um facilitador e guardião do processo, não como um gerente que distribui tarefas.

A definição de responsabilidade do Scrum Master mudou ao longo das revisões do Scrum Guide. A versão de 2020 simplificou a redação, afirmando que o Scrum Master é responsável pela eficácia do Time Scrum, e detalhou como esse papel serve o Time Scrum, a organização e o Product Owner de formas distintas, deixando mais claro que a atuação vai além de facilitar reuniões.

O conceito de liderança servidora, central para o papel, vem de fora do Scrum: foi cunhado por Robert Greenleaf no ensaio "The Servant as Leader", de 1970, décadas antes do Scrum existir, e foi incorporado ao framework como a postura esperada de quem exerce o papel.

Um jeito simples de entender o papel: o Product Owner decide o quê construir, os Desenvolvedores decidem como construir, e o Scrum Master cuida de como o time trabalha junto. O Scrum Guide 2020 organiza essa atuação em três frentes:

Servindo ao Time Scrum. Facilita os eventos quando necessário ou solicitado, treina o time em auto-organização e multifuncionalidade, e ajuda o time a criar produtos de alto valor. Remove impedimentos ao progresso do time, sejam eles técnicos, organizacionais ou interpessoais.

Servindo ao Product Owner. Ajuda a encontrar técnicas para gestão eficaz da Meta do Produto e do Product Backlog, ajuda o time a entender a necessidade de itens claros e concisos, e facilita o planejamento estratégico de produto em ambientes complexos.

Servindo à organização. Lidera, treina e orienta a organização na adoção do Scrum, planeja implementações dentro da organização, e trabalha com outros Scrum Masters para aumentar a eficácia da aplicação do Scrum na empresa como um todo.

O exercício mais prático desse papel costuma se ver naquilo que o Scrum Master não faz. Ele não é o Product Owner do time, mesmo que pareça mais fácil acumular os dois papéis. Não é chefe nem líder técnico, e não decide o que o time constrói ou como constrói. Não cobra o Time Scrum pelas entregas no fim de cada Sprint, papel que na verdade cabe à Sprint Review, um espaço de inspeção conjunta, não de prestação de contas individual. E não é um intermediário que leva e traz mensagens entre PO e Desenvolvedores: sua função é ajudar as duas partes a se comunicarem diretamente, não substituir essa comunicação.

A ferramenta É / Não É / Faz / Não Faz. Criada por Rafael Sabbagh, essa é uma forma simples de deixar claro para a organização o que esperar do papel, evitando as expectativas mais comuns e mais equivocadas, como achar que o Scrum Master é responsável por garantir prazo.

Scrum Master não é uma posição fixa para sempre. Em times maduros, com anos de prática e alto grau de auto-organização, a facilitação dos eventos pode passar a rodar entre membros do time, com o Scrum Master atuando mais na dimensão organizacional do que na condução dia a dia das cerimônias. O Scrum Guide já prevê isso ao dizer que o Scrum Master facilita eventos quando necessário ou solicitado, não obrigatoriamente sempre.

Trabalhe com impedimentos sistêmicos. Um bloqueio recorrente pode nascer de política de aprovação, metas conflitantes ou dependência entre áreas, e não de falta de esforço do Time Scrum. O Scrum Master ajuda a tornar o padrão visível, reúne as pessoas que podem mudá-lo e acompanha o efeito da decisão. Isso difere de resolver pessoalmente cada ticket para que o time continue dependente dele. Ao facilitar uma Retrospectiva, pode ajudar o grupo a separar o que controla, o que influencia e o que precisa de ação organizacional. Ao apoiar o Product Owner, pode melhorar colaboração com stakeholders e clareza do Product Backlog; ao apoiar Developers, pode desenvolver autogestão e colaboração entre especialidades. Seu sucesso não se mede pelo número de reuniões conduzidas ou tarefas cobradas. Observe se o time identifica riscos cedo, adapta o trabalho e entrega Incrementos prontos com menos impedimentos repetidos.

Imagine um time construindo o sistema de check-in de uma companhia aérea, em Sprints de duas semanas. No terceiro dia da Sprint, um Desenvolvedor menciona na Daily Scrum: "estou esperando acesso ao ambiente de homologação há dois dias, abri chamado, ninguém respondeu".

O Scrum Master não delega isso de volta ao Desenvolvedor com um "tenta de novo". Depois da Daily, ele investiga: descobre que o chamado caiu numa fila compartilhada com dezenas de outros times, sem prioridade. Ele contata diretamente o responsável pela área de infraestrutura, explica o impacto (a Meta da Sprint depende desse acesso), e negocia uma liberação em algumas horas, não dias.

Na Retrospectiva seguinte, ele traz o padrão: esse não foi o primeiro chamado que travou naquela fila. Propõe ao time discutir uma solução estrutural, como um canal direto com a infraestrutura para pedidos que bloqueiam Sprint em andamento. O time concorda, e o Scrum Master leva essa proposta para a conversa com outros Scrum Masters da organização, já que o problema provavelmente afeta outros times também, e vale mais resolver uma vez para todos do que cada Scrum Master negociar a mesma fila separadamente.

Repara no que ele fez: resolveu o impedimento imediato, mas também tratou a causa, em vez de deixar o mesmo problema se repetir Sprint após Sprint. Essa dupla atuação, no time e na organização, é o que separa um Scrum Master eficaz de alguém que só marca as reuniões do calendário.

Repara também no que ele não fez: não resolveu o problema técnico do sistema de homologação, porque não era um problema técnico, era um problema de fila e priorização entre áreas. Não repreendeu o Desenvolvedor por não ter escalado antes, porque isso ensinaria o time a esconder bloqueios em vez de trazê-los cedo. E não prometeu, sozinho, que aquilo nunca mais aconteceria, porque a solução estrutural depende de gente fora do seu controle direto. No fim das contas, o que mais separa um Scrum Master eficaz de um passivo é essa disposição de investigar além do sintoma que apareceu na Daily, e de levar o padrão encontrado para quem pode mudar a causa, mesmo quando isso significa sair da zona de conforto do próprio time.

Em times pequenos e organizações no início da jornada ágil, a mesma pessoa costuma acumular Scrum Master e Agile Coach informalmente. À medida que a organização cresce, os papéis tendem a se separar: o Scrum Master fica com o time, e o Agile Coach cuida da transformação em vários times e níveis da organização. Já o Gerente de Projetos tradicional raramente convive bem com o Scrum Master no mesmo time: os dois papéis competem pela mesma responsabilidade de coordenar o trabalho, um pela via da autoridade formal, o outro pela via da facilitação e da auto-organização.

Cursos K21 recomendados