Origem do Scrum: do rugby ao gerenciamento de projetos
Scrum, rugby e gestão de projetos parecem assuntos sem relação, até você ver uma formação de scrum em campo: dezesseis jogadores agarrados uns aos outros, empurrando em bloco, disputando uma bola que ninguém consegue levar sozinho. Foi essa imagem que dois professores japoneses usaram em 1986 para descrever as equipes de desenvolvimento de produto mais rápidas que tinham estudado, e foi dela que saiu o nome de um dos frameworks ágeis mais conhecidos.
Conhecer essa origem não é curiosidade de almanaque. A metáfora explica por que o Scrum insiste em um time só, multifuncional e responsável pelo resultado inteiro, e por que ele funciona mal quando a empresa o encaixa numa estrutura de etapas e repasses.
Formação relacionada
Papéis, eventos, práticas e ciclo de vida do Scrum, com preparação para o exame ASF.
O que é scrum no rugby
No rugby union, o scrum é a formação usada para reiniciar o jogo de forma rápida, segura e justa depois de uma infração leve ou de uma parada. Os casos mais comuns são quando um jogador derruba a bola para a frente ou faz um passe para a frente, o que é proibido no rugby.
A formação funciona assim:
- Oito jogadores de cada time se agrupam em três linhas. A primeira linha tem três jogadores, a segunda tem dois e a terceira fecha o bloco.
- As primeiras linhas se encaixam, com as cabeças intercaladas, e formam um túnel entre os dois times.
- O scrum-half lança a bola no túnel e os jogadores da primeira linha disputam a posse com os pés, enquanto os dois blocos empurram.
- A bola sai por trás do bloco e o jogo continua.
A palavra é a forma curta de scrummage, termo mais antigo para a mesma formação. O que importa para a gestão é o desenho: ninguém avança sozinho, cada posição tem uma função, mas o resultado só aparece se o grupo empurra junto.
Takeuchi e Nonaka: do campo para o desenvolvimento de produtos
A ponte entre o esporte e a gestão é o artigo The New New Product Development Game, de Hirotaka Takeuchi e Ikujiro Nonaka, publicado na Harvard Business Review em janeiro de 1986. Os autores estudaram empresas do Japão e dos Estados Unidos, fabricantes de áreas como automóveis, copiadoras e impressoras, que tinham ganhado velocidade e flexibilidade no lançamento de produtos novos.
O contraste do artigo é entre duas imagens:
- A corrida de revezamento. O modelo sequencial: cada área faz sua parte (conceito, projeto, protótipo, produção) e passa o bastão para a próxima. Cada repasse cria espera, perda de informação e retrabalho.
- O rugby. Um time só, com todas as especialidades, avança junto pelo campo e passa a bola de um para outro conforme a jogada pede. As fases se sobrepõem em vez de esperar uma pela outra.
Os autores descreveram seis características dessa abordagem: instabilidade embutida (a direção dá um objetivo desafiador e amplo, não um plano detalhado), equipes de projeto auto-organizadas, fases de desenvolvimento sobrepostas, aprendizado múltiplo, controle sutil e transferência do aprendizado para o resto da organização. Uma das seções do texto fala justamente em levar o scrum campo acima.
Repare que o artigo de 1986 não descreve o framework Scrum. Ele não tem Sprint, Product Owner nem Daily. Ele oferece a metáfora e um conjunto de observações sobre equipes que funcionavam bem.
Do artigo ao framework: Schwaber e Sutherland
No início dos anos 1990, dois caminhos paralelos levaram a metáfora para o software. Ken Schwaber aplicava na sua empresa, a Advanced Development Methods, o que viria a ser o Scrum. Jeff Sutherland, com John Scumniotales e Jeff McKenna, desenvolvia uma abordagem parecida na Easel Corporation, e a equipe a batizou de scrum, em referência ao artigo de Takeuchi e Nonaka.
Daí em diante, a linha do tempo fica assim:
| Ano | Marco |
|---|---|
| 1986 | Artigo de Takeuchi e Nonaka na Harvard Business Review, com a metáfora do rugby |
| Início dos anos 1990 | Schwaber e Sutherland aplicam o Scrum em suas empresas |
| 1995 | Os dois apresentam o Scrum juntos na conferência OOPSLA, a primeira definição pública formal |
| 2001 | Publicação do Manifesto para Desenvolvimento Ágil de Software |
| 2002 | Schwaber e outros fundam a Scrum Alliance |
| 2009 | Schwaber deixa a Scrum Alliance e funda a Scrum.org |
| 2010 | Primeira versão do Guia do Scrum |
| 2020 | Versão atual do Guia do Scrum, publicada em novembro |
Sutherland conta essa trajetória, com a influência da sua formação militar e do ciclo de Deming, no livro que escreveu com o filho; o resumo está em livro Scrum de Jeff Sutherland: resumo e lições para gerentes. Como o Guia evoluiu de versão em versão está em Scrum Guide em português: resumo do guia oficial.
O que a metáfora do rugby ainda ensina
O Guia do Scrum 2020 não menciona o rugby. Mesmo assim, várias ideias do framework ecoam a imagem de 1986:
- Um time só, sem sub-times. O Guia diz que não há sub-times nem hierarquias dentro do Scrum Team. No rugby, não existe "time de ataque" esperando o "time de defesa" terminar.
- Multifuncional. O time tem todas as habilidades para entregar valor a cada Sprint, como o bloco tem todas as posições necessárias para ganhar a bola.
- Autogerenciável. O time decide quem faz o quê e como, assim como os jogadores ajustam a jogada em campo sem esperar instrução para cada passe.
- Objetivo comum, não tarefas individuais. A Meta da Sprint funciona como a direção do empurrão: todos sabem para onde o bloco precisa ir.
- Fases sobrepostas. Dentro da Sprint, especificar, construir e testar acontecem ao mesmo tempo, não em sequência.
E há um ponto em que a metáfora alerta contra um erro comum: empresas que adotam Scrum mas mantêm o revezamento. O analista termina a especificação e "passa" para o desenvolvimento, que "passa" para o teste, que "passa" para a homologação. Os eventos do Scrum estão na agenda, mas o trabalho continua sendo uma corrida de bastão. Quando isso acontece, a Sprint vira um miniprojeto em cascata e o ganho desaparece.
O que muda para quem gerencia projetos
Para o gerente de projetos que chega ao Scrum, a origem no rugby ajuda a entender três ajustes de postura:
- Organize por time, não por etapa. Em vez de montar um cronograma de repasses entre áreas, monte um time que reúna as especialidades necessárias para entregar algo utilizável em poucas semanas.
- Dê direção, não roteiro. Na instabilidade embutida do artigo de 1986, a direção sinaliza um objetivo amplo e desafiador e deixa o time livre para encontrar o caminho. No Scrum, isso é a Meta do Produto e a Meta da Sprint.
- Acompanhe sem microgerenciar. O artigo cita o controle sutil entre as características das equipes estudadas. Na prática, acompanhar resultados nas revisões e remover obstáculos funciona melhor que cobrar tarefas individuais todos os dias.
Isso vale para projetos de obra, de marketing ou de órgão público tanto quanto para software, desde que o trabalho seja complexo o bastante para não caber num plano fechado.
Vale olhar também a outra metade da herança japonesa da gestão ágil: o Kanban, que veio do sistema de produção da Toyota por outro caminho. A trajetória está em história do Kanban: da Toyota à gestão ágil.
Para continuar
Depois da origem, o passo natural é entender como o framework funciona hoje, com responsabilidades, eventos e artefatos: está tudo em o que é Scrum e como funciona na prática e, num panorama mais amplo, no guia completo de métodos ágeis e Scrum. Se você quer estudar o framework de forma estruturada e com foco em certificação, o curso Agile Scrum Foundation da Projeto Diário cobre papéis, eventos, práticas e ciclo de vida do Scrum, com preparação para o exame ASF.
