Recentemente a Forbes publicou um artigo muito interessante, cujo título traduzido é “A Causa Contra Agilidade: 10 Objeções Gerenciais Perenes”, onde o autor discute 10 objeções à Agilidade, sendo 6 delas apontadas em outro post (“Limitações do Desenvolvimento Ágil de Projetos”).

Meu objetivo é ampliar essa discussão, entrando no debate entre os autores dos posts mencionados acima. Se eu fizesse isso apenas nesse momento acabaria com um texto muito longo. Assim vou dividir essa discussão em 6 posts, sendo esse o primeiro. Mais do que reproduzir esse debate, meu objetivo é incrementá-lo. Para facilitar o entendimento apelidarei o primeiro post (o da Causa Contra a Agilidade) como “A Defesa” e o segundo (o das Limitações) como “A Acusação”.

A Acusação, antes de colocar seus pontos, alega de que não há estatísticas confiáveis comprovando que projetos desenvolvidos com metodologias ágeis são mais bem sucedidos do que aqueles desenvolvidos com metodologias tradicionais.

A Acusação não começou bem… Aqui nesse blog já escrevi sobre uma pesquisa (“CHAOS Report: Métodos Ágeis Aumentam Taxa de Sucesso de Projetos“) do Standish Group. Nesse relatório o instituto aponta que o aumento do número de projetos desenvolvidos com metodologias ágeis é uma das 4 razões para o aumento do número de projetos bem sucedidos.

Mas vamos para a primeira objeção, o assunto desse post, … A Acusação alega: “Agilidade é somente para uma equipe de craques”. Ela menciona que Agilidade foi desenvolvida por pessoas experientes, inteligentes e bem sucedidas. Na visão dela pessoas como Martin Fowler ou Jeff Sutherland seriam bem sucedidas no desenvolvimento de projetos utilizando qualquer metodologia.

A Defesa, por sua vez,  contra-argumenta, dizendo que enquanto os métodos tradicionais pressupõe que as pessoas precisam de uma gerência rigorosa por não serem competentes o suficiente, as metodologias ágeis pressupõe o contrário, de que as pessoas são competentes, desde que livres das amarras de uma hierarquia burocrática.

Penso que competência é fundamental, independente da metodologia. A Agilidade apoia-se em um conjunto de 12 princípios. Um deles diz que software deve ser entregue em ciclos de poucas semanas. Outro que software funcionando consiste na primeira medida de progresso. Sem competência esses princípios não serão alcançados e isso será verificado logo no começo do projeto (em detrimento dos métodos tradicionais cujo sinal de alerta emerge em decorrência de orçamento estourado ou cronograma atrasado), quando medidas corretivas podem e devem ser tomadas.

A Acusação, ainda nessa objeção, convida o leitor para pensar em qual seria o resultado de um projeto desenvolvido em sua empresa por uma equipe auto-organizada constituída de funcionários medianos sem uma supervisão próxima. Outro princípio desconhecido pela Acusação  diz que as melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis. Esse princípio resulta de um estudo publicado pela Harvard Business Review onde os autores descobrem que foram justamente equipes auto-organizadas constituídas pelos próprios funcionários de organizações como Cannon, Honda e Toyota que permitiram a essas empresas inovarem com rapidez sem a perda de qualidade e flexibilidade de forma a competirem em mercados cada vez mais competitivos. Assim tenho certeza que se o leitor for de uma empresa com esse tipo de cultura reponderá positivamente à pergunta da Acusação.

Entendo que a Defesa perdeu uma grande oportunidade aqui. Se as pessoas que desenvolveram o Manifesto Ágil são caracterizadas pela Acusação como craques (a tradução correta seria “estrelas”, mas penso que craque está mais próximo da cultura do país do futebol), então ela deveria perguntar por que esses craques sentiram a necessidade e desenvolveram metodologias ágeis, se as tradicionais, que eles utilizavam, os levavam ao sucesso?

Em 1993 Jeff Sutherland se preocupava com a baixa produtividade no desenvolvimento de software, um problema que as metodologias tradicionais não endereçavam. O Scrum nasce dessa preocupação e, nas palavras de Jeff, “…deriva da teoria de sistemas adaptativos complexos e foi influenciado pelas melhores práticas na indústria japonesa… Scrum não é um método de desenvolvimento ou um processo formal, consiste num algoritmo de compressão das melhores práticas no desenvolvimento de software observadas por um período de 50 anos.”

Com as palavras de Jeff termino esse post. No próximo discutirei a objeção cultural das organizações à implementação de metodologias ágeis e, em particular, o Scrum.

Aqui fica o meu abraço pra você.