Quando as abordagens ágeis foram criadas, desenvolver software era uma atividade totalmente humana. As pessoas escreviam código, faziam testes, documentavam, integravam componentes, corrigiam erros e tudo isso levava tempo. Os sprints surgiram como uma forma de organizar esse trabalho - um período de uma a duas semanas - que permitia planear, desenvolver, avaliar o que foi entregue e auditar a própria forma de trabalhar numa lógica de melhoria contínua, até se atingir a máxima velocidade possível. Rituais que, apesar do dinamismo e da rapidez na entrega de valor, impediam que a equipa multidisciplinar estivesse sempre a ser interrompida ou a ver as prioridades alteradas, ao mesmo tempo que davam alguma previsibilidade.
Numa reflexão anterior escrevi sobre como a IA está a mudar o dilema de "construir ou comprar" no setor público. O ponto era que a IA reduz a fricção entre quem entende o problema e quem consegue materializar uma solução e que, com isso, a dificuldade real desloca-se para o desenho, para a arquitetura e para a governação. Quero agora passar da componente estratégica para a dimensão operacional da transformação e perceber o que acontece à gestão dos projetos quando essa aceleração chega ao terreno.
A produção deixou de ser o gargalo
Toda a estrutura de cerimónias que conhecemos, o planning, a daily, a review, a retrospetiva, foi desenhada à volta do constrangimento de que desenvolver era caro e lento. Se uma funcionalidade demora dias ou semanas a ganhar forma, é razoável planear em blocos, proteger a equipa de mudanças constantes de prioridade e criar momentos formais para mostrar o que foi feito e recolher feedback. Estes princípios são bons, foram testados e funcionam, não quero dizer que estão errados, mas o contexto mudou e é legítimo perguntar se estes rituais continuam a ser aplicáveis.
Hoje um agente de IA consegue escrever uma funcionalidade, criar os testes, rever o código e sugerir melhorias em minutos. Quem trabalha com estas ferramentas no dia-a-dia sabe que isto não é uma promessa de futuro, é a realidade atual - com nuances que convém não esconder. Esta velocidade é sobretudo verdade quando se desenvolve de raiz. Quando há sistemas legacy para integrar, validações de segurança, ambientes controlados e arquiteturas de referência que impõem separação entre componentes e equipas, as coisas não perdem a sua complexidade, até porque num sistema de grande dimensão a produção de uma funcionalidade pode ser rápida e tudo o resto à volta continuar lento.
Mas é justamente por isso que o ponto se mantém. O custo de produzir uma primeira versão funcional caiu de forma drástica e, quando uma parte do processo acelera assim, os pressupostos sobre os quais as cerimónias foram desenhadas deixam de se verificar. Continuar a gerir como se escrever software fosse o passo mais caro do processo, quando já não é, é gerir com um mapa desatualizado.
Sinto isto na prática, há alturas em que a velocidade na resolução de problemas e no desenvolvimento de funcionalidades é tão rápida que parece que estamos só a fazer teatro, à espera do fim do sprint para apresentar formalmente aquilo que já está pronto, testado e validado há dias. Sprint plannings onde se discute se "temos capacidade" para desenvolver determinadas funcionalidades quando toda a gente na sala sabe que capacidade não é o problema. Reviews que mostram trabalho que já toda a gente viu.
Na equipa já deixámos de fazer story points e categorização da dimensão das tarefas, não por discordarmos da metodologia mas porque deixou de medir alguma coisa útil. Estimar esforço fazia sentido quando o esforço humano de execução era o recurso escasso a gerir, agora que uma parte significativa da execução é feita ou amplificada por agentes, no tempo que levaríamos a estimar uma funcionalidade o desenvolvimento já está feito.
Nada disto quer dizer que as cerimónias sejam inúteis. A daily continua a servir para alinhar pessoas e a retrospetiva continua a ser dos melhores instrumentos para melhorar a forma como se trabalha. O problema aparece quando a cadência fixa, desenhada para proteger um fluxo de trabalho lento, passa a impor esperas artificiais a um fluxo que já não é lento. Esperar duas semanas para rever uma funcionalidade que ficou pronta em vinte minutos é contrário aos próprios princípios do agile de entrega rápida de valor.
Para onde se deslocou o esforço
Num programa de grande dimensão, com várias equipas e módulos que têm de funcionar em conjunto, aquilo que hoje nos consome mais tempo e energia não é o desenvolvimento das funcionalidades. É o alinhamento entre módulos transversais e entre equipas, é o release management, é saber onde foram feitas alterações e garantir que os vários ambientes, configurações e pipelines estão coerentes entre si. A curva de esforço deslocou-se da produção para a coordenação, para a integração e para a decisão.
Na prática, equipas mais pequenas com grande capacidade de entrega são muito mais fáceis de coordenar do que equipas grandes. Com a capacidade de produção que a IA dá a cada pessoa, ter demasiada gente num projeto deixou de ser sinónimo de velocidade e passou a ser, muitas vezes, sinónimo de entropia - mais dependências, mais alinhamentos, mais confusão sobre quem mexeu em quê.
Chamam a esta nova forma de trabalhar agent driven development, ciclos contínuos em que o requisito entra, um agente implementa, outro testa, um terceiro revê, o sistema faz deploy, monitoriza, gera feedback e imediatamente um novo ciclo começa. Se a execução tende para o contínuo, a gestão por blocos fixos de tempo deixa de fazer sentido.
O gargalo passou a ser a decisão. Decidir o que construir e o que é prioridade, validar resultados, garantir qualidade, gerir risco. A velocidade de execução aumentou mas a velocidade das decisões continua a ser humana, e o foco do gestor de projeto também tem de mudar. Em vez de perguntar quem vai executar uma atividade, passa a decidir o que merece ser executado e se o resultado é de confiança. Em vez de controlar tarefas, orquestra fluxos. Em vez de acompanhar horas de trabalho, acompanha a qualidade das decisões e dos resultados. Em vez de gerir os elementos da equipa de projeto, passa a gerir "acima" - o project sponsor, o steering committee, quem quer que tenha o poder de decidir.
Reinventar sem deitar fora
Afasto-me de quem declara a morte tanto do agile como da gestão de projetos como um todo. Os princípios não só continuam válidos como me parecem mais atuais do que nunca. Entregar valor cedo e continuamente, trabalhar com MVPs que ajudam a identificar o caminho antes de investir tudo numa direção, ciclos curtos de feedback, adaptação em vez de planos rígidos - num mundo em que as coisas mudam tão depressa que não nos podemos basear no passado para preparar o futuro, esta lógica é ainda mais necessária.
O que está em causa são as práticas que ficaram presas ao contexto em que nasceram. O sprint de duas semanas, os story points, a cadência fixa de cerimónias, tudo isso foi desenhado para gerir um recurso escasso que está a deixar de o ser. Não sei exatamente com o que se substitui a estrutura de sprints num contexto de execução quase contínua, nem onde fica a linha entre adaptar as práticas e deitar fora disciplina, porque as cerimónias também servem para alinhar pessoas e as pessoas continuam a precisar de alinhamento. O que sei é que o futuro da gestão de projetos passará sobretudo por aquilo que é estritamente humano - o julgamento, a decisão, a gestão da mudança, o risco - menos na vertente de análise e processamento de informação, onde os agentes fazem cada vez mais, e mais na de interação humana de perceber quando é altura de mudar de rumo ou de parar um projeto, influenciar, negociar, levar as pessoas a acompanhar o ritmo da mudança. Eliminar a daily não elimina a necessidade de saber o que se passa. A questão é se esse alinhamento precisa de um ritual em cadência fixa ou se pode acontecer de forma contínua, como a própria execução.
Talvez o futuro da gestão ágil não seja abandonar o agile mas reinventá-lo para equipas compostas por pessoas e agentes de IA a trabalhar em conjunto - manter os princípios, questionar as práticas e aceitar que algumas cerimónias que durante anos foram sinónimo de bom método podem estar a tornar-se ritual. O sprint era uma resposta a um problema que está a desaparecer. Num mundo onde a execução tende a ser praticamente instantânea, o que continua verdadeiramente escasso é o julgamento humano, decidir bem o que construir, para quem e porquê.