A evolução do Scrum

Atualizado em 15/05/2020!

No artigo de hoje vou falar um pouco da história do Scrum e da sua evolução desde a sua criação até hoje e para onde acredito que o mercado está seguindo em termos de agilidade. Essa história é melhor trabalhada no livro Scrum: A Arte de Fazer o Dobro do Trabalho na Metade do Tempo de Jeff Sutherland e outras publicações menos conhecidas.

A Inspiração

Vale lembrar que durante a Crise do Software da década de 70 muitos profissionais de projeto e de tecnologia estavam empenhados em criar métodos e processos a fim de aumentar o grau de sucesso dos projetos à época. A Engenharia de Software moderna se originou deste movimento e metodologias tradicionais como o Waterfall e mais tarde o processo Iterativo Incremental se consolidaram neste período como formas “corretas” de se fazer software.

No entanto, conforme a tecnologia avançava, a digitalização das empresas começava a aflorar e os projetos se tornavam cada vez mais complexos e dinâmicos em um mundo globalizado, isso não bastou. Em 1986 a dupla de professores de Harvard, Takeuchi e Nonaka, escreveram o famoso artigo The New New Product Development Game onde relatavam o resultado da sua pesquisa com algumas das mais bem sucedidas empresas à época. Essa pesquisa buscava entender porque os produtos destas empresas se saíam tão bem, uma vez que a maioria dos projetos até então não estavam sendo bem sucedidos.

Não entrarei em detalhes sobre o artigo em si, que linkei acima que você pode ler na íntegra, mas este artigo inspirou engenheiros como Ken Schwaber e Jeff Sutherland a criarem novas formas de fazerem a gestão dos projetos de software. Em 1995, Ken Schwaber submetia o artigo SCRUM Development Process para a OOPSLA daquele ano, uma conferência sobre desenvolvimento orientado a objetos.

Assim nascia o Scrum, mas bem diferente de como é hoje.

A primeira versão do Scrum

Inúmeras são as diferenças da visão inicial de Ken Schwaber em relação ao que o Scrum se tornou anos mais tarde. Primeiro, ele era descrito como um processo de desenvolvimento, o que mais tarde se transformou em um framework. Talvez você já tenha ouvido falar isso, mas você sabe qual a diferença?

Um método ou processo é algo prescritivo, que deve ser seguido nos mínimos detalhes para que funcione. Já um framework é uma estrutura oca, onde você pluga novos componentes e o usa como base para evoluir para algo que supra a sua demanda. Scrum te dá apenas linhas gerais como base, logo não é um processo, caso contrário seria um processo incompleto.

Também nessa primeira versão, que você pode ler aqui, existiam apenas dois papéis: o Manager e o Development Team. O Manager era descrito como um Product Manager, mas que tinha também funções de Project Manager, o que obviamente o tornava quase um deus dentro do time e ao mesmo tempo alguém sobrecarregado. Anos mais tarde, Ken e Jeff quebrariam este papel em dois, além de evoluir suas funções como Product Owner e Scrum Master.

Os artefatos à época eram oito, o que mais tarde se reduziu pela metade:

• o clássico Backlog (hoje quebrado em dois) mais as Issues;
• Release/Enhacement, atualmente chamado de Incremento;
• Packets, Changes e Problems, hoje todos incorporados no Incremento;
• Risks e Solutions, não mais evidenciado de maneira diferenciada hoje;

E por fim, uma sprint à época possuía as seguintes fases (hoje cerimônias, eventos ou timeboxes, como preferir):

• o Pregame, composto por Planning e Architecture (as mesmas duas etapas da Sprint Planning atual);
• o Game, o desenvolvimento da sprint;
• o Postgame, com testes, documentação, preparação para release e a dita cuja.

Note como isso não era exatamente um método ágil moderno, uma vez que não previa melhoria contínua (com a Retrospective atual) embora citasse algum grau de transparência com uma menção à Review atual Também não é explícito que estas fases devam acontecer a cada sprint, e entendia que uma vez feito o Pregame, poderiam acontecer diversas sprint de desenvolvimento (Games) e depois um único Postgame para fechar o pacote.

As versões posteriores

Mais tarde, com Ken se aliando a outros engenheiros importantes e com a própria publicação do Agile Manifesto em 2001, o Scrum ganhou força e tivemos uma grande publicação que descrevia sua implementação em mais detalhes, fruto da parceria de Ken com Mike Beedle, o livro Agile Software Development with Scrum, em 2001 mesmo. No entanto, como descrito no livro, o Scrum teria sido criado como uma forma de fazer com que o Extreme Programming (XP) pudesse ser aplicável nas empresas.

Ou seja, Ken Schwaber e Mike Beedle eram fãs do trabalho de Kent Beck, o que mostra como essa galera estava compartilhando conhecimento e bebendo uns nas fontes dos outros naquela época.

Depois em 2004 veio novo livro de Ken Schwaber de como aplicar Scrum na gestão de projetos, o Agile Project Management with Scrum. Diferente do seu antecessor, mais focado em engenharia, este último era para o público de projeto, provavelmente oriundo da incompatibilidade dos métodos de gestão tradicionais com a nova abordagem de desenvolvimento.

Finalmente em 2010 surge o Scrum Guide, o guia que se tornaria a fonte oficial (e enxuta) de informação sobre Scrum. Foi nessa época que aprendi sobre métodos ágeis a primeira vez e quando li o guia, que tinha 32 páginas (hoje tem 19). Aqui o Scrum já estava bem mais próximo da versão atual. De lá pra cá apenas se apararam algumas arestas como por exemplo:

• maior foco no Sprint Goal, principalmente na Daily;
• o Incremento se tornando um artefato oficial (voltando às origens);
• o Burndown Chart deixando de ser um artefato oficial;
• criação dos Valores do Scrum;

Entre outras mudanças menores.

Em 2012, o famigerado Software in 30 Days foi lançado por Ken e Jeff. Famigerado porque, assim como “Scrum: Arte de fazer o dobro do Trabalho na Metade do Tempo” de 2014 (este somente pelo Jeff), este livro é muuuito marketeiro, o que gera críticas por fazer um desserviço à comunidade ágil uma vez que ilude manager inescrupulosos, criando falsas expectativas que geram mais pressão sobre os times. Mas enfim.

Em 2016 eu lancei o meu livro sobre o assunto, visando preencher as lacunas que eu fui encontrando ao longo dos anos com técnicas e artefatos de outros autores e que fizeram (e ainda fazem) sentido para os times ágeis que eu liderei ao longo dos anos trabalhando com Scrum.

O futuro do Scrum

Pesquisas como a State of Agile e a State of Scrum indicam que nunca o Scrum foi tão popular nas empresas. Não somente nas que se autoproclamam ágeis, mas também em maior ou menor grau até mesmo em empresas tradicionais, sendo que células independentes de muito empresa jurássica usa Scrum atualmente. Isso mostra o Scrum como um framework mainstream para desenvolvimento de produtos complexos, o que é evidenciado pelas tendências apontadas ano a ano pela InfoQ.

Note que o que esta imagem mostra é que os métodos ágeis mais tradicionais, os que estamos acostumados, já estão sendo adotados na categoria de empresas Late Majority. Isso não significa que Scrum está caindo em desuso, muito pelo contrário, que jamais foi tão utilizado na indústria de software.

No entanto, note o quanto de novidades temos à frente de nós e que só o Scrum por si não consegue dar conta. Ao invés de eu ficar especulando o que o futuro reserva para o Scrum, acho que vale a pena você dar uma olhada nestes tópicos aí para ver como as empresas mais tops do mercado estão trabalhando hoje, para quem sabe amanhã você puxar essas novas linhas na sua empresa.

Conforme eu mesmo for estudando e aprendendo sobre estes temas, tenha a certeza que estarei compartilhando aqui no blog. No vídeo abaixo eu compartilho várias dicas, aliás.

Até lá!

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso (abaixo) sobre o mesmo assunto!