Tenho pensado muito sobre meu papel na Lambda3 nos últimos tempos. Com a empresa crescendo, eu mudando de áreas internas para atender às diversas demandas que surgem ou ainda participando de projetos, estou constantemente fazendo uma análise sobre qual atuação devo seguir como influenciador.

Depois de uma conversa acalorada com o Claudio Kerber, numa das várias que tivemos ao longo desses meses que ele está trabalhando conosco, surgiu a necessidade imensa de compartilhar a minha visão sobre Agilidade, e a atuação que isso passa a ter em nossa vida profissional. Trabalho nesse ritmo há anos, desde os tempos de Dojo Floripa, qdo aprendi com o Ivan Sanchez sobre o tal XP. Para mim, resumindo numa frase:

Agilidade é militância

Nos dias de hoje existe uma visão romântica sobre agilidade. Resumindo em algumas frases que já ouvi por ai:

• Meu chefe é ausente, não me procura pra falarmos dos problemas, não dá pra fazer Agile
• Ah, se tem código legado, não dá pra fazer Agile
• O cliente é muito chato, não da pra fazer Agile
• O cliente não quer ajuda, então vamos apenas baixar a cabeça e trabalhar. Não dá mais para ser Agil aqui.
• Não dá pra testar, então Agile não vai funcionar

A lista se estende por outras diversas pérolas, tocando nas ferramentas que estão ou não disponíveis, restrições diversas que o projeto apresenta, a cadeira que não é confortável, o cliente que é longe, etc…

Pareço um velho falando, mas é preciso lembrar do passado, e de como a Agilidade surgiu para resgatar projetos em crise. Existiu um tempo em que TODOS os projetos eram waterfall. Todos os projetos levavam meses de levantamento de requisitos para sairem do papel, em que ninguém acreditava que qualidade de software era um requisito de sucesso. Foi com a intenção de sair de uma situação problemática, e de fazer a diferença, que os pioneiros do movimento ágil resolveram rodar a baiana e mexer com o ambiente em que trabalhavam.

E chegamos ao valor mais importante pra mim no mundo ágil: A Coragem. Foi isso que motivou Kent Beck a apresentar o Extreme Programming num evento do PMI. Enxergando o extremo caos e desespero que os projetos de software estavam se enfiando, ele foi atrás de apresentar sua idéia, mudando a história da industria pra sempre.

Neste contexto, Agilidade deveria ser uma forma de agir, um modus operanti sobre como conduzimos nosso trabalho. Se você está num projeto de merda, a responsabilidade de mudar é sua. Comece utilizando as ferramentas disponíveis para possibilitar essa mudança, fazendo a diferença. Por que não utilizar os conceitos ágeis para lidar com situações de crise? Por que não agir para mudar?

Nenhum projeto é perfeito, nenhum cliente é totalmente favorável à Agilidade. Por isso que um trabalho diário de militância é imprescindível para conduzir qualquer projeto ágil. Todas as restrições e problemas que ocorrem num projeto devem ser encaradas como “mudanças ambientais de requisitos”, e conduzidas como qualquer outra parte do projeto: Aprendizado, feedback e adaptação.

Num exemplo mais claro, imaginem um projeto que você esteja trabalhando. Este projeto tem um gerente apenas cobrando horas do povo, não se importando com a entrega, exigindo código de baixa qualidade pra se ter a percepção de produtividade… enfim, sendo apenas o gerente que tanto odiamos. Você tem duas opções nesse caso:

Não faça nada, apesar trabalhe, afinal vai acabar logo esse projeto. E viva na miséria de sua existência, estressado e descontente com o trabalho que está realizando… quem sabe uma úlcera surge pra te fazer companhia. Com certeza é o mais fácil a se fazer. Ou você pode:

Usar o seu trabalho para mostrar o quão importante é mudar esta postura, apresentando resultados e convencendo a todos sobre a melhor forma de trabalho. Faça alguma coisa! PQ não começar tendo uma conversa franca com o tal gerente sobre as implicações de não se preocupar com a entrega no projeto? Ou mostrando o quanto custa não construir software com qualidade. Comece você mesmo a escrever testes automáticos escondido, e meça o quanto isso representa em redução de bugs nas partes que você trabalha no projeto. Quem sabe colocar um servidor de integração continua clandestino e apresentar essa idéia para a equipe de produtos? Quem sabe encontrar outras possibilidades de atuação dentro desse projeto, que tornarão o seu trabalho muito mais efetivo, além de mais divertido?

Sendo uma consultoria, a Lambda3 participa de vários projetos. Isso significa: os bons projetos, e os projetos péssimos. Uma coisa é clara: todos os projetos tendem ao caos, e a forma como encaramos o trabalho vai guiar muito dos resultados. Se tivermos uma mentalidade deterministica (ah! esse cliente não sabe ser ágil, o projeto está perdido), com certeza esse cliente terá uma experiência horrível. Agora, quando nosso trabalho se estende além da entrega de software, isto é, utilizando a melhoria contínua inclusive para guiar nossa relação com o cliente, os problemas são sempre resolvidos sem que um dos lados saia traumatizado. Um descuido, seja por preguiça ou conflito, e toda a relação de confiança e companheirismo com o cliente passa para discussão de contratos, eternas reuniões de Cover your Ass e ambos os lados insatisfeitos. O “projeto bom” vira uma porcaria, e o péssimo, sempre pode ficar pior…

O ponto mais positivo que o desenvolvimento ágil nos trouxe na indústria de software não foi o JUnit, ou o TDD, ou Planning Poker. Estamos colhendo os frutos através da autonomia e auto organização dos times. É o momento de estarmos mais cientes das implicações disso em nossos projetos: Sendo autônomo, você tem a opção de questionar, sugerir e mudar, desde que esteja disposto a assumir as consequências de seu trabalho – assim como apresenta o software funcionando no final de uma sprint.

Sua capacidade de trabalhar em projetos de maneira saudável e consciente de todas as restrições, é o que vai fazer de você um profissional melhor. Adaptar-se à situação e influenciá-la para o melhor está somente em suas mãos.