A maioria dos praticantes de Scrum já viu a tira sobre o porco e a galinha. Para quem não viu, basicamente a galinha convida o porco para abrir um restaurante: ovos com bacon. O porco diz que não vai entrar, pois ele estaria comprometido, a galinha estaria apenas interessada.
Vamos pular dessa referência para os filmes de Hollywood e o jogo de “chicken”, isto é, galinha. Galinha é tipicamente um desafio mortal, onde o primeiro que desistir perde. Um carro indo rapidamente em direção ao outro, ou ambos em direção ao abismo, quem desviar primeiro é o medroso, a galinha. É um jogo interessante, pois caso os dois não desistam o prejuízo é enorme para ambos.
Só como comentário, não conheço o jogo do porco. Acho que eles são espertos demais para jogar.
Em projetos de software, e em projetos ágeis, não podemos ser galinha. Temos que ter coragem e assumir a responsabilidade. O problema é que ás vezes estamos indo de encontro ao abismo e confundimos a galinha do Scrum com a galinha do jogo.
A mensagem que tenho é: algumas vezes o melhor que o porco pode fazer é ser a galinha do jogo.
Vamos então discutir o problema de sair correndo em direção ao abismo e uma possível solução.
Em um projeto recente decidimos que um grupo de funcionalidades seria praticamente impossível de desenvolver com a tecnologia que estávamos usando. Depois de pensar um bocado, decidimos mudar de tecnologia. Obviamente a promessa era de um “parto sem dor”. Imaginamos que em poucos sprints estaríamos com tudo pronto. A equipe estava animada, a tecnologia não era conhecida mas era “apenas” uma evolução e tudo deveria funcionar.
Ou não.
Depois de duas sprints, os sinais estavam todos lá. Ninguém sabia a dificuldade de fazer qualquer coisa. A equipe chutava todas as estimativas para o alto. A revisão era praticamente nula. Um dos motivos: a terra prometida da nova tecnologia não era a terra do leite e do mel, mas sim uma sinfonia inacabada, cheia de notas desafinadas. Vamos deixar claro: não adianta ter uma equipe competente se a sua biblioteca não funciona. A culpa, porém, de cair nessa armadilha não é da biblioteca, mas sim da equipe toda, do Product Owner, do ScrumMaster e do Development Team.
Para encurtar uma história triste, nós ainda tentamos por mais duas sprints dominar a tecnologia e no final, desistimos. Trabalho jogado fora, desistimos da nova tecnologia e das novas funcionalidades.
Perdemos um bom espaço de tempo para produzir nada, zilt!
Perdemos a hora exata de ser galinha. Caímos no abismo.
Novas tecnologias tem um charme que atraem desenvolvedores. Novas funcionalidades propostas por essas tecnologias atraem os POs. Maravilhados com o canto da sereia, ninguém quer confessar que fez a escolha errada e continua com a escolha, se apega ao capital afundado até que esse capital seja tão grande que quase afundamos junto.
Estou há algum tempo imaginando uma solução para esse problema. Acho que não é o primeiro post que toca nesse assunto, mas nunca fui tão claro e honesto em descrevê-lo.
Qual a solução?
Lembrando da Teoria dos Jogos, é melhor não jogar o jogo da galinha. Sair cedo, desistir imediatamente.
Proponho que a primeira solução é uma “Sprint de Reconhecimento”.
Esse é o termo que cunhei para uma Sprint que vai “dar uma olhada”. O objetivo dela é conhecer e mapear o terreno, ver se é possível caminhar por ele e quais as principais dificuldades. Uma Sprint de Reconhecimento tem que incluir reconhecimento do terreno, isto é, estudar a nova tecnologia, e tentativas de penetração no terreno, isto é, protótipos funcionando que demonstrem que alguma necessidade é possível. Seu resultado tem que ser um mapa do que é possível, do que não é possível e das partes que não foram visitadas.
Após uma Sprint de Reconhecimento é necessário parar para pensar. Ela é apenas parte de um estudo de viabilidade tecnológica. As conclusões devem ser apresentadas formalmente. Uma sugestão é mudar a reunião de revisão da tradicional forma de rever funcionalidade para a forma de rever o pedido do PO, que é verificar a viabilidade de adotar uma tecnologia. Isso implica que as histórias tem que ser escritas com esse objetivo e não com o objetivo de criar funcionalidade. O valor agregado ao usuário é a capacidade de discutir se o projeto deve ou não ir por aquele caminho.
Era isso que eu faria agora. Será que daria certo? Bem, a reunião de retrospectiva serviria para avaliar e propor mudanças.
Gostei muito da analogia!
Me senti muito familiarizado com a história. rs
Abraços
Muito bom post. Parabéns!
Quando tenho um cenário como este gosto de fazer os spikes do xp. Parte do time se dedica a estudar e fazer soluções rápidas para validar a tecnologia dentro do contexto do projeto. Desta forma, ainda entregamos algo para o cliente ao passo que experimentamos a nova tecnologia.
Ao escrever o post não me lembrei de citar, mas enquanto pensava e investigava uma solução me lembrei sobre os spikes do XP. Obrigado pela contribuição. Uma introdução rápida em http://www.extremeprogramming.org/rules/spike.html