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 sempre conseguem introduzir o Scrum e tornar suas equipes tudo menos ágeis. Isso é frequentemente chamado de "Zombie Scrum".
Quais são as causas do Fake Agile?
Em minha experiência, as causas mais comuns de Agile falso na prática 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
"Quando uma medida se torna um alvo, ela deixa de ser uma boa medida."
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, como seria se também pudéssemos definir nossos métodos de trabalho completamente com as regras –? 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 as coisas 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, a maioria das equipes ágeis não o faz.
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
