Todas as vezes que penso em indicadores e métricas, lembro da frase de H. James Harrington:

Medir é o primeiro passo para controlar e eventualmente promover melhorias. Se você não pode mensurar algo, você não pode entendê-lo. Se você não consegue capturá-lo, você não consegue controlá-lo. Se você não consegue controlá-lo, você não consegui melhorá-lo.

Apenas para deixar claro, meu interesse é melhorar processos e sistemas, portanto defino “controle” como habilidade que uma equipe desenvolve para construir ferramentas que fomentem a auto-gestão, ao invés da cultura de comando e controle.

Desde que comecei a trabalhar com desenvolvimento de software, tenho visto métricas a partir de dois pontos de vista:

1. No lado negro da força, as métricas são aplicadas como ferramentas que enxergam equipes como números e, a única razão para coletá-las visa cobrar respostas e criar conflitos destrutivos. Exemplos de métricas desse tipo são: número de testes unitários escritos, velocidade individual, etc. (dê uma olhada no texto “How To Not Destroy your Agile Team with Metrics”).

2. Do outro lado da força, as métricas promovem ações de melhoria continua e trazem visibilidade para a equipe.

Aqui na Plataformatec, utilizamos as métricas para compreender como podemos fazer o nosso trabalho melhor baseado em dados, como um exercício de evolução.

Este é o primeiro post da série “Métricas Ágeis, em que compartilharei algumas métricas e gráficos que usamos nos projetos dos nossos clientes.

Se você busca material avançado em métricas, escrevi o livro Métricas Ágeis – Obtenha melhores resultados em sua equipe, um guia de aprendizado e boas práticas.

Vamos falar sobre Lead time

Segundo o Wikipedia, “é possível definir lead time como a latência entre o início e a execução de um processo. Por exemplo, o lead time entre o pedido e a entrega de um carro novo de um fabricante pode ser de 2 semanas à 6 meses. No setor de bens industriais, a redução do lead time é uma parte importante da produção enxuta.”

No contexto do desenvolvimento de software, consideramos o lead time como o número de dias entre o início e o fim de uma entrega — por exemplo, história do usuário, bugs, etc. Para medir o lead time deve-se estabelecer os limites de começo e fim.

Para algumas equipes, “feito” pode significar uma história de usuário lançada em produção, para outras pode ser a liberação de uma funcionalidade em ambiente de homologação.

Uso o gráfico de lead time para responder perguntas, como:

• Quanto tempo a equipe precisa para desenvolver um novo item?
• A equipe está conseguindo desenvolver as funcionalidades planejadas dentro do timebox de uma iteração?
• Existe algo afetando a previsibilidade dos itens que são trabalhados pela equipe (por exemplo, tamanho, complexidade, incerteza)? A variabilidade vem aumentando nas últimas semanas?

Bom, agora que definimos as coisas, vamos ver um exemplo prático. Imagine uma situação em que você, como Agile Coach, está aconselhando a equipe C3PO. Que tipo de insight é possível obter do gráfico abaixo?

Ao traçar a linha do percentil 75 (linha verde), notamos que 75% dos itens que passaram pelo processo da equipe levaram 20 dias ou menos para serem concluídos.

Outra linha que podemos desenhar é a do percentil 95. Com base nela, é possível assumir que um novo item tem 95% de chance de ser completado em 37 dias ou menos.

Então, o que deduzimos disso tudo?

Se alguém pedir ao time para estimar o tempo necessário para desenvolver um novo item, um palpite pode ser um número dentro do intervalo de 20 à 37 dias. Uma vez que temos alta amplitude, as estimativas não serão muito confiáveis.

Indo um pouco além nas investigações, é possível identificar que após a primeira release, algo aconteceu, afinal, o lead time aumentou. Provavelmente, nas releases posteriores, a equipe lidou com itens mais complexos ou incertos.

Outro ponto interessante para se analisar no gráfico são os casos extremos (lead times que estão nos extremos superior e inferior). Na maioria das vezes, esses valores atípicos são causados ​​por circunstâncias que estão além do controle da equipe, porém, é um ótimo material para retrospectivas como insumo de aprendizado.

Para concluir, gostaria de compartilhar cinco dicas sobre como otimizar o lead time:

1. Eduque a pessoa que estiver vestindo o chapéu de Product Owner para que ela consiga conceber itens que gerem valor com soluções simples (foco: diminuir o lead time).
2. Desenvolva ferramentas para que a equipe diminua a complexidade e remova incertezas técnicas ou de negócio (falo mais sobre isso no post Requisitos em equipes ágeis: Falando sobre complexidade e incerteza).
3. Analise a distribuição de lead time com freqüência. No início, a variabilidade alta será normal, mas, depois de algum tempo, é importante buscar um padrão para que seja possível ter um processo de desenvolvimento previsível.
4. Comunique qualquer variação no lead time para os stakeholders e implemente ações para controlar o crescimento do lead time.
5. Use os casos extremos como uma oportunidade para aprender e melhorar o processo.

E você? Que tipo de pergunta você está respondendo com base no lead time? Compartilhe conosco seus aprendizados nos comentários abaixo!