Legal, você começou a usar métricas ágeis com seu time ou organização!

Estive certa vez em uma empresa que acreditava na transparência de informação, e dispunha de uma interface para que qualquer pessoa consultasse os gráficos de métricas de todos squads.

Transparência é algo muito bom, pois reforça confiança e promove colaboração. Porém, precisa ser usada com cuidado para evitar que pessoas que não convivem com o squad, muitas vezes baseadas em contextos de experiências passadas em suas equipes, interpretem de forma errada e deem pitacos que não se aplicam à realidade.

Um exemplo exagerado:

Sim, é um gráfico interpolando a quantidade de filmes com o Nicolas Cage com o de afogamentos em piscina, ambos por ano.
Creio que você, leitor(a), não recomendaria um banimento dos filmes do Nicolas Cage à fim de reduzir os índices de afogamento, até porque, por mais que as curvas dos gráficos pareçam andar de forma parecida, sabemos que não existe absolutamente nada ligando essas estatísticas (ou pelo menos, nós não temos como saber olhando o gráfico apenas).

Mas como é no mundo real?

Exemplo do dia a dia de um projeto ágil, com uso de métricas:

Com certeza absoluta, algumas coisas que se pode falar desse gráfico são:
– P95 (ou “Percentil 95”) está em 24,7 dias;
– P75 está em 10 dias;
– P50 está em 4 dias;

Essas são certezas absolutas que o gráfico nos mostra. Mais que isso, é especular.

Uma forma muito errada de analisar o gráfico seria, por exemplo, olhar os picos (os itens perto e/ou acima da linha roxa do Percentil 95) e especular se o tamanho do lote não está desigual demais e fazer o time estudar sobre escrita de histórias.
Ou indagar por que o time não focou em terminar os 2 itens em vermelho, acima da linha roxa, antes de pegar mais itens.

As questões talvez sejam válidas, mas concorda que tomar ações em cima de palpites talvez seja precipitado?

Vamos olhar para o mesmo gráfico, mas numa outra apresentação:

Aqui, nós temos o contexto de alguns dos itens. Olhando assim, fica claro que “tamanho de lote irregular” não é necessariamente o causador dessas demandas com lead time mais alto (o que não quer dizer que não exista problema nenhum com tamanho de lote, só não está explícito).

A grande sacada nas métricas não é olhar os gráficos e gerar ações para tratar um ponto fora da curva, mas sim olhar o que aconteceu com o time nesse tempo, e como isso se refletiu em números. Esses números são consequências para embasar o argumento de que melhorias podem ser feitas.

No caso acima, por exemplo, não poderíamos dizer que um problema é a importação de arquivos, que vez ou outra pára o time? Não seria possível automatizar isso?

Ou as aprovações que dependem de uma única pessoa de um fornecedor: não conseguiríamos mais uma pessoa com esse poder de decisão?

Um caso real:

Este caso é um pouco diferente, pois os envolvidos tinham um pouco de contexto:

As semanas com Throughput zerado (após o começo do projeto) correspondiam ao recesso de fim de ano da empresa, quando nada poderia ir para produção.

Um questionamento da gerência que surgiu da análise desse gráfico foi:

“Na semana 28, tivemos um throughput record para realizar as entregas das semanas 29 e 30. Por que nós não produzimos assim sempre? O que fizemos de diferente que nos ajudou nessa vazão, e como continuar fazendo isso?”

Realmente, mostrou-se que era possível um throughput mais alto. O objetivo de todos times é entregar valor, sempre. Analisar esse pico de throughput seria interessante.

E a resposta, resumidamente, foi:

Pressão, horas extras, trabalho de fim de semana e time esgotado.

Sim, esse esforço extra rendeu resultados, mas não é um caminho recomendado com o objetivo de se aumentar a produtividade. Eventualmente, entregas com data fixa ou expedites (um pouco sobre tipos de demanda e classes de serviço aqui) podem gerar pressão no time, mas transformar isso em rotina deve ser evitado.
Voltando aos princípios da agilidade, temos um exemplo da sustentabilidade sendo ferida.

Não digo que o throughput desse time não poderia ser melhorado, mas que a forma como isso foi atingido especificamente na semana 28 não foi boa.

Na Plataformatec, costumamos nos perguntar se um Throughput está saudável, não se está alto.

Esse gráfico, sem contexto, parece mostrar que algo bom aconteceu (e olhando apenas para volume de entregas, foi bom), mas o contexto mostra que essa vazão bem acima da média é na verdade um alerta sobre a saúde da equipe.

Sumarizando, métricas servem para ser reflexos do contexto, e não o contrário. Analise-as, mas entendendo o contexto das mesmas, e pense em ações para começar a fazer (ou para parar de fazer, em alguns casos).

Já imaginou se eliminássemos as chances de um National Treasure 3, abolindo os filmes do Nicolas Cage?

Como você e seu time olham para métricas hoje?