No artigo de hoje vou falar um pouco da história do Scrum e da sua evolução desde a 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 da é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 sua demanda. Scrum te dá apenas linhas gerais como base. Logo, não é um processo – se fosse, 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 caiu 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

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

• Pregame, composto por Planning e Architecture (as mesmas duas etapas da Sprint Planning atual)
• Game, o desenvolvimento da sprint
• 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 devem 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 das fontes dos outros naquela época.

Depois, em 2004 veio um 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
• Incremento se tornando um artefato oficial (voltando às origens)
• 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 é muito marketeiro, o que gera críticas por fazer um desserviço à comunidade ágil, uma vez que ilude managers inescrupulosos, criando falsas expectativas que geram mais pressão sobre os times.

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 pela tendências apontadas pela InfoQ ano passado, como pode ver na imagem abaixo.

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 quantas novidades temos à frente de nós e que só o Scrum por si só 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 portal.

Curtiu o artigo? Dê uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso sobre o mesmo assunto.

Até!