Quando o Agile Se Tornou Aquilo Que Prometeu Matar

Circula com frequência no LinkedIn um conselho de coaching Agile já familiar: como devem os Scrum Masters responder quando as equipas dizem que o seu trabalho não cabe num sprint fixo.

O conselho é bem estruturado. Costuma citar pensadores Agile consagrados, usa analogias acessíveis e oferece frameworks práticas para gerir o âmbito dentro dos time-boxes. Enquanto conteúdo de coaching, é competente.

Mas levanta uma pergunta que merece mais atenção do que costuma receber: o que acontece quando uma metodologia desenhada para libertar equipas se torna precisamente aquilo de que essas equipas precisam de se libertar?

Breve História de Uma Rebelião

Em fevereiro de 2001, dezassete programadores reuniram-se numa estância de esqui no Utah e assinaram o que ficou conhecido como o Manifesto Agile. O documento era notavelmente curto — quatro declarações de valores e doze princípios. A sua essência era a rejeição de processos pesados, documentação excessiva, planeamento rígido, e do pressuposto de que os gestores sabem mais do que as pessoas que fazem o trabalho.

Era, em todos os sentidos que importam, uma rebelião. Contra a burocracia. Contra o comando-e-controlo. Contra a ideia de que cumprir o processo equivale a qualidade.

Vinte e cinco anos depois, o Agile tornou-se uma indústria global. Os programas de certificação cobram centenas — por vezes milhares — de euros por credencial. As consultoras oferecem projetos de «transformação Agile» que ascendem aos milhões. Construíram-se frameworks sobre frameworks: SAFe, LeSS, DAD, Nexus — cada uma acrescentando camadas de estrutura, papéis, cerimónias e governação a um movimento que nasceu do desejo de arrancar essas coisas.

Os rebeldes venceram. E depois construíram um império que se parece notavelmente com aquilo que derrubaram.

A Armadilha da Cerimónia

Considere-se uma implementação típica de Scrum num ambiente empresarial.

Há uma reunião de planeamento de sprint. Um stand-up diário. Uma revisão de sprint. Uma retrospetiva. Uma sessão de refinamento de backlog. São as cerimónias prescritas — e em muitas organizações tornaram-se exatamente isso: cerimónias. Realizadas porque o processo as exige. Frequentadas porque a ausência se nota. Facilitadas porque alguém detém o título que obriga à facilitação.

O stand-up que devia ser um pulso rápido de coordenação torna-se um relatório de estado de quinze minutos para observadores da gestão que não deviam ali estar. A retrospetiva desenhada para a reflexão honesta torna-se um teatro de feedback cuidadosamente redigido onde o que realmente correu mal fica por dizer, porque o quadro do Jira está projetado na parede e tudo é rastreável. A revisão de sprint torna-se uma demonstração para stakeholders cujas prioridades já estavam fechadas antes de o sprint começar.

Os rituais sobrevivem. O propósito que os sustentava erode-se em silêncio.

Isto não é uma falha das pessoas que realizam as cerimónias. É um resultado estrutural de industrializar algo que foi desenhado para ser adaptativo. Quando uma prática se torna obrigatória, deixa de ser uma escolha. Quando deixa de ser uma escolha, deixa de ser ágil — por definição.

O Paradoxo da Autonomia

O post que despoletou esta newsletter fez uma observação importante: prazos fixos só prosperam com autonomia da equipa. É verdade. É também, na maioria das implementações empresariais, ficção.

Autonomia genuína da equipa significa que a equipa decide o que construir, como construí-lo, e como se organizar para o fazer. A fronteira do sprint fornece o constrangimento; a equipa fornece a solução.

O que realmente acontece na maioria das organizações é subtil mas fundamentalmente diferente. O Product Owner chega ao planeamento do sprint com uma lista que foi moldada — por vezes ditada — por prioridades da gestão, pressão de stakeholders, ou compromissos de roadmap feitos meses antes. A equipa «estima» com story points — uma unidade de medida tão abstraída da realidade que há palestras inteiras de conferência dedicadas a debater o que significa. O sprint é «planeado» de forma colaborativa, mas o resultado estava em larga medida predeterminado antes de alguém entrar na sala.

A equipa tem autonomia sobre como implementar. Raramente tem autonomia significativa sobre o quê implementar ou se o trabalho está adequadamente dimensionado para o time-box. E quando o sprint termina e o trabalho não está feito, a conversa tende a centrar-se na exatidão da estimativa ou na velocidade da equipa — não em se o âmbito era razoável ou se os constrangimentos eram realistas.

Autonomia dentro de um âmbito predeterminado, medida contra expectativas definidas do exterior, facilitada por alguém cujo desempenho é avaliado pela adesão da equipa à framework. Isso não é autonomia. Isso é delegação com monitorização.

O Papel Que Perdeu o Seu Propósito

O papel do Scrum Master, tal como originalmente concebido, tinha valor genuíno. Um líder-servidor que remove impedimentos, facilita a colaboração, protege a equipa da interferência externa, e ajuda a organização a perceber onde os seus próprios processos estão a criar atrito.

Na prática, o papel derivou. Em muitas organizações, o Scrum Master tornou-se um administrador de cerimónias — a garantir que o stand-up acontece, que o quadro está atualizado, que o gráfico de velocidade está em dia, que as ações da retro ficam registadas. O valor mede-se pela adesão ao processo: os sprints estão a correr no prazo? As cerimónias estão a acontecer? A equipa está a seguir a framework?

Não foi para isto que o papel foi desenhado. Mas é o que a estrutura de incentivos produz. Quando uma organização mede a «maturidade Agile» pela proximidade com que as equipas seguem as práticas prescritas, a pessoa responsável por essa maturidade gravita naturalmente para impor as práticas em vez de questionar se as práticas estão a servir a equipa.

O Scrum Master que diz «talvez esta equipa não devesse estar a fazer sprints de duas semanas» está a desafiar a framework que foi contratado para implementar. O Scrum Master que diz «estas cerimónias não estão a acrescentar valor» está a questionar os rituais que é responsável por facilitar. O Scrum Master que diz «esta equipa na verdade trabalha melhor com uma abordagem diferente» está a minar a padronização que a gestão quis com a transformação Agile.

O papel foi desenhado para ser um catalisador de mudança. A estrutura fez dele um guardião da conformidade. Não por malícia, mas por alinhamento de incentivos.

A Economia da Certificação

Vale a pena deter-se na economia.

Um curso de Certified Scrum Master custa tipicamente uma quantia de quatro algarismos por um programa de dois dias. As certificações SAFe custam mais. Aplicam-se taxas de renovação. As certificações avançadas exigem cursos adicionais. O mercado de formação, coaching e consultoria Agile é, por qualquer medida plausível, substancial.

Nada disto é intrinsecamente errado. Profissionais de todas as áreas investem em credenciais. Mas cria um ecossistema em que um número significativo de pessoas tem um interesse profissional e financeiro na adoção e expansão continuadas destas frameworks. Quando alguém com uma certificação de SAFe Program Consultant avalia se uma organização precisa de SAFe, a resposta é estruturalmente previsível.

É o mesmo ciclo autovalidante que existe na arquitetura empresarial. A metodologia é promovida pelas pessoas certificadas na metodologia, avaliada pelas pessoas formadas na metodologia, e medida pelas métricas que a metodologia define. Em momento nenhum entra uma voz independente com a autoridade para perguntar: esta framework está de facto a produzir melhores resultados do que aquilo que substituiu?

A resposta incómoda é que, em muitos casos, a resposta não é clara. Porque as métricas em uso — velocidade, taxa de conclusão de sprints, cumprimento de cerimónias — medem a adesão ao processo, não o valor entregue pelo processo.

Quando a Equipa Resiste

Isto traz-nos de volta ao gatilho original: equipas a dizer que o seu trabalho não cabe num sprint fixo.

A resposta-padrão do coaching é tratar isto como uma lacuna de competências. A equipa precisa de aprender a fatiar melhor. A estimar melhor. A gerir melhor o âmbito. A framework não é o problema — a adaptação da equipa à framework é que é o problema.

Por vezes isto é verdade. O trabalho pode muitas vezes ser decomposto de forma mais eficaz do que as equipas inicialmente acreditam.

Mas por vezes — e esta é a parte que raramente se explora — a equipa tem razão. Algum trabalho é genuinamente exploratório. A análise de causa-raiz num sistema de vinte anos não se decompõe de forma limpa em incrementos de duas semanas. A investigação, o inquérito e o diagnóstico complexo têm ritmos que são inerentemente imprevisíveis. Forçá-los para dentro de time-boxes fixos não aguça o foco — cria uma pressão artificial para produzir conclusões prematuras.

O primeiro princípio do Manifesto Agile é «indivíduos e interações acima de processos e ferramentas». Quando uma equipa de profissionais experientes diz que o processo não serve o seu trabalho, responder com «têm de se adaptar ao processo» é o oposto de ágil.

Ouvir esse feedback, investigar genuinamente se a framework serve o trabalho e não o contrário, e ter a coragem de adaptar o processo às pessoas — isso é ágil. Todo o resto é cumprimento de metodologia vestido com roupa de ágil.

As Condições Que Recuperam os Valores Originais

As organizações que recuperam os valores originais, quando o fazem, tendem a partilhar três propriedades estruturais. Medem resultados em vez de cerimónias — perguntando o que o trabalho entregou em vez de se os rituais foram realizados. Tratam a resistência da equipa como dado diagnóstico e não como um problema a ultrapassar — reconhecendo que, quando profissionais experientes dizem que uma framework não serve o seu trabalho, a objeção contém informação. E permitem que a própria framework, e não apenas a execução dentro dela, seja questionada. Onde estas condições faltam, a metodologia sobrevive intacta enquanto o valor que era suposto entregar se erode em silêncio.

O Essencial

O Agile, enquanto conjunto de valores, mantém-se sólido. Priorizar as pessoas sobre o processo. Responder à mudança. Entregar resultados que funcionam. Colaborar. Refletir. Adaptar.

O Agile, enquanto indústria, tornou-se algo que os seus fundadores dificilmente reconheceriam. Uma economia de certificação, um mercado de consultoria, um conjunto de cerimónias prescritas, e uma ortodoxia onde questionar a framework é tratado como uma incapacidade de a compreender.

A ironia é precisa e dolorosa: uma metodologia nascida da rejeição do processo rígido tornou-se um dos processos mais rigidamente impostos na empresa moderna. E às pessoas mais qualificadas para o apontar — os profissionais experientes que fazem o trabalho real — dizem-lhes que a sua resistência é um equívoco que precisa de coaching.

Talvez. Ou talvez sejam eles que ainda estão a ouvir o manifesto original — a parte que diz indivíduos e interações acima de processos e ferramentas.

A pergunta que vale a pena deixar assentar é simples: ainda estamos a ser ágeis, ou estamos apenas a fazer Agile™?