Jeff Sutherland e Ken Schwaber frequentemente apontam para o artigo “The new new product development game” (ou “O novo jogo no desenvolvimento de novos produtos”), publicado em 1986 por Takeushi e Nonaka na revista Harvard Business Review, como a principal fonte de inspiração direta para a criação do framework Scrum.
Nesse artigo, os autores japoneses utilizaram uma analogia com o jogo de rúgbi para a forma como times de desenvolvimento de novos produtos (como carros, impressoras, copiadoras e computadores pessoais) estavam realizando seu trabalho nos anos 1980.
Se Scrum fosse aplicado ao desenvolvimento de software, seria mais ou menos assim: (…) forme a equipe escolhendo cuidadosamente uma pessoa de cada uma das [fases tradicionais de desenvolvimento]. (…) Você então dá a eles uma descrição do problema a ser resolvido e (…) os desafia, dizendo que deverão produzir o sistema em, digamos, metade do tempo e dinheiro e que deve ter o dobro da performance de outros sistemas. Em seguida, você lhes diz que como eles farão isso é da conta deles (DeGrace & Stahl, 1990).
As verdadeiras origens do Scrum
A palavra “scrum”, que aparece nomeando uma das sessões do artigo, é uma formação para reposição de bola no jogo de rúgbi. Assim, foi a partir daí que os criadores do Scrum nomearam o framework.
Há muitos indícios, no entanto, que sugerem que Sutherland e Schwaber não contam a história toda. Veja a citação no ínicio deste post. Ele foi retirado do livro “Wicked problems, righteous solutions”, de 1990. Foi esse livro que trouxe pela primeira vez a ideia de utilizarmos no desenvolvimento de software o conjunto de práticas descritas pelos dois autores japoneses na reconhecida revista. E foi nesse mesmo livro que seus autores, DeGrace e Stahl, batizaram essa nova forma de trabalhar de “Scrum“.
Para sermos justos, é importante notar que o livro não fornece um método minimamente detalhado nem utilizável de como colocar essas ideias em prática. Coube a Sutherland e Schwaber criar o framework propriamente dito com suas regras, papéis, eventos e artefatos, e colocá-los em funcionamento.
Nesse mesmo livro, os autores explicam por que o modelo em cascata (ou “waterfall”) não funciona para o desenvolvimento de software, e oferecem possíveis alternativas. Scrum aparece como uma das alternativas. O livro gira em torno da ideia de que software é um tipo de problema que não pode ser claramente definido nem detalhado antes que se ofereçam soluções a ele (um “wicked problem”). Em outras palavras, cada tentativa de criarmos uma solução modifica a própria definição do problema.
Para os meus alunos, eu tento demonstrar esse conceito perguntando o seguinte: “o que temos certeza que vai acontecer quando colocamos uma nova funcionalidade diante de um usuário?” O usuário certamente vai responder algo como: “agora que estou vendo isso funcionando, vejo que não preciso disso, que preciso daquilo, que isso não deveria ser assim…” etc. Com isso, não podemos detalhar antecipadamente todas as funcionalidades que o software deverá ter para resolver o problema proposto, apenas podemos desenvolver a partir de hipóteses. A definição do produto emerge ao longo do seu desenvolvimento e uso. Ou, como sempre gosto de dizer, o uso define o produto.
Jeff Sutherland faz referência ao livro “Wicked problems, righteous solutions” em pelo menos dois artigos escritos por ele nos primórdios da história do Scrum. Ele destaca essa obra como de grande influência na introdução do Scrum na Easel Corporation. Jeff ainda destaca o modelo “Tudo-de-uma-vez” (“All-at-once”), trazido pelo livro, para descrever o Scrum como uma abordagem em que o time multidisciplinar realiza simultaneamente todo o trabalho necessário para gerar partes do produto funcionando de ponta a ponta.
Quando a K21 trouxe, em 2017, o Jeff pela primeira vez para o Brasil, passei uma tarde com ele e tivemos a oportunidade de conversar sobre diversos assuntos relacionados à história do Scrum. Mas, até onde sei e pude verificar, nem Jeff nem Ken em momento algum deram oficialmente o devido crédito aos autores do livro nem mencionam sua importância com relação à ideia original.
De forma alguma estou afirmando que Jeff e Ken não são os criadores do framework Scrum, já que eles definiram e ainda evoluem suas regras, papéis, eventos e artefatos e os colocaram em prática. Mas, certamente, não foram eles que tiveram a ideia original de aplicar no desenvolvimento de software a abordagem descrita pelos japoneses, e certamente não foram eles que a batizaram de Scrum.
Quer saber mais sobre o Scrum?
• Leia mais artigos sobre o framework
• Participe do treinamento Certified ScrumMaster
Referências:
DEGRACE, P.; STAHL L. H. Wicked problems, righteous solutions: a catalogue of modern software engineering paradigms. Nova Jersey: Yourdon Press, 1990.
SUTHERLAND, J. Agile can scale: inventing and reinventing SCRUM in five companies. Cutter IT Journal, v. 14, p. 5-11, 2001.
SUTHERLAND, J. Agile development: lessons learned from the first Scrum. Cutter Agile Project Management Advisory Service: Executive Update, v. 5, n. 20, p. 1-4., 2004.
TAKEUCHI, H.; NONAKA, I. The new new product development game. Harvard Business Review, Boston, MA, Estados Unidos, v. 64, n. 1, p. 137-146, jan./fev. 1986.
