Pessoas de negócio acreditam que determinados requisitos são óbvios demais para precisarem estar escritos em um documento. Gente de tecnologia reclama que as especificações não são claras e cobram por mais detalhes nas solicitações. Quando as features são implementadas, time de negócio não tem tempo de avaliar prontamente a entrega. O time de tecnologia, por sua vez, quando recebe o retorno diz que precisa que aguardem seu sprint terminar. Para tentar resolver, cria-se mais processos e mais burocracia, como já falamos aqui no blog.

Apesar de dar enfoque nas discussões sobre os artefatos, você acredita que é ágil por que os chama de user stories e os escreve em post-its. Apesar de priorizar o fechamento do sprint e o processo, acredita que é ágil por estimar usando planning poker e fazer reuniões em pé.

O desenvolvimento ágil de software, para começar, não é fazer programação em pares, TDD, ou Histórias de usuário (…) Quanto mais se impõe regras rígidas, mais se restringe a capacidade natural dos integrantes da equipe para criar regras. Por fim, eles perdem a capacidade de serem realmente ágeis.

Jurgen Appelo no livro Management 3.0

A aparente leveza dos métodos ágeis comparados às abordagens tradicionais, pode nos induzir a acreditar que eles, por si só, enlatem a agilidade. Neste caso, uma boa adaptação deles pra nossa organização seria o suficiente para nos tornarmos ágeis. Os métodos prescritivos tem substituído nosso senso crítico que nos permite analisar, compreender e aplicar os princípios da agilidade no dia a dia.

Não que a simplicidade dessas metodologias, que permitiram a massificação da “agilidade”, não tenham trazido benefícios, porém como diz o bordão clichê do mercado corporativo, temos que ser focados em resultado. No fim do dia, por mais “cool” que seja uma metodologia, precisamos entender como nossas ações geram valor para o negócio. Como entregamos mais software de qualidade, em menor tempo, com menor esforço, resolvendo o problema certo.