Ainda lembro como se fosse há poucos meses, mas foi no começo de 2005 que uma acalorada discussão começou a crescer pelos corredores da CI&T. Falava-se com apaixonada eloquência sobre uma nova forma de se desenvolver software que estava amadurecendo no mercado americano desde 2001: Agile Software Development. Sabíamos que havia grandes chances de sofrermos uma forte disrupção no processo altamente controlável que vínhamos utilizando por mais de seis anos para desenvolver software para grandes empresas. Bateu um medo…

Até então, éramos mestres no processo formal chamado RUP (Rational Unified Process), uma implementação de sucesso das ideias pioneiras do conhecido framework Unified Process. Nosso discurso era bem estruturado e atacava o método waterfall, que vinha destruindo a reputação das empresas de software por anos a fio. Estudos mostravam que, consistentemente, mais de 65% das grandes implementações de sistemas falhariam. Já pensou se 65% de tudo o que você faz fosse considerado perda de tempo e dinheiro?

Hoje podemos falar sem qualquer sofrimento que 100% de nossos projetos são realizados usando Ágil, mas naquela época de transição estávamos bastante incertos sobre o futuro. A certificação mais valiosa que já conquistamos, o CMMI nível 5, passaria a perder seu brilho no mercado. E o conjunto enorme de processos muito bem detalhados que havíamos definido para alinhar times e clientes em torno de objetivos de negócio e frentes de trabalho teria que sofrer adaptações profundas. Mas nossos clientes estavam demandando que usássemos Ágil e decidimos pular no desconhecido como naquela situação do filme The Matrix em que Neo precisa decidir pela pílula azul ou vermelha. No nosso caso, a pílula vermelha era a única opção.

Em 2006, entregamos nosso primeiro projeto 100% Ágil. Nem tudo foram flores, tivemos muita dificuldade para “largar mão” de coisas do RUP que estavam enraizadas em tudo o que fazíamos. Mas nada resiste ao reforço positivo, e em pouco tempo já havíamos reinventado nossa a maneira de desenvolver software e adotado com paixão o Agile Manifesto.

Grandes empresas são um terreno difícil para novas ideias que trazem incertezas, mesmo que também tragam promessas de grandes ganhos. E temos que admitir que no começo nós interpretamos o manifesto de maneira muito literal. Havíamos nos tornado fundamentalistas e queríamos seguir à risca o que acreditávamos, mesmo que isso significasse empurrar goela abaixo os novos conceitos para alguns de nossos clientes.

Mas quando crescemos de algumas centenas de funcionários para mais de 500 e depois para mais de 1000 e nossos projetos se tornaram todos grandes projetos em grandes empresas, fomos acordando para uma cruel realidade. Estávamos nos enganando sobre tentar seguir o manifesto de maneira tão literal. Tornamo-nos mais frágeis do que ágeis, e era chegado o momento de levar em consideração a escala e as restrições das grandes empresas. Um dos maiores desafios era promover alinhamento em diferentes níveis e tomar decisões rapidamente, mantendo o alinhamento com os objetivos de negócio em um ambiente onde é simplesmente impossível reunir todos os participantes em reuniões diárias.

Fazendo uma rápida revisão das distinções feitas pelo manifesto que diz “enquanto há valor nos itens da direita, valorizamos mais os itens da esquerda”, chegamos a algumas conclusões interessantes.

1. Indivíduos e interações em vez de ferramentas e processos

Existe uma beleza intrínseca em permitir que times autogeridos possam se aventurar com autonomia para desenvolver user stories em colaboração com um product owner. Isso funciona muito bem para startups, mas em grandes empresas a falta de alinhamento em diferentes níveis geralmente gera mais calor do que resultados. A CI&T traz uma visão holística para o assunto e estende o conceito de times para diferentes áreas da grande empresa a fim de construir consenso, antes e durante os projetos. É fundamental o uso de ferramentas para esse fim e há várias gratuitas, como o Trello. Descobrimos também que Desenho de Experiência de Usuário (UX design) é uma ferramenta muito poderosa para alinhamento de expectativas entre áreas de negócio, mesmo que haja agências responsáveis executá-lo. Mapear a experiência do usuário deveria ser preocupação de todos, pois não existe bom software se essa experiência for insatisfatória.

2. Software que funciona em vez de documentação detalhada

Nem todo mundo percebeu o quão transformador este mindset foi para a indústria de software. As startups intuitivamente abraçaram essa causa. Afinal, elas não podem se dar ao luxo de produzir documentações extensas em detrimento de produzir software que as pessoas possam usar. E o dinheiro é muito limitado. Dentro de grandes empresas, no entanto, existia um padrão irracional de valorizar documentação que precisava mesmo ser desafiado. Mas o outro extremo é que agilistas radicais podem acabar arruinando a estratégia de disseminação da API de um produto que depende justamente de excelente documentação para poder ser adotado.

3. Colaboração com clientes em vez de negociações contratuais

Funcionários de grandes empresas onde a tecnologia é considerada estratégica são muito mais flexíveis ao estabelecer diferentes modelos contratuais com seus parceiros de desenvolvimento. As empresas, no entanto, não podem se dar ao luxo de contratar times sem visibilidade de prazos e custos, ou mesmo sem entender a produtividade do time que as está servindo. A esmagadora maioria dos agilistas radicais vai fazer de tudo para provar que produtividade não deve ser medida em times ágeis. Mas como conseguimos melhorar algo que não se mede? E, ainda mais importante, como é possível se adaptar às mudanças rápidas trazidas pela tecnologia sem adaptar processos?

4. Responder a mudanças em vez de seguir planos

Independentemente de seus tamanhos, as empresas precisam responder rapidamente às mudanças de mercado. Desenvolver software com agilidade pode fazer, para muitas, a diferença entre vida e morte. Em grande empresas, no entanto, a necessidade de se seguir um plano é também muitas vezes uma questão de vida ou morte: muitos projetos podem ter seus orçamentos corroídos por um excesso de mudanças não controladas. Value Engineering é uma das ferramentas mais eficazes para trazer um planejamento às mudanças que naturalmente ocorrem em projetos de software.

Se você já ouviu uma ou mais das frases abaixo de um agilista, você deve se perguntar se não está perante um fundamentalista, ou que chamei anteriormente de agilista radical:

• “Desenvolvimento de software é uma arte e arte não pode ser medida”.

• “A funcionalidade estará pronta quando ficar pronta. Projeções feitas por gerentes de projeto não servem para nada, estamos adicionando valor com a maior velocidade possível”.

• “Medidas de produtividade e métricas em geral são coisas do passado, importadas dos processos de produção em massa. São artifícios usados pelos gerentes para tirar o sangue dos desenvolvedores”.

• “Os times vão encontrar um jeito de provar que estão sendo produtivos, mesmo que não estejam”.

• “Não podemos fazer um projeto com preço fechado porque seria impossível acomodar mudanças sem longas discussões contratuais”.

Essas e muitas outras pérolas são mitos que não resistem a boas perguntas.

Métricas podem ser usadas para medir processos em vez de pessoas, e produtividade deveria ser medida e monitorada pelos próprios times. Um time incapaz de medir sua performance, e entender o que a afeta, nunca vai conseguir melhorar continuamente.

Como aprendemos ao chegar ao patamar de 1200 pessoas (agora somos quase 1700), os princípios lean contêm o arcabouço filosófico e o conjunto de ferramentas ideais para uma implementação de Ágil que faz sentido para grandes empresas, seja com SCRUM, XP, ou qualquer outra metodologia. Lean foi nossa chave para superar as armadilhas de uma interpretação radical do manifesto Ágil e escalar times ágeis em grandes projetos para empresas enormes, como Johnson & Johnson, Pfizer e Coca-Cola, entre outras. Sentimos orgulho de agora sermos evangelistas em Lean Agile Enterprise em vez fundamentalistas. Nossos clientes estão felizes e satisfeitos por observarem entregas com qualidade e produtividade nunca antes experimentadas em desenvolvimento de software.

Não somos os únicos a notar essa movimentação. Dave Thomas, um dos fundadores do manifesto, recentemente escreveu no seu blog que deveríamos abandonar o termo “Agile”. Na minha opinião, só precisamos saber distinguir os evangelistas dos fundamentalistas.