PMO e Inteligência
Domingo, 08 de junho de 2025
Scrum Master: o que é, o que faz e quais são suas responsabilidades
Acredito que a transição do Waterfall para métodos ágeis trouxe melhorias reais para o desenvolvimento de software. Ciclos menores de entrega, feedback mais rápido, maior proximidade entre negócio e tecnologia e mais autonomia para os times resolveram problemas que projetos tradicionais carregaram durante anos.
Isso não significa, porém, que tudo o que existia antes tenha desaparecido. Às vezes tenho a impressão de que o Agile é tratado quase como se tivesse inventado uma nova realidade empresarial. Mudamos os nomes, dividimos o trabalho em ciclos menores, criamos novos eventos e distribuímos algumas responsabilidades, mas custos continuam existindo, riscos continuam existindo, stakeholders continuam existindo, prazos continuam existindo e alguém continua tendo de explicar para a diretoria por que uma entrega que deveria acontecer em março agora vai acontecer em junho.
E é justamente nesse ponto que um dos papéis mais curiosos do Scrum entra na conversa: o Scrum Master.
Não porque o papel não tenha importância. Tem. O problema é que existe uma distância enorme entre o que é um Scrum Master segundo o framework, o que faz um Scrum Master na prática e o que muitas empresas começaram a esperar dessa pessoa depois que decidiram que não precisavam mais de um gerente de projetos.
E foi aí que, na minha opinião, começamos a criar uma confusão bastante conveniente.
O que é Scrum Master?
O Scrum Master é uma das responsabilidades definidas pelo Scrum e tem como principal objetivo ajudar o Scrum Team e a organização a compreender e aplicar o framework de maneira efetiva.
Ele não deveria ser o chefe do time, não distribui tarefas como um gerente tradicional e não deveria funcionar como uma espécie de fiscal da Daily Scrum. Seu trabalho está muito mais relacionado a facilitar a adoção do Scrum, apoiar a auto-organização do time, ajudar a remover impedimentos e contribuir para que o Scrum Team se torne mais efetivo.
Essa distinção é importante porque existe uma tendência curiosa no mercado: algumas empresas adotam Scrum, retiram o gerente de projetos da estrutura e, algumas semanas depois, começam a perguntar ao Scrum Master sobre orçamento, cronograma, riscos, dependências, fornecedores, stakeholders, capacidade, previsibilidade e relatórios executivos.
Ou seja: retiramos o gerente de projetos, mas aparentemente esquecemos de retirar os problemas que ele gerenciava.
O que faz um Scrum Master?
Quando alguém me pergunta o que faz um Scrum Master, a resposta parece simples até começarmos a olhar para o que acontece nas empresas.
Dentro do Scrum, o papel envolve ajudar o time a trabalhar melhor dentro do framework. Isso passa por apoiar a auto-organização, melhorar a efetividade do time, ajudar na remoção de impedimentos, garantir que os eventos do Scrum sejam produtivos e colaborar com Product Owner, Developers e organização na adoção das práticas.
O problema começa quando transformamos “remover impedimentos” em uma espécie de categoria universal onde colocamos qualquer coisa que ninguém sabe para quem atribuir.
O fornecedor atrasou? Scrum Master.
O stakeholder está pressionando? Scrum Master.
A sprint está comprometida? Scrum Master.
O orçamento está estourando? Alguém chama o Scrum Master.
O diretor quer saber quando o projeto termina? Adivinhe quem acaba preparando a apresentação.
Em algum momento, “facilitar o Scrum e aumentar a efetividade do time” começa a se transformar silenciosamente em “cuide de tudo o que está atrapalhando o projeto”.
E isso já se parece bastante com outra profissão que conhecemos há décadas.
Quais são as responsabilidades do Scrum Master?
As responsabilidades do Scrum Master estão relacionadas à aplicação do Scrum e à efetividade do Scrum Team. De forma prática, podemos resumir boa parte do papel em atividades como:
- Ajudar o time a compreender e aplicar Scrum.
- Apoiar a auto-organização e a atuação multidisciplinar do time.
- Ajudar na remoção de impedimentos que prejudiquem o progresso.
- Apoiar Product Owner e Developers na utilização adequada do framework.
- Contribuir para que os eventos do Scrum sejam produtivos e tenham propósito.
- Trabalhar com a organização para melhorar a adoção do Scrum.
- Ajudar o Scrum Team a aumentar continuamente sua efetividade.
Perceba o que não aparece naturalmente nessa definição: gerenciar orçamento do projeto, controlar contrato, administrar fornecedores, consolidar riscos corporativos, controlar um cronograma global, responder por margem financeira ou produzir reporting executivo para o board.
Isso não significa que essas atividades deixaram de existir.
Significa apenas que o Scrum não colocou essas responsabilidades no Scrum Master.
E essa pequena diferença produz uma quantidade impressionante de problemas organizacionais.
Scrum Master é um gerente de projetos?
Não. Pelo menos não segundo o Scrum.
Essa resposta precisa estar clara porque dizer simplesmente que Scrum Master e gerente de projetos são a mesma coisa seria tecnicamente errado.
O Scrum Master trabalha sobre o framework e sobre a efetividade do Scrum Team. Um gerente de projetos, dependendo da organização e do modelo de gestão utilizado, pode ter responsabilidade muito mais ampla por cronograma, orçamento, riscos, comunicação, fornecedores, escopo, stakeholders, governança, dependências e resultado global do projeto.
Mas agora vem a parte que considero muito mais interessante:
o fato de os papéis serem diferentes no papel não significa que continuem diferentes dentro das empresas.
Já vi Scrum Masters acompanhando riscos, preparando relatórios executivos, negociando dependências entre equipes, coordenando fornecedores, pressionando entregas, acompanhando custos, respondendo perguntas de stakeholders e tentando prever quando uma iniciativa terminaria.
Em outras palavras, executando uma quantidade bastante razoável de atividades que, alguns anos antes, provavelmente estariam com um gerente de projetos.
Scrum Master vs gerente de projetos: qual é a diferença?
A comparação entre Scrum Master e gerente de projetos fica muito mais fácil quando deixamos de olhar apenas para cerimônias e começamos a olhar para accountability.
O gerente de projetos normalmente existe porque alguém precisa olhar para o projeto como um sistema inteiro. Há orçamento, prazo, escopo, riscos, pessoas, fornecedores, dependências, qualidade, expectativas e diferentes grupos tentando puxar o projeto para direções diferentes.
O Scrum Master, por outro lado, não é definido pelo Scrum como responsável por gerenciar todo esse sistema. Seu foco é ajudar o Scrum Team e a organização a trabalhar de maneira mais efetiva dentro do framework.
E aqui surge a pergunta que, para mim, muitas implementações de Agile nunca responderam adequadamente:
se removemos o gerente de projetos, quem passou a gerenciar tudo aquilo que não desapareceu com ele?
Às vezes a resposta é um Program Manager. Em outras empresas, um Delivery Manager. Pode ser um Engineering Manager, Product Manager, PMO ou outra função.
Isso é perfeitamente possível.
O problema aparece quando a empresa não dá essa responsabilidade formalmente para ninguém e espera que ela seja absorvida informalmente pelo Scrum Master.
O Scrum eliminou o gerente de projetos, mas não eliminou a gestão
Essa é provavelmente a parte mais provocativa da minha opinião sobre o assunto.
Vejo empresas discutindo há anos se precisam ou não de gerentes de projetos em ambientes Agile, como se a decisão de retirar um cargo de um organograma tivesse algum poder mágico sobre os problemas reais do negócio.
Você pode retirar o gerente de projetos.
O custo continua existindo.
Você pode retirar o gerente de projetos.
O stakeholder continua perguntando quando a entrega estará pronta.
Você pode retirar o gerente de projetos.
O fornecedor continua atrasando.
Você pode retirar o gerente de projetos.
O risco continua se materializando.
Você pode retirar o gerente de projetos.
O CFO continua querendo saber por que já consumimos 80% do orçamento e entregamos 50% do esperado.
O que desapareceu foi o cargo.
A necessidade de gestão continuou exatamente onde estava.
E então o Scrum Master começa a virar gerente de projetos
É aqui que aquela frase provocativa que deu origem à primeira versão deste artigo começa a fazer sentido.
Não estou dizendo que Scrum Master é gerente de projetos.
Estou dizendo que algumas empresas eliminam uma função e começam, pouco a pouco, a empurrar partes dessa função para outra pessoa.
Primeiro, o Scrum Master apenas ajuda com um impedimento.
Depois, começa a acompanhar uma dependência externa.
Em seguida, alguém pede para atualizar um status.
Logo está falando com stakeholders.
Depois aparece uma planilha de riscos.
Então alguém pede previsão de entrega.
Quando percebe, aquela pessoa que deveria ajudar o time a utilizar Scrum está fazendo coordenação de delivery, gestão de riscos, comunicação executiva, acompanhamento de cronograma e parte da gestão de stakeholders.
Só que sem necessariamente ter recebido treinamento para isso, autoridade para isso ou reconhecimento formal por isso.
É nesse ponto que dizer “somos Agile, não precisamos de gerente de projetos” deixa de parecer uma transformação organizacional e começa a parecer apenas uma redistribuição silenciosa de trabalho.
O problema não é pedir mais ao Scrum Master
Quero deixar uma coisa clara: eu não vejo problema em um Scrum Master desenvolver competências de gestão de projetos, delivery, riscos ou stakeholders.
Na verdade, considero essas competências extremamente úteis.
O problema é outro.
É contratar alguém para uma função, explicar que seu papel será um e depois cobrar silenciosamente outro completamente diferente.
Se a empresa precisa que aquela pessoa gerencie cronograma, orçamento, riscos, fornecedores, dependências e reporting executivo, então talvez seja hora de reconhecer que aquela função deixou de ser apenas Scrum Master.
Podemos chamar de Delivery Manager, Project Manager, Program Manager ou qualquer outro nome que faça sentido para a estrutura.
O nome é a parte menos importante.
O que importa é deixar claro quem possui responsabilidade, autoridade e competência para fazer o trabalho.
Menos autoridade, mas as mesmas cobranças
Há outro efeito que considero ainda mais perigoso: cobrar resultado de uma pessoa que não possui autoridade suficiente para influenciá-lo.
Imagine um Scrum Master sendo questionado pelo atraso de uma iniciativa que depende de quatro outras equipes, dois fornecedores, orçamento controlado por outra área e prioridades decididas por executivos aos quais ele nem sequer tem acesso direto.
A pessoa pode facilitar quantas Daily Scrums quiser. O problema continuará existindo.
Quando responsabilidade e autoridade não caminham juntas, criamos uma função condenada a negociar tudo e decidir quase nada.
E depois chamamos isso de accountability.
Não é.
É apenas transferência de cobrança.
Quem gerencia custos, riscos, cronograma e stakeholders?
Essa é a pergunta que considero mais importante do que discutir se Scrum Master substitui ou não gerente de projetos.
Não me interessa tanto o nome do cargo.
Quero saber quem está olhando para o dinheiro. Quem está acompanhando riscos. Quem entende dependências entre equipes. Quem consegue perceber que uma sequência de pequenos atrasos provavelmente vai comprometer uma entrega daqui a três meses. Quem está conversando com stakeholders. Quem está comparando o que planejamos com o que realmente estamos entregando.
Se a resposta for “ninguém, porque o time é auto-organizado”, temos um problema.
Auto-organização é extremamente importante para definir como o trabalho será executado pelo time.
Mas auto-organização não faz desaparecer governança, restrições financeiras, contratos, dependências organizacionais ou compromissos assumidos com clientes.
Um burndown não administra uma empresa
Um dos meus problemas com algumas implementações de Agile é a redução exagerada da gestão a algumas métricas de sprint.
Velocity é útil. Burndown pode ser útil. Sprint Goal é importante. Retrospectivas são importantes.
Mas nenhuma dessas coisas responde sozinha a perguntas como:
Quanto este projeto já custou? Qual área está consumindo mais orçamento? Quais profissionais ou equipes estão produzindo mais rework? Quais riscos estão aumentando? Estamos entregando proporcionalmente ao dinheiro consumido? Qual dependência pode comprometer nosso cronograma? Nossa produtividade está melhorando ou piorando?
Executivos continuam precisando dessas respostas independentemente de o time trabalhar com Scrum, Kanban, SAFe, Waterfall ou qualquer combinação entre eles.
Um framework de desenvolvimento não substitui inteligência de gestão.
É aqui que entra o Saint Jude
Essa lacuna de visibilidade é uma das razões pelas quais criamos o Saint Jude Project Intelligence .
Quando uma empresa utiliza Jira, Azure DevOps, Asana, monday.com ou ClickUp, uma enorme quantidade de informação sobre execução já está sendo produzida todos os dias. O problema é que normalmente ela continua espalhada entre boards, dashboards, planilhas, apresentações e interpretações diferentes de cada gestor.
O Saint Jude utiliza esses dados para criar uma camada de inteligência sobre projetos, permitindo analisar cronograma, custos, produtividade, performance, riscos, estimativas, qualidade das atividades, comportamento das sprints e outros sinais que ajudam PMOs e lideranças a entender o que realmente está acontecendo.
A ideia não é transformar o Scrum Master novamente em gerente de projetos.
É justamente o contrário.
Quanto mais informação de gestão puder ser estruturada automaticamente a partir dos dados que já existem, menor é a necessidade de alguém passar parte da semana coletando informação manualmente para criar relatórios que estarão desatualizados no dia seguinte.
Então, afinal, qual é o papel do Scrum Master?
O papel do Scrum Master faz sentido quando permitimos que ele seja aquilo que deveria ser: alguém que ajuda o Scrum Team e a organização a trabalhar melhor dentro do Scrum.
O problema começa quando decidimos que o gerente de projetos ficou ultrapassado, removemos a função e simplesmente assumimos que todas as responsabilidades associadas à gestão desapareceram junto com o cargo.
Não desapareceram.
Alguém continuará cuidando delas. Talvez um PMO. Talvez um Delivery Manager. Talvez um Program Manager. Talvez um Engineering Manager. Talvez ferramentas e automações consigam assumir uma parte.
Ou talvez, sem perceber, a empresa coloque tudo isso nas costas do Scrum Master.
E é nesse último cenário que minha provocação continua válida:
em muitas empresas, o Scrum Master não virou oficialmente um gerente de projetos. Ele apenas recebeu uma quantidade crescente de responsabilidades de gestão sem que ninguém tivesse coragem de admitir que gestão de projetos ainda era necessária.
O problema nunca foi o Scrum Master.
O problema é acreditar que mudar o nome dos papéis faz custos, riscos, prazos, dependências e stakeholders desaparecerem.
Não faz.
E você, o que pensa sobre isso? Na empresa em que trabalha, o Scrum Master exerce apenas as responsabilidades previstas pelo Scrum ou acabou absorvendo parte do trabalho que antes pertencia à gestão de projetos?
Até breve!
Erik Scaranello
