Fui convidado para falar sobre o tema agilidade na prática, para alguns projetos. Nesse bate-papo surgiram muitas dúvidas sobre o assunto e sobre minha abordagem em transformar equipes, então optei por criar esse conteúdo falando sobre o assunto. Vamos lá.
“Se você não pode medir, você não pode gerenciar”, Peter Drucker.
Essa frase é uma das citações mais famosas do considerado pai da administração moderna e quero te convidar para entender um pouco mais sobre a importância das métricas no gerenciamento e na transformação.
Tudo começa pelas métricas
Vejo que muitas empresas lideram suas equipes de desenvolvimento no modo “deixa a vida me levar”. Talvez elas tenham alguma bola de cristal que as ajude a identificar pontos positivos ou negativos de acordo com as mudanças que acontecem em suas equipes, ou simplesmente estão andando sem rumo.
Uma empresa precisa de métricas de negócio para se orientar, para se posicionar de uma forma mais assertiva ao mercado e às necessidades dos clientes.
Desenvolvimento de software não é muito diferente, precisamos de métricas para nos orientar, para aprendermos mais rápido e entendermos se o que está sendo aplicado está gerando resultados.
Ser ágil é fazer mudanças constantemente e validá-las. É ter um mindset de experimentação, que implica em levantar uma hipótese e validar a resposta dessa hipótese. Não há uma fórmula, ou framework, que possa resolver seus problemas de processos e gestão. O caminho é metrificar, experimentar e validar seus experimentos.
Primeiro, antes de fazer qualquer mudança em sua equipe, é importante compreender o cenário atual do seu projeto. Em outras palavras, entender o tamanho do problema.
Quais métricas devo utilizar?
Há várias métricas que você pode adotar para acompanhar um projeto de desenvolvimento de software. Porém, é muito importante entender o motivo de utilizar tal medição. Utilizar uma métrica porque outra equipe utiliza, por que a empresa adotou ou porque você viu em algum artigo na Zup não faz nenhum sentido.
As métricas tem o objetivo de nos ajudar na tomada de decisão, são informações que nos apoiam para termos mais assertividade no dia a dia.
Mas eu sei que muitas vezes é difícil saber por onde começar quando se fala de métricas. Por isso, a seguir vou listar as minhas sugestões de métricas que você deveria acompanhar.
Lead time
O lead time é uma das métricas mais importantes, pois conseguimos obter o período médio entre o início de uma atividade, produtiva ou não, até o seu término. Quando eu digo até o seu término, estou considerando que aquela tarefa já esteja em produção, não necessariamente liberada para o cliente.
A coleta do lead time é simples, basicamente ela calcula quanto tempo cada atividade ficou no seu board, passando por todos os status. Depois é só fazer uma média com todas as atividades finalizadas em determinado período.
Touch Time e Wait Time
Podemos abstrair várias outras métricas do lead time, mas irei focar em apenas em duas, Touch Time e Wait Time.
O Touch Time é o tempo produtivo do lead time. Sabe os status no Jira?” Em desenvolvimento”, “Em testes”, “Em code review”, então, são as colunas em que há alguém atuando. Assim o tempo gasto das atividades nesses status chamamos de touch time.
Já Wait Time são os status em que as tarefas estão em espera. Por exemplo, “Aguardando code review”, “aguardando testes”, “backlog”. Em outras palavras, são os status onde não há ninguém atuando. Dessa forma conseguimos metrificar quanto tempo a tarefa ficou parada em toda jornada.
Agora vamos ver um exemplo prático para você entender como essas métricas funcionam.
Na imagem vemos que a equipe demora, em média, 39 dias para enviar uma tarefa para produção, desde a concepção até o código em produção. Assim temos 39 dias de Lead Time.
Deste total, 79% do tempo é Wait Time, que corresponde ao tempo médio em que as tarefas ficaram paradas, sem ninguém atuando.
Os 21% representam o Touch Time, que é a eficiência do fluxo, que no caso são colunas em que há alguém atuando. Nesse exemplo podemos considerar que esta equipe é 21% eficiente, dessa forma que medimos a eficiência de um projeto.
Você deve estar pensando agora que 39 dias é muita coisa e que apenas 21% de eficiência é bem baixo (seu pensamento está certo). Pode estar pensando também que sua equipe demora bem menos que isso e que a eficiência do seu time deve ser bem maior. Será?
Já parou para pensar quanto tempo seu cliente demora para homologar uma feature? Já parou para pensar quanto tempo sua equipe demora para reagir (reaction time) a uma nova tarefa? E quanto tempo elas ficaram esperando no backlog. Pense nisso!
Valor vs falhas
Eu chamo a segunda métrica de valor vs falhas. Basicamente é quanto de esforço total o seu time dedica para gerar valor (tarefas) ou atuar em (bugs). O objetivo é sempre dedicar o maior esforço a criar valor para o cliente e diminuir ao máximo os bugs e retrabalhos.
Você pode estar pensando, que nem toda feature gera valor para o cliente. Concordo, mas acredito que esse seja um assunto para outro artigo, nosso objetivo é focar na eficiência e não na eficácia.
Agora vamos entender isso com um exemplo prático.
Digamos que determinada equipe tenha um total de 200 horas trabalhadas na semana. Usando o cenário acima, onde 51% deste tempo corresponde ao trabalho dedicado para corrigir bugs e 49% do tempo corresponde ao trabalho dedicado a gerar valor para os clientes, por exemplo: novas ferramentas e produtos ou melhorias.
Valor vs Falhas é simples de medir, porém é seu papel como líder mapear as oportunidades para diminuir essa quantidade de bugs ou retrabalhos.
MTTR (Mean time to repair)
Basicamente é o tempo médio que sua equipe demora para reparar um incidente. Algumas formas para melhorar essa métrica é trabalhar na causa raiz de cada incidente, evitando que aconteça novamente.
Ter uma boa maturidade sobre monitoramento, observabilidade e logs, com o objetivo de mapear e corrigir rápido quando um incidente surgir.
Deployment frequency
É a frequência que seu projeto realiza um deploy em produção, podendo ser um deploy a cada 2 dias, a cada 3 semanas ou a cada 1 mês.
O propósito é diminuir esse ciclo, com o objetivo de acabar com o estoque de código. Caso queira se aprofundar mais a respeito da métrica, sugiro que pesquise sobre Accelerate, já que a métrica pertence a este estudo, realizado pelo Google ao longo dos últimos 7 anos, com mais de 32 mil pessoas entrevistadas.
eNPS
Fugindo um pouco das métricas ágeis, recomendo que acompanhe também de perto alguma métrica de satisfação e clima da sua equipe, a mais comum é eNPS.
Afinal, mudanças geram desconforto, e se isso não for trabalhado pode gerar insatisfação, o que pode gerar attrition (pedidos de demissão).
Então busque compreender o quanto as mudanças impactam na satisfação da equipe, sem dúvida irá ajudar a tomar a decisão correta.
Mãos à Obra: Hora de pôr a agilidade em prática
Quando falamos em equipes ágeis e de alta eficiência, estamos falando de equipes que aprendem e se adaptam muito rápido, que não são engessadas a habilidades, pessoas, ferramentas, formas de trabalho e até a cultura.
E essas mudanças podem passar por algumas etapas: Medir, Planejar/ Executar, Inspecionar e Adaptar.
Planejar e Executar com exemplos
Iremos utilizar o mesmo exemplo para continuar nosso planejamento e execução. Vamos chamar a equipe de Equipe Z. Algumas informações sobre a Equipe Z:
- Lead Time: 39 dias.
- Wait Time: 79% do Lead Time, ou seja, corresponde a 30,8 dias.
- Touch Time: 21% do Lead Time, ou seja, corresponde a 8,2 dias.
- Equipe: 12 pessoas ao total: sendo 8 devs e 1 QA.
Neste momento já temos algumas informações sobre a performance da Equipe Z. Agora vamos trabalhar com algumas situações que já vivenciei e que são bem comuns de acontecer.
Situação 1: dependências externas
Analisando mais a fundo, identificamos que a Equipe Z tem o hábito de começar muitas tarefas e muita dificuldade em terminá-las, por conta de bloqueios externos.
Essas tarefas bloqueadas tem um Lead Time médio de 60 dias, puxando bastante a métrica para cima. Observando, percebemos que 80% dessas tarefas bloqueadas no WIP (Work in Progress) são causadas por uma dependência de outra equipe, que desenvolve parte do back-end da aplicação a ser desenvolvida.
Começo a analisar a documentação e vejo que está bem detalhada, porém não há critérios de qualidade que garanta que aquela demanda possa ser iniciada, não há pré requisitos estabelecidos para puxar as histórias ou tarefas.
Nessa situação é importante levantar possíveis soluções e colocá-las em prática. Uma hipótese que vale validar neste caso é se um Definition of Ready resolveria o problema.
Situação 2: gargalos
Digamos que analisando os dados eu identifique uma disfunção muito grande, onde 70% de todo o Wait Time esteja apenas no status “Aguardando teste”, ou seja, basicamente todas minhas tarefas ficam em média 21 dias apenas neste status.
Essa disfunção eu também poderia ter identificado utilizando uma métrica chamada CFD (Cumulative Flow Diagram), sugiro que busque compreender um pouco mais sobre ela.
Acompanhando mais de perto o dia do desenvolvimento percebo que há um profissional de QA e oito profissionais de desenvolvimento. Nesse projeto o QA é responsável por todos os testes e algumas automações. E quando há algum gargalo na etapa de “Aguardando teste”, não há colaboração de todos do time para que este gargalo seja sanado, assim aumentando cada vez mais o gargalo na etapa de testes e sobrecarregando o QA.
Uma hipótese que poderia ser validada é trazer a responsabilidade dos testes e automação para os desenvolvedores, controlando esse gargalo utilizando limitadores de WIP (Work in Progress).
Inspecionar e Adaptar
Na etapa de inspecionar o objetivo é validar se a hipótese que está na fase de experimentação teve um bom resultado, e quem garante isso são as métricas.
Sugiro que acompanhe mais de uma métrica para garantir que o experimento tenha significância. O que pode acontecer com seu experimento é haver uma queda do Lead time, e isso é muito bom, porém o eNPS está caindo também. E se não tivermos visibilidade sobre a satisfação do time, provavelmente a decisão será prejudicada. Não faz muito sentido sacrificarmos o bem-estar das pessoas para ter melhores resultados na eficiência da equipe.
Já na etapa de adaptação é simples, basicamente é compartilhar os resultados com a equipe em uma retrospectiva e discutir sobre eles. É muito importante que todo mundo tenha espaço para dar suas opiniões. Se o resultado da hipótese é positivo, importante deixar claro que a hipótese deverá se tornar parte dos processos da equipe e não mais um experimento, caso contrário precisa estar claro que tal hipótese será descartada e apresentar os motivos.
Agilidade na prática: métricas para tomar boas decisões
Eu poderia trazer inúmeras situações em que apenas com o Lead Time você teria visibilidade para tomar decisões. Porém, quanto mais informações, mais assertividade você terá como líder. Métricas ágeis, métricas Devops e métricas de satisfação da equipe te darão um panorama mais abrangente sobre seu projeto.
E você, como tem aplicado agilidade na sua equipe? Deixe nos comentários sua opinião! Essa troca é importantíssima para a nossa comunidade.
