O princípio de "responder a mudanças mais do que seguir um plano" em geral é visto como um ponto forte do Agile, mas alguns consideram essa flexibilidade inviável na prática, por terem visto alguns projetos ágeis com dificuldades para gerenciar mudanças com clientes que esperam flexibilidade muito além do normal. Os efeitos são atrasos no projeto, problemas com qualidade e equipes com dificuldades para entregar valor. Será que o Agile não está a altura de suas promessas ou será que é a forma como as equipes e organizações têm adotado o Agile que está causando os problemas?
No artigo "Por que o Agile não está funcionando", publicado na CIO.com, Lajos Moczar apresenta razões pelas quais acredita que a metodologia ágil é falha:
As promessas do Agile são muitas, mas na prática a realidade é outra - muito distante das expectativas. Parece que o Agile falhou como outros modismos antes dele, e que tem tornado as coisas ainda piores no mercado de TI.
Uma das falhas apontadas é a prioridade do desenvolvimento sobre o planejamento:
Na teoria, os desenvolvedores codificam ao mesmo tempo em que colaboram com as partes interessadas, para definir, refinar e mudar os requisitos durante o andamento do projeto. Mas o Agile não diferencia as mudanças pequenas das grandes; cada mudança tem seu custo, e o Agile não leva isso em conta. O resultado é que frequentemente são feitas mudanças grandes no final do projeto. (afinal trata-se de um projeto ágil que pode lidar bem com isso).
A única forma que um projeto pode lidar com essa situação, porém, é adicionando iterações. Conforme isso acontece, os defeitos que antes seriam fáceis de resolver tornam-se cada vez mais difíceis de tratar, uma vez que a base de código não para de ser alterada.
Trata-se de uma abordagem bastante diferente das práticas tradicionais - em que o projeto é construído sobre requisitos bem definidos, e as mudanças são tratadas por meio do processo de Gestão de Mudanças. Apesar dos problemas, essa estratégia pelo menos leva em conta o tempo e os custos financeiros mais claramente.
Shane Hastie apresentou sua reação ao referido artigo em seu post "Por favor, não confunda Agilidade com Fragilidade", iniciando dessa maneira:
O autor interpreta de forma completamente equivocada o manifesto ágil e trata algumas práticas inteiramente fora de contexto, utilizando declarações sem fundamento para justificar suas conclusões.
O primeiro ponto abordado é sobre a falha mencionada por Moczar a respeito da prioridade do desenvolvimento sobre o planejamento. Hastie explica o problema de fazer a definição antecipada dos requisitos e as dificuldades encontradas com a gestão de mudanças:
A realidade é que as necessidade do negócio são voláteis. A expectativa de vida de uma demanda de negócio hoje é de aproximadamente seis meses, de forma que se a entrega acontecer só um ano mais tarde, o simples passar do tempo tornará 75% do que foi pedido simplesmente errado.
Hastie explica que o Agile trata as necessidades dos clientes de forma disciplinada e cuidadosa, e que ele de nenhuma forma se opõe ao planejamento:
O Agile não é desculpa para ignorar boas práticas de design, nem para permitir mudanças enormes sem análise de impacto. O Agile propõe a adaptação dentro de alguns limites e reconhece que, quando uma mudança é grande o suficiente a ponto de impactar o valor do projeto, ela precisa ser avaliada, mas não resistida.
Não há nada no Manifesto Ágil sobre não planejar a estrutura geral do produto desde o começo, e certamente nenhum dos autores ágeis de respeito e líderes na área recomendam começar escrevendo código "como poesia de versos livres". Qualquer projeto precisa de algum design prévio, e nos projetos ágeis o que se evita é o design antecipado de grande porte, pois sabemos que o mundo certamente mudará ao nosso redor.
Esther Schindler escreveu em seu artigo "Por que seus usuários odeiam o desenvolvimento ágil (e o que fazer a respeito)", no ITworld, sobre as diferentes visões que os desenvolvedores e usuários podem ter do Agile. Uma das diferenças apontadas é que os desenvolvedores entendem o Agile como um processo iterativo; os usuários como desorganizado e sem fim.
Logo no começo da história do Agile [...] muitos grupos e empresas viram o Agile como desculpa para que as equipes de desenvolvimento deixassem de estimar, documentar e planejar. As coisas melhoraram muito desde aquela época, mas a má impressão ainda circula por aí, mesmo na própria comunidade de desenvolvimento.
As equipes ágeis procuram ser o mais flexíveis quanto possível para atender às necessidades dos usuários, mas os próprios usuários (Hastie defende) podem acabar tendo expectativas acima do normal sobre essa flexibilidade, tornando difícil para as equipes continuarem a entregar valor:
Às vezes a mentalidade de que "o Agile significa desorganização" leva os usuários e os clientes a interpretar o Agile como um processo que admite que eles próprios sejam inconstantes. Os métodos ágeis permitem sim aos usuários alterarem as prioridades, mesmo que no final de um projeto grande.
O desenvolvedor Sorin Costea, contudo, observa um problema quando as coisas funcionam bem: "Os usuários não conseguem acreditar que existem limites no poder de entrega. Não conseguem entender ideias como Velocidade ou Timeboxes, mas têm expectativa de pedir histórias de usuário a qualquer momento e tê-las entregues no prazo". O argumento seria "afinal, somos ágeis, certo?"
Corbin Norman postou em seu blog reconhecendo o bem geral trazido pelo Agile: Louvando seu lado positivo e afastando seu "minúsculo" lado negativo. Norman fala também de como as pessoas às vezes têm uma visão negativa do Agile:
Os críticos do Agile argumentam que essa metodologia de desenvolvimento está tornando as coisas piores para quem trabalha com software, pois traria promessas que não pode cumprir, induzindo ao hábito de promover um levantamento mal acabado de requisitos, de esconder os custos reais do desenvolvimento e dificultar a gestão efetiva. O argumento defendido é que a suposta dificuldade na gestão levaria a projetos mais longos, insatisfação dos clientes e ineficiência geral da TI.
Atualmente, existem alguns argumentos válidos tanto em prol quanto contra a prática do desenvolvimento ágil, mas a comunidade deveria levar em conta o benefício que o Agile traz em relação ao pequeno prejuízo causado.
De acordo com Norman, uma das vantagens do Agile é sua flexibilidade:
Com o Agile, o cronograma e os custos são fatores mais determinantes e é o escopo que muda para acomodar demandas de negócio aceitáveis, ou seja, as necessidades do cliente. Para equipes ágeis maduras, esse nível de flexibilidade é adquirido por meio de anos de experiência trabalhando em conjunto.
O método cascata tradicional não permite esse nível de flexibilidade após o início do projeto, pois adota estritamente a ideia de que um estágio deve ser concluído antes de o próximo começar e que não se pode voltar para fazer ajustes.