O time está lento? Use o Lead Time para descobrir por quê!

Você conhece a sensação: as estórias simplesmente parecem levar tempo demais para serem completadas, a velocidade parece sempre estar justo abaixo do esperado, e você não sabe ao certo o que fazer a respeito. A pressão começa a se acumular e o time começa a se sentir incomodado com todas as perguntas que você fica fazendo sobre quando eles esperam poder entregar as tarefas. Qual é de fato o problema? Há alguma falha no processo? As pessoas estão levando tempo demais para desenvolver código e testá-lo? Ou o gargalo está na análise? Suas estórias estão grandes demais, pequenas demais, ou apenas sendo subestimadas?

Gostaria de ter as respostas para todas essas perguntas? Bom, não podemos prometer isso. Mas, como na ciência, confiamos que juntando dados significativos para fazer uma análise você consegue ter uma ideia sobre o que pode estar causando seus problemas. E não estamos falando só do feijão-com-arroz, velocidade e escopo. Precisamos ir mais fundo!

Controlar o Lead Time

Qualquer processo de negócio, incluindo projetos de software, é beneficiado pela previsibilidade, mas há um porém: as suposições usadas para prever não devem descartar mudanças. Adotar prazos de trabalho curtos e usá-los para prever orçamento e entrega pode ser controverso, mas a experiência mostra que há maneiras de controlar o tempo levado para completar estórias, e dar essa visibilidade ao time pode ajudar a facilitar a entrega.

Na literatura sobre Agile/Lean/Kanban encontramos várias ideias e nomes diferentes para métricas que controlam quanto tempo uma tarefa leva para ser completada. Também há um debate antigo sobre a terminologia herdada de diferentes campos de estudo (pense em Lead Time vs. Cycle Time). Tudo isso é importante, mas para fins de simplicidade vamos pensar em uma abordagem mais direta: suponha que conseguimos controlar, em um sistema estável, quanto tempo uma estória leva do momento em que começa o trabalho até que ele termina. Suponhamos também que o fluxo de trabalho das estórias jogadas segue um modelo de quatro etapas, como este:

As estórias ficam no Backlog até que um par seja liberado; após algumas conversas, o par começa a trabalhar movendo a estória do Backlog para In Progress. Nesse momento o relógio começa a contar. Quando o desenvolvimento é concluído o item é movido para Sign Off, onde o proprietário da estória dá a olhada final. Depois de tudo feito e verificado, o item é movido de Sign Off para Done. É aqui que o relógio para. A medida do relógio, no contexto do sistema estável de estórias e transições, é o que estamos observando. Dos vários nomes possíveis ("flow time", "latência", "Lead Time de desenvolvimento", etc.) para essa métrica, escolheremos, pela simplicidade, o mais usado no âmbito Lean: Lead Time¹.

Agora, essa é só uma entre as muitas configurações possíveis. Você pode ter uma ideia completamente diferente de fluxo de trabalho em mente para uma estória, mas esperamos que essa ilustração ainda sirva para definir o que estamos tentando controlar. Na essência, espera-se que estórias mais complexas tenham um Lead Time maior, e estórias com complexidades similares provavelmente resultarão em Lead Time similares. Desconsiderando algumas exceções, se criarmos estórias com esforços similares, essas regras deverão se aplicar. Além disso, com o crescimento da quantidade de estórias iniciadas e terminadas, as médias devem convergir em direção a uma leve correlação entre o tamanho da estória e o Lead Time.

Deixe visível!

Então, se o que foi descrito acima faz sentido, o que pode de fato ser feito com os resultados dessas observações e quais são os benefícios potenciais para o time? Vejamos:

O gráfico acima demonstra uma ideia de como dar visibilidade ao Lead Time. No eixo vertical, os números representam os itens de trabalho (estórias, etc.) que pertencem ao sprint/iteração atual. O eixo horizontal representa o tempo, aqui demonstrado em cada dia útil de uma iteração de duas semanas. Usando um códigos de cores para identificar o status de cada item, o time poderá atualizar esse quadro diariamente na stand-up:

• Se um novo item é iniciado, (isto é, passa do Backlog para In Progress), um ponto preto é adicionado na intersecção entre a linha do item e a coluna do dia;
• Para os itens "in progress" atualmente, uma linha preta é desenhada até a coluna do dia;
• Se um item foi para Sign Off desde a última stand-up, mudamos a cor desse item para azul;
• Se um item é concluído (isto é, passa de Sign Off para Done), um "X" verde é adicionado.

Dá para ter uma noção? Uma vez que esse quadro está visível para todo o time o tempo todo e que o próprio time (não necessariamente só o PM) atualiza o gráfico todos os dias adicionando e puxando linhas, o time tem acesso ao Lead Time atual de cada estória de uma vez só. Mas espere, tem mais!

• Sabe as datas azuis à direita do quadro? Quando um item é iniciado o time olha para os pontos da estória; se uma estória de tamanho médio leva em torno de uma semana (cinco dias úteis) para ser concluída, isso significa que se começarmos a "903" (uma estória de tamanho médio) na segunda-feira, 10 de novembro, devemos ter concluído até sexta-feira, 14 de novembro. O número em verde/vermelho abaixo das datas é o número de dias úteis até essa data (se a estória estiver "atrasada", o número é negativo);
• Por fim, as linhas vermelhas verticais: uma vez que a estória "903" está marcada para 14 de novembro, um marcador vermelho é inserido na linha da coluna correspondente àquela data. À medida que puxamos a estória a cada stand-up, podemos acessar visualmente quão perto estamos do prazo.

Então, você pode estar se perguntando: o que acontece se um item não pôde ser concluído antes de chegar à linha vermelha? O caos desce dos céus e todos são demitidos, certo? Claro que não. Transparência em geral funciona melhor do que pressão, e essa é a chave de tudo isto.

Uma valiosa ferramenta para o time

Todos sabemos que estimativas não são muito mais do que palpites informados, e devemos esperar que às vezes elas sejam diferentes da realidade. No entanto, quando bem feitas, após algum tempo as flutuações tendem a se ajustar. Quando um time dá visibilidade a seus próprios dados de Lead Time, as pessoas nele têm o poder de identificar o que pode estar fazendo com que as estórias excedam as projeções e decidir o que fazer a respeito. Às vezes a estória precisa ser dividida em estórias menores que mais pessoas possam jogar paralelamente; às vezes há um problema de design de código em algum lugar causando perda de tempo pra contornar e o time pode decidir gastar algum tempo refazendo-o. Em outras ocasiões é o próprio escopo que não fica muito claro, e mais conversas com as partes interessadas são necessárias para esclarecer isso. No fim das contas, cabe ao time decidir o que pode ser feito para atingir os objetivos de tempo sem sacrificar a qualidade ou quaisquer outros princípios que guiem seu trabalho.

Aqui vai um exemplo: em um de nossos times atuais, há alguns meses, começamos a sentir que estávamos "desacelerando". Tínhamos algumas estórias se arrastando um pouco, mas ninguém sabia ao certo quanto. Após executar uma análise do Lead Time das estórias entregues até então, separando-as por tamanho (2, 4 ou 8 pontos), segue o que descobrimos:

Barras azuis: quanto tempo esperávamos que as estórias levassem, em média
Barras laranjas: quanto tempo estavam levando de fato, em média

Estórias pequenas (2pt) e grandes (8pt) estavam ok; elas levavam um pouquinho mais do que as estimativas projetadas, mas essas flutuações são normais e nosso planejamento de projeto tinha espaço para isso. As estórias médias (4pt), no entanto, tinham um problema: estavam levando, em média o dobro do tempo projetado. Queríamos saber o por quê, então executamos alguns exercícios juntando o time e falando sobre isso. Identificamos alguns pontos sensíveis: muito do tempo era gasto juntando detalhes adicionais sobre as estórias após iniciá-las; como time estava distribuído, a comunicação remota às vezes era difícil; o time era grande demais e era difícil manter a rodada de todos os recursos em desenvolvimento em paralelo - apenas para citar alguns.

Ter os números diante dos olhos nos ajudou a colocar lado a lado a sensação de "lentidão" com dados reais que confirmavam e quantificavam isso. Adicionalmente, nos ajudou a criar itens de ação para lidar com os problemas discutidos de maneira direcionada. Nós fizemos um plano para uma reorganização de todo o time, removendo bloqueios e facilitando uma comunicação mais próxima. Ficamos muito felizes com o resultado, e foi ótimo ver a evolução refletida nas métricas, que melhoravam a cada semana. Após algum tempo, era assim que estava o Lead Time médio:

Experimente!

Quando o time está cercado por um ambiente de trabalho saudável onde as pessoas confiam e dependem umas das outras, e quando os líderes das entregas mantêm um raciocínio de simplicidade incorporando mudanças, controlar o Lead Time como um Indicador Chave de Desempenho é uma técnica poderosa. Ela permite que o time reflita sobre seus resultados, com base na visibilidade e não em pressões externas, e identifique gargalos e pontos sensíveis que precisam de ação. Medindo o Lead Time, você passa de sentir-se lento para saber onde está a lentidão, o que lhe dá uma melhor chance de melhorar através de movimentos específicos e direcionados. Isso fez toda a diferença no nosso time. Por que você não experimenta?

¹ Se você leu algum dos textos do Paulo Caroli's sobre Lean e Lead Time, você pode estar se perguntando por que o tempo passado no Backlog (wait time) não foi incluído no cálculo. Essa é uma ótima pergunta. Nesse caso, um exemplo tirado de um time real, a ideia de um compromisso de sprint é aplicada, em vez de um sistema mais dinâmico de "pull", o que faz com que os itens passem mais tempo no backlog sem serem tocados por ninguém, apenas porque estão atribuídos a um determinado sprint. Por isso, fez mais sentido deixar esse tempo ocioso de fora do cáculo, e pensar no gatilho de "início" como a transição para In Progress.