Métricas em times ágeis e o momento ideal para coletar informações

Métricas é um assunto que eu particularmente gosto muito de estudar e aplicar, mas quanto mais me aprofundo nesse tema mais entendo sua complexidade, engana-se quem pensa que trabalhar com métricas é apenas uma questão de coletar todos os possíveis dados que vemos pela frente e depois tentar tirar a maior quantidade de informação possível desses dados.

Essa inclusive, foi uma abordagem que eu tomei no início da minha carreira como líder de times, logo no começo eu cedi a esse impulso e vivi na pele os problemas que essa abordagem traz. Aprendi que para trabalhar com métricas precisamos começar no momento certo e também estabelecê-las de forma estratégica.

O momento ideal

Logo quando comecei a estudar a agilidade eu passei a liderar alguns times, pequenos para projetos de curta duração. E logo em uma das primeiras oportunidades que tive de estar na liderança de um time, eu quis implementar literalmente tudo que havia aprendido nos poucos cursos de agilidade da época!

Tínhamos uma board física para gerenciar o fluxo de trabalho, uma réplica virtual para ter mais detalhes das tarefas, todas as cerimônias do Scrum (framework que eu mais estava confortável na época) rigorosamente seguidas e é claro, uma planilha de métricas, relativamente complexa para acompanhar o desenvolvimento do time.

Tínhamos:

• Mood marbles, métrica para acompanhar o sentimento da equipe;
• Lead time, métrica para acompanhar o tempo que uma demanda demora para ser entregue;
• Troughput, métrica para acompanhar a taxa de entrega das demandas;
• Burndown chart, para acompanhar o progresso das demandas feitas em um gráfico decrescente;
• Story points, que a pesar de não ser uma métrica eu acompanhava para entender a capacidade do time;
• Nps, métrica que mede a satisfação do cliente com relação; e algumas outras.

No mundo teórico funciona perfeitamente! Time novo, começando do zero, com um líder com uma pequena bagagem de agilidade muito empolgado em colocar tudo em prática e um arsenal de métricas e ferramentas que chega a dar inveja em muitos times mais maduros. O que poderia dar de errado? Muita coisa!

Nas primeiras semanas tudo perfeito, mas conforme o dia a dia passava, eu comecei a ver o peso de integrar um time novo, garantir um ritmo de trabalho sustentável (e desconhecido até o momento por ser um time novo), lidar com as expectativas dos clientes, apoiar o time nos desafios que fomos descobrindo no decorrer dos dias e além disso, desprender tempo e esforço para coletar essas métricas de forma estável.

Se você já teve a oportunidade de iniciar em um time 100% novo sabe que estabilidade não é uma palavra que podemos usar, existe um tempo de maturação da equipe, estágios de desenvolvimento que envolvem não só processos mas também pessoas. Ambos evoluem e se adaptam à esse novo grupo social e isso leva algum tempo.

Coletar métricas desde o dia zero não é um erro, agora coletar todas, começado de uma vez em um time que não tem um mínimo de estabilidade necessário fazia com que os números gerados fossem tão instáveis quanto o momento que aquela equipe estava.

Esses números só reafirmavam que o time estava em um momento de adaptação tanto entre eles, quanto adaptação de processos, fora isso não havia absolutamente mais nada para tirar de insights dessas métricas todas.

E todo o tempo que eu levei para coletar e analisar esses números não foram de grande ajuda, foi apenas tempo perdido que só serviram para me mostrar algo que, sem números eu já sabia ou percebia. E esse é o problema de implementar métricas em um time que não está o seu momento para isso, o custo de coletar e analisar esses dados acaba não se justificando, pois não geram informação útil.

Métricas estratégicas

E por falar em informação útil, quando eu estava montando meu “arsenal de métricas” para esse time, eu não tinha um propósito para essas métricas, só queria por em prática aquilo que eu havia aprendido. Não há nada de errado nisso, mas não havia uma justificativa de negócio forte para justificar a implementação dessas métricas, e isso junto com o momento errado, fez com que eu gastasse tempo com algo que não se justificava naquele momento.

Hoje em dia, eu entendo que o caminho é inverso, métricas são o “como” e não o “por que”. Eu começo primeiro entendendo qual hipótese quero testar no dia a dia da equipe, a partir daí, vejo quais métricas podem gerar dados que me auxiliem a entender esta hipótese.

Por exemplo, se o cliente chega dizendo que o time de desenvolvimento não está fazendo entregas de qualidade. A partir dessa hipótese, a pergunta que vem em seguida é: qual ou quais métricas eu posso implementar no time para validar essa hipótese? Como posso saber se de fato o time está entregando um sistema de baixa qualidade ou se é a percepção do cliente ou dos usuários? Aí sim eu posso chegar em métricas como NPS, taxa de bug, e outros.

Eu chego nas métricas através de hipóteses que fazem parte do dia a dia da equipe. Desta forma, tenho uma forte justificativa de negócio para implementá-las, eu consigo justificar claramente para equipe o porque da coleta desses dados e também eu maximizo o custo de administração dessa equipe, olhando para dados que são realmente úteis para a realidade do time.

Aqui vale uma ressalva, caso você esteja inserido em um ambiente onde os dados são todos coletados de forma automática e um sistema de inteligência artificial cruzando essas informações para identificar possíveis padrões, sem que precisamos de pessoas para manualmente fazer todo esse trabalho, aí sim o quanto antes começar a coleta desses dados é melhor e quanto mais dados melhor ainda!

Mas eu não conheci ainda um ambiente que funcione desta forma.

Não existe uma resposta mágica do momento ideal e as métricas perfeitas para todos os times, desde que você tenha um mínimo de estabilidade na sua equipe e bons motivos para metrificar o ambiente você já pode começar coletar dados e utilizar das métricas como apoio a tomada de decisão.