Espanto-me com a pouca tolerância à falhas que nossa sociedade tem. Parece que somos todos perfeitos. Acredito que boa parte da resistência à adoção da agilidade nas empresas está na dificuldade em aceitar que o modelo anterior é falho, e que as próprias empresas falham constantemente.

Não que o fato de que somos uma industria que falha mais do que tem sucesso esteja em discussão, já que diversos estudos apontam que, enquanto indústria, enquanto profissionais, somos absolutamente incompetentes. Os números do Chaos Report do Standish Group não deixam ninguém discordar:

De 2006 a 2009 nós ficamos ainda piores, fracassamos mais.

Como você se sentiria se seu médico lhe dissesse que, ao realizar uma operação, haveria 1/3 de chance de sucesso, 1/3 de chance de você ficar inválido, e 1/3 de chance de você morrer? Inaceitável, não é? Esses somos nós, enquanto industria.

Ok, falhamos então. E daí?

Daí que ainda assim, agimos como se não falhássemos. Sempre digo que há uma grande chance de as primeiras iterações de um projeto falhar. Quando falo para as empresas, muitos não se conformam. Quando falo para alunos, muitos não entendem. “Como ele, que apóia, divulga, e ensina sobre agilidade pode dizer que falhamos nas primeiras iterações?”, pensam eles. Não só digo que falhamos, como digo que isso não é um problema.

Quando foi que a sociedade determinou que não podemos falhar? Quando nos decretamos super-heróis, que não erram, estimam perfeitamente (?!), e planejam anos à frente sem errar?

O problema não é falhar. O problema é falhar sempre, o problema é falhar e não aprender com a falha. A falha é um dos melhores instrumentos de aprendizagem que temos. Ela expõe nossas deficiências, e nos dá oportunidade para melhorar.

Vou contra o que dizem XP, Scrum, entre outros: a saída mais importante das primeiras iterações de um projeto não é o produto, não é o ROI. Acho que a saída mais importante das primeiras iterações é o aprendizado do time. É ele que vai habilitar o sucesso futuro, se estamos falando de um time verdadeiramente ágil. Tal time vai ter transparência e feedback imediato, resultado de ciclos curtos, e vai se adaptar. Com projetos ágeis há o risco de falhar a cada 1 ou 2 semanas, e junto com ele vem a oportunidade de melhoria. Projetos waterfall só tem essa oportunidade uma vez: no final; mas aí já é tarde demais.

O produto e o ROI também são importantes nas primeiras iterações, mas eles são resultados de um time bem entrosado. Eles devem ser a meta da iteração, assim como são a razão para a existência do projeto. Mas não são o mais importante nestas primeiras iterações. De nada adianta entregar o produto se o time não aprendeu nada; esse tipo de situação é insustentável, senão impossível, em um time que está em amadurecimento.

Logo após as primeiras iterações o aprendizado do time passa a ficar em segundo plano. Assim que se integra e começa a amadurecer, o time passa a aprender osmóticamente, e o conhecimento habilita a entrega do produto e o ROI, que assumem o papel principal.

Em projetos onde o time é mais maduro e trabalha bem junto, conhece mais o negócio e a tecnologia, esse aprendizado ocorre muito mais rápido, e o time é capaz de entregar valor desde as primeiras iterações. A situação exposta no parágrafo anterior é catalizada, e o aprendizado fica em segundo plano o tempo todo. Mas só uma empresa madura consegue propiciar tal cenário.

A cultura de aprendizagem e a capacidade de reação rápida são duas das maiores vantagens de projetos ágeis.

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.