Time Scrum: quem faz o quê e por que a maioria dos times erra isso

Pergunte a dez pessoas de uma empresa quem faz parte do time Scrum e você vai ouvir dez respostas diferentes. Alguém vai incluir o gerente de projetos. Alguém vai deixar o Product Owner de fora, porque “ele é do negócio”. Alguém vai dizer que o time é só quem programa.

Essa confusão não é detalhe de vocabulário. Ela é a raiz de quase todo time ágil que entrega devagar, e eu já vi isso acontecer em banco, em indústria e em startup, sempre pelo mesmo motivo.

O time Scrum é um só

Desde 2020 o Guia do Scrum deixou de falar em “time de desenvolvimento dentro do time Scrum” e passou a falar em um único Scrum Team. A mudança parece cosmética e não é. Ela acabou com a ideia de que existe um grupo que decide e outro que executa.

O time Scrum tem no máximo dez pessoas e três responsabilidades:

• Product Owner, uma pessoa
• Scrum Master, uma pessoa
• Developers, todo mundo que faz o trabalho de construir o incremento

Não existe chefe do time Scrum. Não existe subtime. Não existe uma camada de aprovação interna. O time é responsável, junto, por entregar um incremento útil a cada Sprint.

Product Owner: quem responde pelo valor

O Product Owner é uma pessoa, não um comitê. Isso está no Guia com todas as letras e é a regra mais desrespeitada em empresa grande, onde o PO precisa validar cada decisão com três áreas antes de ordenar o backlog.

A responsabilidade dele é maximizar o valor do que o time entrega. Na prática, isso significa: definir o Objetivo do Produto, criar e ordenar os itens do Product Backlog, e garantir que o backlog é transparente e entendido por todos.

O PO pode delegar o trabalho de escrever itens. O que ele não pode delegar é a decisão de ordem. Se outra pessoa reordena o backlog por cima dele, o time inteiro aprende que o PO não decide nada, e passa a negociar por fora.

Um sinal de que o PO não está funcionando: o time descobre a prioridade no planejamento da Sprint, não antes.

Scrum Master: quem cuida do sistema, não das pessoas

O Scrum Master é a figura mais mal compreendida do Scrum. Em muitas empresas ele virou secretário de reunião, ou pior, virou o gerente com nome novo, cobrando data de entrega na daily.

A responsabilidade real é a eficácia do time. Isso quer dizer ajudar o time a melhorar a prática, remover impedimentos que o time não consegue remover sozinho, e proteger o foco da Sprint. E também, e isso quase ninguém faz, trabalhar a organização em volta, para que ela pare de criar os impedimentos.

Scrum Master que só facilita cerimônia está fazendo um quarto do trabalho. O resto acontece fora do time, conversando com quem cria as regras que travam a entrega.

Developers: quem constrói, e quem decide como

Developers, no Scrum, não quer dizer programadores. Quer dizer todas as pessoas que criam qualquer aspecto do incremento a cada Sprint. Analista, tester, designer, redator técnico, quem for necessário.

Eles são responsáveis por criar o plano da Sprint, aderir à Definição de Pronto, ajustar o plano todo dia rumo ao Objetivo da Sprint e se responsabilizar uns pelos outros como profissionais.

Repare no verbo: eles criam o plano. Ninguém entrega o Sprint Backlog pronto para o time executar. Quando isso acontece, o time perde o único mecanismo que faz a estimativa melhorar com o tempo, que é errar a própria previsão e aprender com ela.

Os erros que quebram o time antes da terceira Sprint

O time é multifuncional no organograma, não na prática. Tem tester no time, mas o ambiente de homologação depende de um chamado para outra área que leva cinco dias. O time não é autossuficiente, e nenhuma cerimônia conserta isso.

Pessoas alocadas em três times ao mesmo tempo. Um profissional a 30% em três produtos não entrega 90%, entrega bem menos, porque troca de contexto custa caro. Time Scrum pressupõe dedicação, e dedicação é decisão de gestão, não de metodologia.

Gerente de projetos e Scrum Master convivendo sem acordo. Não é que um exclua o outro. É que, sem combinar quem decide o quê, o time recebe duas prioridades diferentes na mesma semana e escolhe obedecer a quem faz a avaliação de desempenho.

Time grande demais. Acima de dez pessoas a comunicação vira o gargalo. Se o produto exige mais gente, são dois times com um Product Backlog só, não um time de dezoito.

Como saber se o seu time Scrum é um time de verdade

Faça essas quatro perguntas na próxima retrospectiva. As respostas dizem mais que qualquer avaliação de maturidade ágil:

1. Se um item da Sprint atrasar, o time consegue resolver sozinho ou depende de alguém de fora
2. Todo mundo sabe dizer o Objetivo desta Sprint sem consultar a ferramenta
3. Quando duas prioridades entram em conflito, existe uma pessoa que decide, e o time sabe quem é
4. Na última Sprint, alguma decisão do time foi revertida por alguém que não estava no time

Se as respostas forem desconfortáveis, o problema não é a cerimônia, é o desenho do time. E esse é um problema de gestão, resolvido com conversa e com dado, não com mais uma ferramenta.

Para levar essa conversa para quem cobra resultado, ajuda ter número na mão: capacidade real do time, alocação, lead time, o que entrou e o que saiu da Sprint. Eu reuni os modelos que uso para isso, prontos para preencher, no MASP, Modelos para Acelerar o Seu Projeto.

Alcione Nunes é PMP certificada desde 2015, Mentora de Gestão de Projetos com mais de 20 anos de experiência corporativa. Criadora do Método MERCC e fundadora do CLAAN — a comunidade de profissionais que decidiram que salário não é teto, é piso.