A ritualização do Agile: quando as cerimônias perdem o sentido

A ritualização do Agile: quando as cerimônias perdem o sentido

Nos corredores sagrados das corporações ao redor do mundo, de gigantes multinacionais a startups ambiciosas, uma nova religião criou raízes. Seus sacerdotes ostentam notas adesivas coloridas (ou seu equivalente digital nos quadros do Jira) em vez de túnicas e títulos pomposos, e suas congregações se reúnem ao redor de lousas e quadros virtuais de Kanban ou Scrum, em vez de altares. Bem-vindos à Igreja do Agile, onde as reuniões diárias em pé substituíram as orações matinais, e as retrospectivas de sprint servem como nossos confessionários modernos.

Mas, como acontece com muitas religiões, será que perdemos de vista o verdadeiro significado por trás desses rituais?

Os textos sagrados e seus falsos profetas

Comecemos revisitando nossos textos sagrados. O Manifesto Ágil, assim como as escrituras antigas, estabeleceu princípios para uma forma melhor de trabalhar:

"Indivíduos e interações acima de processos e ferramentas. Software em funcionamento acima de documentação abrangente. Colaboração com o cliente acima de negociação de contratos. Responder a mudanças acima de seguir um plano."

Essas palavras tinham a intenção de nos libertar do desenvolvimento rígido no estilo cascata que havia se tornado nosso capataz. No entanto, ironicamente, conseguimos criar um novo conjunto de correntes, forjadas pelos autoproclamados "especialistas em agilidade" que proliferam em nosso ecossistema de negócios e pelas próprias ferramentas que deveriam facilitar nosso trabalho.

Esses gurus dos tempos modernos, contratados a tarifas exorbitantes por empresas desesperadas para embarcar na onda da agilidade, muitas vezes não passam de fanáticos por agendar reuniões e gerenciar backlogs no Jira. Eles pregam a palavra do Agile, mas, em vez de fomentar a entrega de software valioso, parecem mais interessados em aperfeiçoar a arte da cerimônia vazia e da gestão de quadros digitais.

Os rituais aos quais nos apegamos

Considere a reunião diária em pé. Concebida originalmente como uma sincronização rápida e informal, ela se transformou em uma cerimônia temida, na qual os membros da equipe recitam roboticamente suas tarefas como versículos de um livro de orações, muitas vezes apenas lendo seus tickets do Jira. "Ontem trabalhei no ticket JIRA-1234. Hoje vou trabalhar no JIRA-5678. Não tenho impedimentos." Amém.

A reunião de planejamento de sprint, antes um esforço colaborativo para priorizar o trabalho valioso, agora se assemelha a um processo burocrático no qual os pontos de história são barganhados como indulgências nos tempos medievais, tudo isso enquanto se encara uma tela cheia de épicos e histórias de usuário do Jira. "Eu te dou três pontos de história por esta funcionalidade, mas você precisa prometer entregá-la até o fim do sprint!"

E não esqueçamos a retrospectiva de sprint, o equivalente ágil da confissão. Os membros da equipe anotam diligentemente o que correu bem e o que poderia ser melhorado, muitas vezes em mais uma ferramenta digital, mas com que frequência essas reflexões levam a uma mudança significativa? Com frequência demais, elas se tornam um ritual catártico sem impacto no mundo real, perdidas no mar de notas adesivas digitais e itens de ação que nunca parecem ser de fato executados.

Os falsos ídolos das métricas

Como se a proliferação de cerimônias sem sentido não bastasse, agora enfrentamos uma nova ameaça à verdadeira agilidade: o culto à carga das métricas. A alta gerência, em sua infinita sabedoria, descobriu que as equipes ágeis usam números. E se há uma coisa que a gerência ama, é um bom número para colocar numa apresentação de PowerPoint.

Eis que surge a velocidade, o bezerro de ouro das métricas ágeis. Essa medida, pensada como uma ferramenta de planejamento específica de cada equipe, foi elevada a um status sagrado que faria corar até o mais zeloso adorador de relíquias medievais. Gerentes que não saberiam distinguir uma história de usuário de uma história para dormir agora exigem que as equipes aumentem sua velocidade, aparentemente sob a impressão de que o desenvolvimento de software funciona como uma linha de montagem de fábrica.

"A Equipe A tem uma velocidade de 50 pontos de história por sprint, enquanto a Equipe B só consegue 30", proclamam de suas alturas. "Claramente, a Equipe A é mais produtiva. A Equipe B precisa melhorar seu desempenho!"

Não importa que a Equipe A e a Equipe B trabalhem em produtos completamente diferentes, com definições diferentes de pontos de história, tamanhos de equipe distintos e diferentes níveis de dívida técnica. Contexto? Quem precisa de contexto quando se tem números!

Mas a velocidade é apenas a ponta do iceberg. Os gráficos de burn-down são examinados como áugures perscrutando as entranhas de animais sacrificiais. As porcentagens de cobertura de código são brandidas como talismãs para afastar os espíritos malignos dos bugs. E ai da equipe cujo tempo de ciclo não diminuir de sprint em sprint, pois certamente deve estar relaxando.

Neste admirável mundo novo das métricas ágeis, de alguma forma conseguimos recriar exatamente o mesmo estilo de gestão de cima para baixo e sem contexto do qual o Agile deveria nos salvar. Nossas novas ferramentas digitais se tornaram os chicotes usados para nos fazer correr cada vez mais rápido, com pouca consideração pela qualidade ou pelo valor daquilo que produzimos.

O Manifesto Ágil nos lembra de valorizar "software em funcionamento acima de documentação abrangente". Talvez seja hora de acrescentar "resultados significativos acima de métricas sem sentido". Mas quem tem tempo de entregar software que funcione quando há tantos gráficos para atualizar?

O significado perdido

Assim como muitos praticantes religiosos esqueceram o propósito de construir comunidade por trás de seus rituais, muitas equipes ágeis perderam de vista a verdadeira intenção do manifesto. O Manifesto Ágil nos exortou a valorizar "indivíduos e interações acima de processos e ferramentas", e, no entanto, criamos um novo conjunto de processos que seguimos cegamente.

Na Bíblia, Jesus criticou os fariseus por sua rígida adesão às leis religiosas enquanto ignoravam sua essência espiritual:

"Ai de vós, mestres da lei e fariseus, hipócritas! Pois dais o dízimo da hortelã, do endro e do cominho. Mas tendes negligenciado as questões mais importantes da lei: a justiça, a misericórdia e a fidelidade." (Mateus 23:23)

Não somos culpados do mesmo em nossas práticas ágeis? Acompanhamos meticulosamente a velocidade, os gráficos de burndown e os tempos de ciclo, mas será que negligenciamos as questões mais importantes da colaboração, da adaptação e da entrega de valor?

O caminho para a redenção

É hora de uma reforma ágil global. Precisamos abandonar as cerimônias que já não nos servem e redescobrir o verdadeiro espírito da agilidade. Isso não significa abandonar toda estrutura, mas sim abordar nossas práticas com atenção plena e propósito.

Perguntem a si mesmos: Esta reunião em pé realmente nos ajuda a colaborar e remover obstáculos? Nosso planejamento de sprint de fato nos permite responder a mudanças? Nossas retrospectivas levam à melhoria contínua? E, o mais importante: Estamos realmente entregando software valioso, ou apenas aperfeiçoando nossa atuação nessas cerimônias?

Se a resposta for não, tenham a coragem de mudar. O Manifesto Ágil nos lembra de valorizar "responder a mudanças acima de seguir um plano". Isso se aplica não apenas aos nossos planos de projeto, mas aos nossos próprios processos.

É hora de questionar os falsos profetas da agilidade que prometem a salvação por meio de mais reuniões e mais rituais. A verdadeira agilidade não se mede por quantas cerimônias realizamos, mas por nossa capacidade de nos adaptar e entregar valor real aos nossos usuários.

Libertemo-nos das correntes do Agile de culto à carga e voltemos à verdadeira fé da adaptabilidade, da colaboração e da entrega de software que funciona. Só então poderemos almejar a salvação do atoleiro da ineficiência e redescobrir a terra prometida do desenvolvimento de software verdadeiramente ágil.

Amém. Que seus sprints sejam produtivos, seus backlogs estejam sempre refinados, e que você nunca se esqueça de que software em funcionamento é a verdadeira medida do seu progresso.

← Todos os posts