Nem toda equipe Scrum é ágil: Fake Agile

Fake Agile: Toda equipe Scrum é ágil?

Não, infelizmente nem toda equipe Scrum é realmente ágil.

Deixe-me explicar: Uma equipe Scrum é definida por trabalhar de acordo com a estrutura Scrum: Portanto, ela tem sprints, determinadas funções e rituais. E como o objetivo da estrutura Scrum é ajudar as equipes a trabalhar de forma ágil, o Scrum deve automaticamente tornar todas as equipes ágeis, certo?

Infelizmente, na prática, as organizações continuam a introduzir o Scrum e, ao fazê-lo, tornam as equipas tudo menos ágeis. Fala-se frequentemente de “Zombie Scrum”.

O que é “Fake Agile”?

“Fake Agile” refere-se a equipas que, embora trabalhem oficialmente com frameworks e métodos ágeis, não têm ciclos de aprendizagem reais com os clientes. Fake Agile significa, portanto, que ou a) não são entregues incrementos iterativos aos clientes ou b) o feedback direto do cliente sobre o incremento não é utilizado para a priorização a curto prazo.

Quais são as causas do Fake Agile?

Existem muitas razões para o “Fake Agile”. Na minha experiência, as causas mais comuns na prática para o Fake Agile são as seguintes:

Falso Agile Causa #1: nenhum feedback do cliente

Se uma equipe ágil não receber feedback direto dos usuários, ela não poderá trabalhar de forma ágil. Na prática, as solicitações dos clientes geralmente são formuladas pela gerência e repassadas às equipes por meio dos proprietários dos produtos. – Os verdadeiros ciclos de feedback com os clientes desaparecem ou nem sequer existem.

Uma equipe ágil precisa de contato direto com o cliente!

Fake Agile Causa #2: Foco na velocidade e nos pontos da história

Ufa, será que precisamos falar muito mais sobre pontos de história em 2025? Acho que todos nós já tivemos experiências suficientes sobre o quanto o foco na velocidade e nos pontos da história atrapalha o benefício do cliente.

Um exemplo: O que acontece se uma função estiver formalmente pronta após a primeira iteração, mas ainda não atingir o benefício para o cliente? Se o benefício para o cliente for importante para nós, trabalharemos nele até que o benefício para o cliente seja de fato alcançado. No final, talvez sejam necessárias três iterações, mas pelo menos o cliente está satisfeito.

Mas espere, agora meu gerente aparece de repente e reclama que minha equipe realizou menos pontos de história no último sprint. Portanto, teria sido melhor para minha velocidade se tivéssemos simplesmente abandonado a função não valiosa e trabalhado diretamente na próxima função para que pudéssemos criar mais pontos de história.

Que besteira, não é mesmo? Se repetirmos esse processo por mais alguns meses, teremos um produto com muitas funções que geram muito pouco benefício para o cliente.

Portanto, não é de surpreender que tanto os clientes quanto as equipes de desenvolvimento fiquem insatisfeitos e saiam.

Em termos mais gerais, trata-se de uma lei já bem conhecida: Lei de Goodhardt

“When a measure becomes a target, it ceases to be a good measure.”

Fake Agile Causa #3: A ditadura do dogma

Os engenheiros adoram quando há regras fixas para tudo. Isso torna os processos planejáveis.

Então, que tal se também definíssemos completamente as nossas formas de trabalhar com regras - não seria ótimo? Não, não seria.

Somente com o Scrum e suas muitas regras e diretrizes, o trabalho ágil já dá a sensação de que muitas equipes estão trabalhando de acordo com diretrizes rígidas. Não deveria ser assim. Portanto, não piore a situação acrescentando mais regras e diretrizes ao trabalho ágil.

Nas melhores equipes ágeis que conheço, o trabalho parece humano, animado, espontâneo e colaborativo. E, reconhecidamente, na maioria das equipes ágeis isso não acontece.

As equipes de Agile devem ter, pelo menos, liberdade suficiente para colaborar de forma flexível com os clientes. Se as regras e os processos impedirem isso, eles deverão ser examinados.

Neste post, já escrevi especificamente sobre as etapas necessárias para proteger as equipes Scrum do Zombie Scrum: Corrigir o Zombie Scrum

O Agile falso é real: como se proteger?

Nada o protege totalmente da falsa agilidade. Mas há uma coisa que pode protegê-lo da melhor forma possível: Um processo eficaz centrado na melhoria contínua.

É claro que isso começa com boas retrospectivas, nas quais os membros da equipe podem compartilhar abertamente seus pontos de vista e derivar e implementar medidas de melhoria de forma independente.

Desde que esse processo funcione, o potencial de agilidade real da sua equipe não será perdido.

Se quiser levar suas retrospectivas ágeis para o próximo nível, recomendo o –naturally – Echometer, nossa ferramenta para retrospectivas. Você pode experimentá-la gratuitamente aqui: Experimente o Echometer