Ep. 136 - Agilidade fora dos holofotes

Cauê é um dos executivos de inovação na NTT Data Brasil, onde lidera uma iniciativa global de descoberta de novas tecnologias e aplicação a clientes. Miguel Sotti é Head de Tecnologia da Halian no Brasil, uma spin-off da GSK, que por sua vez é spin-off da Pfizer. Ambos começaram a jornada ágil juntos e hoje trabalham com o tema em contextos diferentes.

A agilidade surgiu na vida deles para resolver um problema concreto: um projeto muito grande, com pouca visibilidade de entrega, que já tentava ser implementado havia pelo menos quatro ou cinco anos sem sucesso. Era um projeto que mudava o processo de produção de um negócio quase de ponta a ponta, muito complexo, e a equipe tentava cascatear as coisas sem que nada andasse. Em 2014, alguém da equipe do fornecedor levantou a bandeira de fazer o projeto em ágil. Ninguém na empresa conhecia o método de fato. Cauê e Miguel se fecharam numa sala, pegaram PDFs sobre ágil, estudaram em conjunto, exercitaram o que era uma sprint, e estruturaram o projeto. A primeira expectativa era de mais sete anos para implementação. Cauê levou uma pastinha debaixo do braço até o CIO e pediu uma aposta: cinco anos sem resultado, e a projeção era de mais sete. A analogia que ele usou foi a do Waze: você dá o destino, e a cada interação a rota é ajustada, medindo exaustivamente se vai chegar às dez, às nove e cinquenta ou às dez e meia. Antes, não havia métrica nenhuma de execução, era tudo no achismo do cascata tradicional.

O resultado foi de dois anos e sete meses, menos da metade do previsto. Nesse meio caminho, aprenderam que estimativa ágil é sempre de pior caminho. A alta frequência de interação e revalidação de escopo fez com que o que realmente era prioridade entrasse em primeiro lugar e o que era perfumaria fosse descartado. A taxa de desperdício do backlog ficou em torno de 27%. Na quinta sprint, começaram a fazer releases de features de verdade para as pessoas usarem, e a coisa estabilizou. Mas teve cancelamento de sprint, teve sprint entregue com zero pontos. O primeiro desafio foi acreditar na equipe e chegar ao nível executivo dizendo que o jeito antigo não estava funcionando. O segundo desafio foi lidar com os promotores detratores que diziam que não ia dar certo. A equipe era muito independente, não dependia de ninguém para implantações, o que evitou o viés estruturante da empresa. Tiveram um Product Owner de verdade, uma pessoa de negócio que ficava cem por cento da sprint com a equipe, ensinando como as coisas funcionavam. O pior que pode acontecer num projeto ágil é ter um proxy PO que não entende nada e só passa recado. O projeto foi de implementação de uma solução SaaS, sem desenvolvimento essencial, o que era muito incomum para ágil na época.

Depois do projeto, a empresa implementou ágil em quase tudo. Cauê levou a experiência para outros departamentos e depois para a GSK e a Halian. Miguel colocou a agilidade no DNA e começou a carregá-la para os lugares onde trabalhava. Na Halian, ele não faz um projeto que não seja ágil. A primeira coisa que fez foi mostrar ao negócio e aos POs o que é ser um PO de verdade, cem por cento dedicado. A tese se provou: quando abria concessão para fazer do jeito do negócio, não dava certo e voltava ao formato ágil. Ele também trabalha com a diferença entre projeto e produto, que a maioria das pessoas acha ser só semântica, mas são coisas completamente diferentes. Ser ágil na tomada de decisão, na alocação de recursos, na estratégia, é tão importante quanto ser ágil na execução. Autonomia e disciplina são fundamentais. Sem autonomia, as dependências são infinitas.

Cauê, que foi Agile Coach sem certificação por um ano antes de tirar PSM, PMA-ACP e SAFE, cuidou de 24 squads ao mesmo tempo e viu muito o problema de daily meeting a cada dois dias em vez de todo dia. Hoje, na NTT Data, ele gerencia o laboratório de inovação com Kanban Portfolio Management, Value Stream Mapping e SAFE. A equipe nunca trabalhou com waterfall e se adapta bem a diferentes métodos: Kanban, Scrum, design sprint, dependendo do valor e do enquadramento do cliente. Na área de inovação, pesquisa e desenvolvimento de tecnologia, 85 por cento das coisas dão errado, o que torna o cascata inviável. A cultura ágil mudou o jeito de pensar de Cauê: fazer engenharia de valor, questionar se realmente precisa de algo, dividir a vida em períodos menores, não planejar muito longe porque sabe que vai dar errado, o que diminuiu até a ansiedade.

Miguel aponta que o grande problema da maioria dos projetos, ágil ou cascata, é a utopia de que o ser humano é capaz de fazer mais de uma coisa ao mesmo tempo. Quando você divide o tempo entre diversas atividades, o resultado é que não se faz nenhum bem. A exclusividade das pessoas no projeto é o grande calcanhar de Aquiles. O projeto ágil tem uma simplicidade de execução: não precisa de pessoas tão especialistas para gerenciar. A velocidade é medida pela equipe naquele projeto específico, não por aproximação de projetos anteriores. Não adianta enfiar 70 pontos numa sprint se historicamente nunca se fez 70, sem mudar nenhuma condição do projeto.

Sobre a comunidade de agilidade, Cauê se distanciou dos meetups por achar a comunidade superficial, optando por bibliografias, livros e cases, priorizando a troca de experiência da trincheira. Miguel está completamente fora dos holofotes, aprende na prática, evangeliza internamente e só se certificou em Scrum Master e Product Owner recentemente para verificar se estava atualizado. O primeiro projeto que Miguel participou foi em 2011, com XP, antes de Scrum ser divulgado, sem Jira, sem Team Foundation Server com Scrum. A contribuição dele é nos bastidores, garantindo que o time execute de forma ágil e agregando valor nos níveis executivos. Ser ágil não significa ser irresponsável: significa colocar as pessoas certas nos lugares certos rapidamente, tomar riscos conscientes, e completar o framework com mapeamento de riscos e outras práticas que as certificações não ensinam.

Outro ponto essencial é o Product Adoption: não basta entregar um incremento, é preciso medir se está gerando valor ao longo do tempo. Se uma feature deixa de gerar valor, ela é substituída. A maturidade de adoção de cada feature precisa ser individualizada, usando escalas como o CMMI. Existe também o mito de que a cada sprint se entrega software em produção; na verdade, entrega-se um software que potencialmente pode ser liberado, e a estratégia de produto faz com que features sejam acumuladas para lançamento no momento certo.

Se pudessem se dar um conselho no início da jornada, nenhum dos dois mudaria nada. Cauê diria que não criaria atalho, veria o outro cowboy passar do outro lado da rua cansado e daria risada. Miguel diria apenas: por que você não começou antes? Para fazer uma loucura dessas, é preciso ter uma equipe em que se confia, que se joga do penhasco junto. O sistema expurga quem não está na mesma frequência. O recado final é: põe a mão na massa, vá num hackathon, tente liderar uma equipe na prática, com um livro embaixo de um braço e a prática embaixo do outro. É fail fast, errar rápido para aprender rápido. E se preocupar menos com certificação e mais com a capacidade de agregar valor no dia a dia, porque a certificação vem fácil depois.