A decisão entre usar métodos waterfall ou agile deveria ser determinada com base no nível de conhecimento que se tem sobre o problema e a solução. Essa é a afirmação de David J Blant, da Scrumology.
O artigo de David aponta que:
1. É uma questão de preferência entre utilizar agile ou waterfall se tanto a solução quanto o problema são bem conhecidos.
2. Agile funciona bem quando o problema é conhecido, mas não a solução. Waterfall não funciona nestes casos.
3. Métodos ágeis também funcionam bem quando o problema e a solução são em grande parte desconhecidos. Waterfall não se aplica nestes casos.
David resume sua opinião no final do artigo:
A batalha Agile vs Waterfall está se tornando velha e cansativa. Nenhuma delas vai desaparecer e a discussão é apenas ruído. Ela nos distrai do que realmente importa, que é saber se o problema e a solução são conhecidos corretamente.
Então devemos parar de culpar waterfall por todos os nossos problemas e começar a nos perguntar se estamos escolhendo as melhores ferramentas para cada tipo de projeto.
O artigo gerou uma interessante repercussão no grupo Agile do LinkedIn. Inicialmente, muitos comentários concordaram com Blant, mas, conforme a discussão progrediu tornou-se evidente que, no desenvolvimento de software, é raro serem conhecidos tanto o problema quanto a solução. Isso foi ilustrado por um comentário de Chris Shield:
Acredito que a solução nunca é 100% conhecida em desenvolvimento de software. Existe sempre alguma mudança a partir do início do projeto, novas premissas surgem, outras se mostram inválidas, novos requisitos são revelados etc.
Greg Robinson fez o seguinte comentário:
Desenvolvimento de software é essencialmente um processo de pesquisa e desenvolvimento em que você trilha seu caminho através de uma infinidade de potenciais soluções para encontrar um ótimo aceitável. Pensar que você pode aplicar processos de manufatura onde seja possível criar um desenho técnico, obter concordância de todos e então o construir corretamente (OTOBOS) já na primeira tentativa é, na melhor das hipóteses, uma posição otimista; e trata-se de uma deficiência fundamental de todos os processos em cascata. Se já é difícil planejar um sprint de duas semanas, o que dizer de um plano de entregas com duração de um ano? Será que os seus requisitos ainda terão validade no próximo ano, mesmo que eles estivessem corretos no início do planejamento?
Os comentários seguintes discutiram a possibilidade de se conhecer o problema e a solução no início de um projeto de desenvolvimento de software. Porém, parece ter havido um consenso de que tanto waterfall quanto Agile possuem espaço no gerenciamento desses esforços.
Além disso, outras opiniões puderam ser encontradas na web, incluindo um post de Pawel Bradzinski. A visão dele é que as pessoas, não processos e metodologias, é que determinam o sucesso de um projeto de software.
Outros autores fizeram uma análise mais profunda e criteriosa de fatores contextuais que afetam o desenvolvimento de software. Tom Peplow escreveu um ótimo artigo sobre isso em 2008.