Mesmo com sua adoção crescendo ano a ano e comprovadamente trazendo ganhos de produtividade para projetos de desenvolvimento, metodologias ágeis ainda encontram bastante resistência e ainda tem uma adoção relativamente pequena aqui no Brasil. Existiria então uma forma mais indicada de transição para uma abordagem ágil de acordo com as características de cada ambiente?
O Mike Cohn documentou alguns padrões interessantes para adoção de agilidade e os dividiu em três pares antagônicos que são:
- Start Small ou Go All In?
Começar a adoção com um projeto piloto ou já começar com a grande maioria dos projetos da empresa?
- Technical Practices First ou Iterative First?
Focar primeiramente nas práticas de engenharia ou nas práticas de gestão?
- Stealth Mode ou Public Display of Agility?
Serão esperados os primeiros resultados para que a adoção seja tornada pública ou ela será divulgada de ante mão?
Dentre estes padrões, o caminho mais seguro e menos traumático é a combinação de Start Small, Technical Practices First e Stealth Mode. Foi essa combinação que funcionou muito bem em meu emprego anterior e, encontrando as mesmas condições, tentaria adotá-la em qualquer outro ambiente.
Adotando Start Small e Technical Practices First não se precisa de tanto apoio das hierarquias superiores e conseqüentemente pode-se atuar sob Stealth Mode. Como, até meio que paradoxalmente, as hierarquias superiores são as que menos conhecem e mais resistem às abordagens ágeis, o time pode evoluir sem encontrar muitas resistências nos estágios iniciais e, principalmente, sem ser talhado pela equipe de “qualidade”. Claro que vai chegar um momento em que o apoio será necessário, porém os resultados já alcançados servirão de prova de que desenvolvimento ágil não é coisa de adolescente frustrado ou programador revoltado.
Essa combinação, no entanto, possui um lado negativo considerável: é a mais lenta. Adotando-a, demoramos em torno de três anos para que começássemos a ter um impacto organizacional mais abrangente (demora também ocasionada pelo tamanho da empresa), mesmo resultados positivos tendo estado presentes desde os primeiros meses. E a razão da sua vantagem é também o motivo da sua desvantagem. Sem o apoio corporativo, o time pioneiro sente dificuldades de levar a adoção adiante e depende muito de esforços homéricos dos envolvidos para que as dificuldades naturais da adoção não comprometam o andamento do(s) projeto(s), gerando ruídos e quebrando o Stealth Mode.
Seria então está combinação a mais indicada para todos os ambientes? Acredito que não. Algumas forças devem estar presentes para que esta combinação seja a mais indicada:
-
Já existe na empresa um processo de desenvolvimento “tradicional” bem estabelecido e controlado. Geralmente em empresas que tem ou buscam o selo CMMI e que acabam considerando abordagens ágeis uma ameaça para o processo de avaliação e controle de “qualidade”.
-
O time tem um perfil técnico muito bom, os membros são proativos e comprometidos na busca de melhores formas de desenvolver software.
-
Os integrantes do time devem, em grande parte, se manter constantes.
Aqui na SEFAZ, por termos outro cenário (com vantagens e desvantagens) estamos adotando outra estratégia, mais próxima da combinação Start Small, Iterative First e Public Display of Agility. O padrão Go All In traria resultados ainda mais rápidos, mas acho demasiadamente arriscado. O ponta pé inicial ainda não foi dado, mas estou animado com o comprometimento que estamos obtendo em todos os níveis e espero que em breve eu tenha boas notícias para dar.