Ferramentas das metodologias ágeis, são apenas isso: ferramentas. Elas devem ser utilizadas quando necessárias, são um tipo de ajuda e fórmula básica para te ajudar a fazer seu trabalho ficar mais fácil, como TDD, BDD, DDD, pair programing, etc, por si só não são mágicas e não resolverão seus problemas, não importa se você as está utilizando exatamente da maneira prescrita. Esses assuntos foram tratados no curso de PO que fiz com o Alexandre Magno e também na palestra do David Hussman, ambas no Agile Brazil 2010.

O mesmo vale para Scrum, XP, RUP, “coisas waterfall”, ou qualquer outra metodologia, que não passam de um conjunto de ferramentas com um manual de instruções. Se você usar Scrum, por exemplo, “by the book” e seu projeto continuar dando errado quer dizer que a metodologia é ruim? Não, quer dizer apenas que o problema é maior do que um conjunto de regras pode resolver, provavelmente a culpa é sua, da equipe, da empresa e sua cultura, ou simplesmente do acaso, mas não é algo errado com a metodologia em si, é apenas a vida se mostrando mais complexa do que esperamos, ou seja, nada fora do normal.

Nesse momento reforço a importância dos valores e princípios, que no caso dos projetos de software podem ser encontrados no Manifesto Ágil. Eles não são fórmulas ou regras escritas em pedra, são apenas conselhos dados por pessoas que estão buscando um jeito eficiente e eficaz para desenvolver software há décadas, que podem ser considerados ou ignorados, mas, que na maior parte dos casos, fazem muito sentido, e particularmente tento segui-los.

Se o que você faz hoje não segue todos os detalhes da metodologia X ou Y mas são fiéis aos valores e princípios expressos lá, então você é ágil, e se eles o ajudam a fazer seus projetos andarem melhor, ótimo, a agilidade é boa para você, continue o que já faz, caso contrário mude, ou os resultados continuarão sendo os mesmos.

Recomendo a leitura dos blogs do Fabio Akita - Akita On Rails e Gestão 2.0 (se é que você já não lê), onde ele sempre fala sobre a complexidade das coisas e também da racionalidade/irracionalidade inerente ao ser humano quando pensamos em metodologias e ferramentas. Escrevi o básico desse no fim de Junho, logo após o Agile Brazil, e só ontem fiz a última edição e aproveitei para assistir ao screencast que o Akita publicou há pouco tempo, o Entenda Software da Maneira Correta (vale muito a pena comprar), onde ele fala sobre bastante sobre isso mas com uma pesquisa muito mais abrangente e com o estilo “pé na porta, soco na cara” dos crédulos de plantão. Material obrigatório.

Também recomendo o post e vídeos “Restrições são boas mas restrições são ruins” doGuilherme Silveira e da Cecília Fernandes, além dos blogs deles, são visões muito interessantes sobre seguir regras/fazer o que é importante.

No fim das contas, o importante é fazer o que ajuda você e seu time a atingir seus objetivos, e no mundo dos projetos de software feitos por 99,9% do mercado, na minha experiência, o melhor caminho é expresso pelo Manifesto Ágil. Sempre existirão casos extremos, mas aconselho que você se pergunte: meu projeto caí nos 0,01% que sobraram? Ah, e seja sincero na resposta :)