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.