Já alguma vez ouviu falar da experiência dos cinco macacos? Se não, não vou a reescrever aqui, visto que há vários exemplos na internet (como neste artigo). Conclusão: após uma dinâmica específica e falta de comunicação adequada, a experiência acaba com cinco macacos numa jaula, evitando o que eles realmente querem - comer um cacho de bananas - mas sem saber exatamente porquê. Apesar de não haver provas suficientes que demonstrem que esta experiência realmente aconteceu, aposto que você pode relacionar com alguns exemplos no trabalho.

Aposto nisso porque tenho de me lembrar constantemente porque estou fazendo algo do modo como estou a fazer. Respostas como “porque sempre o fizemos assim “ escondem frequentemente que, na época, o contexto era diferente do de hoje em dia, mas ainda assim pagamos o preço. Além disso, quando se fala de Agile, frameworks e metodologias, não é raro de se ver uma encenação estranha - como uma peça de teatro - que não duraria se parássemos durante 5 minutos a tentar justificá-la.

Não me interpretem mal, não estou dizendo que nunca fiz parte dela, ou que nunca mais seria apanhado nessa situação. Nem pensar! Estou ciente de que o perigo do status quo está sempre a espreita e que preciso me questionar, de forma recorrente, se quiser ficar livre dele. E foi por causa dessas análises que decidi registar aqui as três maiores armadilhas que vi em equipes de Scrum e porque é que acredito que, evitando essas armadilhas, sua equipe entregue mais valor, mais rapidamente.

Concentre-se em fornecer valor, não Story Points! Se for detectado um defeito tardio devido à US, seja verdadeiro sobre ela, trabalhe na sua reparação e depois entregue-a. “Concluir” a US mas abrir um defeito logo a seguir não é o verdadeiro objetivo aqui.

🐵 Armadilha 1: Entregar story points ao invés de valor

Imagine o seguinte: o desenvolvedor descobre um defeito no código existente enquanto desenvolve uma funcionalidade específica. O defeito está relacionado ao código desta funcionalidade? Não, de forma alguma, ele está ali parado há séculos e ninguém jamais notou isso. Entretanto, com esta nova funcionalidade, é quase impossível não perceber que algo de errado está acontecendo.

A armadilha aqui é tentar “entregar” o trabalho, argumentando que o defeito precisa ser corrigido em outro ticket. Não está suficientemente claro que mesmo que a funcionalidade não esteja causando o defeito, ele o coloca em destaque? Todos os usuários e desenvolvedores serão impactados pelo defeito no momento em que este novo recurso for incluído no produto. Por que isto precisa ser entregue tão rápido, a qualquer custo?

Alguns podem dizer: porque nos comprometemos a entregar, e se não entregarmos, nossa velocidade diminuirá. Esqueça a velocidade, se você considerar que ela existe para se comparar com outras equipes. Chame-lhe de cadência, capacidade, o que você quiser, desde que você entenda que isso é um indicador para ajudá-lo a prever o valor entregue nos próximos sprints. Nada mais do que isso. Prever o valor que você vai entregar. Qual é o valor de entregar o recurso do cenário acima?

Concentre-se em fornecer valor, não Story Points! Se for detectado um defeito tardio devido à US, seja verdadeiro sobre ela, trabalhe na sua reparação e depois entregue-a. “Concluir” a US mas abrir um defeito logo a seguir não é o verdadeiro objetivo aqui.

Como diz o ditado, um pássaro na mão vale mais que dois voando. Transpondo para nosso mundo, pode-se dizer que uma pull request completada vale mais que duas sob revisão.

🐵 Armadilha 2: Pensamento individual ao invés de esforço em equipe

Sobre concentrar em entregar valor, eu quis dizer valor de equipe. A armadilha número 2 na minha lista é a memória seletiva que vi, mas da qual também fiz parte. O cenário é claro: você pega uma US para trabalhar, você coloca todo o seu esforço nisso. Codificar, testar e validar o melhor que você puder. Você pode até mesmo ir um pouco mais além, fazendo tudo o que puder para que a Pull Request seja completada o mais rápido possível. Uma vez que a US esteja pronta, o que você faz?

Por experiência, há uma boa chance de que você simplesmente volte sua atenção para o próximo ticket. Como quando se joga futebol, você recebe a bola e mantém sua cabeça baixa, correndo em direção ao gol. Mesmo que você esteja fortemente marcado e outros dois colegas estejam lá, ao seu lado, apenas esperando o passe que certamente fará com que sua equipe marque. A memória seletiva que eu estava mencionando antes é que se você for perguntado “Você faz parte de uma equipe?” você responderá prontamente: “SIM!”. No entanto, em vez de tentar ajudar a equipe a atingir seus objetivos, você pensa como um indivíduo, um elétron livre.

Como diz o ditado, um pássaro na mão vale mais que dois voando. Transpondo para nosso mundo, pode-se dizer que uma pull request completada vale mais que duas sob revisão. Da mesma forma que o desenvolvimento é muito mais do que código, destacar-se como membro de uma equipe é muito mais do que abrir pull requests. Faça o esforço para mudar esta resposta mecânica de agarrar diretamente o próximo ticket. Comece a levantar a cabeça, verificando se há algum US em andamento que você possa ajudar a desbloquear. Mesmo que não seja necessariamente o seu “papel”, como ajudar a testar a acessibilidade.

🐵 Armadilha 3: Seguir metodologias cegamente

Talvez, a última armadilha seja um efeito dos termos que usamos. Sprint, Velocity e Story Points dão uma noção de competição. Como se você estivesse competindo com outras equipes de Scrum. E não se trata apenas dos termos, mas também dos papéis e cerimônias. Quero dizer, o stand-up diário não é apenas para sair de sua cadeira uma vez por dia 😂

Quantas vezes você já disse a frase mágica: “Ontem eu fiz isso, hoje eu vou continuar fazendo isso e não estou bloqueado” e imediatamente parou de ouvir os outros? Ou passar uma hora falando sobre o que correu bem e o que poderia ser melhorado, para que no final você tenha uma lista de itens de ação que ninguém segue? Sem entender porque a metodologia é do jeito que é, como você não pode dizer que não é como o macaco na jaula? Ou pior, depois de experiências desagradáveis, simplesmente chegue à conclusão de que a Agile está “quebrado” e não se ajusta à sua equipe.

Não me entenda mal, não estou defendendo seguir a metodologia como o Santo Graal. Estou, por outro lado, defendendo estar atento ao que você está fazendo e ao que você não está fazendo. E para isso, o conhecimento é seu melhor aliado. Há duas coisas que eu definitivamente sugiro que você leia:

1. The Scrum Guide - por Ken Schwaber and Jeff Sutherland Scrum.org link (em inglês)

2. Scrum: A arte de fazer o dobro do trabalho na metade do tempo - por Jeff Sutherland Amazon link

Sugiro também que você leia na ordem acima. O primeiro é o próprio guia, excelente para descobrir que você pode estar fazendo coisas em sua equipe que nem sequer estão descritas no guia (como User Stories 😮). O segundo, é um excelente livro do Sr. Sutherland (sim, o mesmo co-autor do próprio Guia Scrum) onde ele descreve porque cada cerimônia tem seu lugar e qual é o objetivo que você quer alcançar. Mais importante, ele até usa exemplos surpreendentes de mundos tecnológicos e não tecnológicos.

🍌 Concluindo…

Tentando resumir as formas de evitar as armadilhas acima:

1. Entregar valor ao invés de story points
2. Favorecer o esforço de equipe ao invés do individual
3. Conhecer a metodologia ao invés de segui-la cegamente

E o mais importante, esteja atento a suas ações, você pode ser parte de uma experiência e não sabe

Créditos à Jamie Haughton em Unsplash🙈