Por que o Agile não está funcionando?

Recentemente tenho conversado com bastante gente sobre Shape Up, o framework de gestão de produto da 37signals que foi publicado como livro em 2019. Nessas conversas percebo muita gente empolgada com a ideia, com alguma clareza de problemas do seu dia a dia que poderiam ser resolvidos adotando esse caminho alternativo.

Quase sempre são times que operam — ou tentam — seguindo as doutrinas do Agile, com suas squads, times de produtos empoderados e todo o resto. A impressão é de que hoje em dia fundar uma startup ou empresa de tech vem com um manual e essa cartilha já vem junto.

Não me leve a mal, eu também já segui e implementei esse “playbook” diversas vezes. Provavelmente ainda vou voltar a fazer isso no futuro. Inclusive, até hoje o recomendo pra muita gente. Talvez essa seja a forma mais segura atualmente de se escalar um time de engenharia, iniciar uma cultura de produto dentro de uma organização e construir software de qualidade.

Você já viu esse filme

O engraçado é que nas conversas com líderes de produto ou founders que já operam assim há um tempo, ouço muitas pessoas reclamarem de versões similares dos mesmos problemas.

No geral, as reclamações giram em torno da demora para as coisas acontecerem. Parece que o time cresce e amadurece e tudo se torna mais complicado. Perguntas como “você lembra como a gente fazia as coisas mais rápido?” ou “por que isso ainda não está pronto?” acabam se tornando recorrentes.

Realização

Foi com tudo isso em mente que, por acaso, esbarrei em um post de 2017 do John Cutler falando sobre os motivos de Agile não funcionar. Inspirado no autor, resolvi escrever esse texto como uma provocação para quem está insatisfeito com o status quo e se perguntando se não há uma alternativa melhor. Primeiro vamos falar dos motivos, depois de como tentar contorná-los, e por fim trazer uma possível alternativa.

John e eu trazemos 4 grandes motivos para exemplificar quando Agile não funciona: (1) eficiência de fluxos de trabalho, (2) trabalho inesperado e mudanças de contexto, (3) péssimas estimativas e (4) complexidades mal resolvidas.

Eficiência de fluxos de trabalho

Se olharmos para o lead time, ou seja, o tempo desde que decidimos implementar uma feature até ela chegar nas mãos dos usuários em produção, você irá perceber que a maior parte do tempo é gasta em “espera“. É considerado normal ter cerca de 15% de eficiência do fluxo de trabalho (tempo trabalhando/lead time). Os melhores times atingem cerca de 40% nessa proporção. Ainda assim, nós geralmente só atuamos no que é visível, aquela pequena parcela do tempo de trabalhando. O resumo da ópera é: para se mover mais rápido é preciso diminuir o tempo de espera.

Na minha visão, essa é uma métrica que Cutler utiliza para exemplificar a quantidade de esforço e energia gastos em trabalho que não gera valor para os usuários. Não acredito que essa seja uma métrica que valha a pena ser acompanhada no dia a dia, mas serve muito bem de reflexão para pensarmos em como aumentar a eficiência dos times.

Trabalho inesperado e mudanças de contexto

Não é incomum vermos times por aí que gastam mais da metade do seu tempo com trabalho que não estava planejado e trocas de contexto. O trabalho não planejado pode ser manutenção da aplicação em produção, resolução de bugs urgentes, ajuda para outros times ou qualquer outro incêndio que precise ser apagado. Todo mundo sabe que isso sempre acontece, e essas esferas de trabalho raramente são mapeadas nos sistemas de tickets internos.

Não vou nem entrar no mérito do quão tóxicas tantas trocas de contexto são para os times de engenharia…

Agora imagine que todas essas demandas são responsabilidades compartilhadas e o mesmo time responsável pela infraestrutura da aplicação está trabalhando nos projetos que agregam valor. Pronto, você já tem um gargalo no desenvolvimento de produto.

Lição: não ignore as fontes de trabalho não planejado. Tente entender o impacto econômico dos serviços compartilhados. Times com responsabilidades compartilhadas prestando serviços internos fazem sentido intuitivamente, mas podem custar caro em planejamento prévio para que funcionem como o esperado.

Péssimas estimativas

Esse é um truque bacana! Tente desenhar em um gráfico o tempo até a entrega de tarefas com diferentes estimativas de tamanho (P, M e G ou usando a escala de sua preferência). De preferência, analise tarefas que realmente adicionam valor para seus usuários. O que se nota é que em muitas organizações o tamanho das tarefas não tem correlação com o tempo em que demoram para serem entregues.

Por que? A resposta é que existem muitos outros fatores influenciando quanto tempo se demora para realizar uma entrega (ex: trabalho imprevisto, muitas frentes de trabalho ao mesmo tempo, incêndios, etc).

Esse é um bom exercício para aprendermos o quão ruim somos em fazer estimativas.

Complexidades mal resolvidas

Por último, experimente pegar uma feature de referência conhecida (aquela feature que você usa como base comparativa nas estimativas de esforço) e fazê-la passar pelo seu processo de desenvolvimento de produto. Se você não estiver constantemente minimizando complexidades, refatorando código e priorizando automações, mais tempo será necessário para realizar o mesmo trabalho ano após ano. Não é surpreendente ver algo que antes demorava 3 dias passar a demorar 1 mês para ir para o ar.

Agile

O que nos traz de volta para o Agile. Agile é inútil se ele não funciona como catalisador de melhorias contínuas. Scrum e SAFe, idem. Sabe o por quê? Porque os fatores que estão te atrasando são apenas parcialmente relacionados as cerimônias ou rotinas que seu time realiza. Uma vez que você entende o conceito de gradativamente mitigar riscos, importa muito pouco se você faz sprints, escreve user stories ou faz retrospectivas quinzenais.

Para “ser ágil” de verdade você precisa investir muito tempo e dinheiro em:

• Fazer o trabalho que realmente importa. E provavelmente fazer menos;

• DevOps — automaçoes, pipeline de deploy, feature flags, etc;

• Mudar sua cultura de gerenciamento;

• Ajustar como você faz apostas. Apostar em pequenas melhorias incrementais ao invés de grandes projetos;

• Alocar recursos para reduzir a complexidade — refatoração e repensar arquitetura de tempos em tempos;

• Um novo olhar atento sobre responsabilidades compartilhadas e serviços internos que consomem tempo dos times

Não tem mistério, você precisa colocar tempo nisso. Dá trabalho. E tome cuidado com quem te disser o contrário.

Uma alternativa

Voltando ao assunto inicial, agora com muito mais contexto, tenho enxergado no Shape Up uma alternativa interessante para resolução de muitos desses problemas comuns. Sinto que hoje estou numa posição privilegiada como Country Manager do Brasil na 37signals para entender a fundo como a metodologia funciona e pode ser adaptada para outras realidades.

Por isso, decidi dedicar parte do meu tempo a implementar o Shape Up em organizações e documentar esse processo para compartilhar por aqui. Nas próximas semanas também começarei uma série explicando sobre a metodologia.

Caso sua curiosidade tenha sido despertada, aperte os cintos e vamos nessa!

PS: se você já usa Shape Up no seu dia a dia ou está considerando fazer essa, mudança: me manda uma mensagem, vou adorar conversar sobre :)

Obrigado por ler! Este Post é público e ficarei muito agradecido se você puder compartilhá-lo com quem achar interessante :)