Агиле-проекты: идеальные ритуалы не гарантируют реальных результатов

A gestão de projetos ágeis raramente falha na execução do ritual. Falha no momento em que o ritual passa a ser o resultado. O sprint tem velocidade. A entrega de valor, não tem necessariamente a mesma. A reunião de sprint review estava impecável. O líder abriu o painel: 43 de 45 histórias entregues, velocidade estável pelo terceiro sprint consecutivo, cerimônias realizadas sem exceção. Daily, planning, review, retrospectiva. Tudo no lugar. Tudo com data, com presença, com ata. Alguém da diretoria levantou a mão. “A funcionalidade principal que o cliente pediu há dois meses, quando entra?” Silêncio. Não porque ninguém soubesse a resposta. Mas porque a resposta não estava em nenhum dos slides Quando o Método Vira Destino O Agile foi criado em 2001 para resolver um problema específico: projetos de software que entregavam tarde, acima do orçamento e fora do escopo acordado, porque o processo de desenvolvimento estava desconectado da realidade do negócio. De fato, o Manifesto Ágil não foi escrito como defesa da metodologia. Foi escrito como crítica ao excesso de metodologia. “Software funcionando em vez de documentação abrangente.” “Responder a mudanças em vez de seguir um plano.” Essas são as palavras do manifesto original, de 2001. Ou seja, os criadores do Agile estavam combatendo exatamente o que muitos projetos ágeis de hoje reproduzem: processos que se perpetuam como fim em si mesmos. Além disso, existe uma ironia que merece nome. O líder que usa a metodologia como troféu está fazendo o oposto do que o manifesto pretendia. Está documentando o processo com rigor, seguindo o plano com precisão e celebrando a aderência à cerimônia como se fosse entrega. Afinal, “estamos sendo ágeis” e “estamos entregando valor” são duas afirmações diferentes. Nenhuma delas garante a outra. A Diferença Entre Velocidade e Progresso Na prática, velocidade de sprint mede quantas histórias o time completa por iteração. Essa é uma métrica de capacidade. Não é uma métrica de direção. Por isso, um time pode ter velocidade alta e estar indo rapidamente na direção errada. Pode completar histórias com consistência e não avançar um centímetro em direção ao resultado que o projeto existe para produzir. No entanto, a confusão entre as duas coisas não é acidental. Ela é conveniente. Velocidade é objetiva, mensurável e não ameaça ninguém. Você soma os pontos, divide pelo sprint, plota no gráfico e apresenta. Em contrapartida, progresso é subjetivo, exige critério e frequentemente expõe que o que está sendo feito não é o que deveria estar sendo feito. Contudo, o líder que mede o projeto pela velocidade e não pelo progresso não está ignorando a realidade. Está escolhendo qual realidade olhar. Assim, o burndown chart fica verde. O projeto não avança. O Ritual Que Aprimora a Coisa Errada Existe um padrão específico que vale nomear: a retrospectiva que aprimora o processo de fazer a coisa errada com mais eficiência. De fato, a retrospectiva é uma das cerimônias mais valiosas do Agile quando bem aplicada. O time olha para o sprint encerrado, identifica o que funcionou, o que não funcionou e define ações de melhoria. Sendo assim, quando a retrospectiva está desconectada da pergunta “estamos entregando o resultado certo?”, ela aprimora apenas a execução. Melhora o daily, planning. Melhora a comunicação interna. Na verdade, ela aumenta a capacidade do time de fazer aquilo que o projeto não deveria estar fazendo. Da mesma forma, o daily que funciona como relatório de status substitui o daily que funciona como ferramenta de alinhamento. Todo mundo diz “ontem fiz isso, hoje vou fazer aquilo, sem bloqueios.” O projeto trava. Ninguém nomeia o bloqueio porque o bloqueio não é técnico. É estratégico. Em suma, o ritual está perfeito. O projeto, não. Gestão de Projetos: O Que os Líderes Deveriam Perguntar Antes de avaliar se a metodologia está sendo bem executada, quatro perguntas mudam o nível da conversa: Em primeiro lugar: qual é a definição de sucesso deste projeto? Não do sprint. Do projeto. Se o líder não consegue responder em uma frase sem mencionar cerimônia, velocidade ou aderência ao framework, a resposta ainda não existe. Em seguida: a última funcionalidade entregue mudou alguma coisa para o usuário final? “Done” em Agile significa aceite da história. Não significa valor percebido pelo cliente. As duas coisas precisam ser medidas separadamente. Além disso: existe uma métrica de impacto acompanhada sprint a sprint, ao lado da métrica de velocidade? Velocidade sem direção é combustível sem destino. O que o projeto está tentando mover, e quanto moveu no último ciclo? Por fim: o que o time está evitando dizer no daily? O bloqueio que ninguém nomeia em voz alta é frequentemente o bloqueio que está travando o projeto. A cerimônia que funciona como performance de progresso é o sinal mais claro de que o projeto precisa de uma conversa diferente. Para Refletir A metodologia é útil exatamente enquanto ela serve ao resultado. No momento em que passa a servir a si mesma, ela deixa de ser instrumento e vira decoração. Portanto, o líder que apresenta velocidade de sprint numa sala onde ninguém pergunta sobre progresso não está gerenciando o projeto. Está gerenciando a percepção do projeto. Afinal, não existe framework que entregue resultado por adesão. O Agile não garante entrega. Garante visibilidade do trabalho. O que você faz com essa visibilidade é uma decisão de liderança, não uma consequência da metodologia. A gestão de projetos não falha por falta de cerimônia. Falha quando a cerimônia substitui a pergunta que ninguém quer fazer: o projeto está indo para algum lugar? ** Este texto não reflete, necessariamente, a opinião do Portal UAI.