Independente se você é um agilista experiente ou iniciante, existem desafios que fazem parte do dia a dia de qualquer equipe que esteja em busca da criação de software com qualidade e com o mínimo de previsibilidade quanto ao prazo para a entrega de uma demanda (ex: nova funcionalidade, correção de um bug, melhoria técnica, etc.).

Desenvolver uma visão que possibilite enxergar e compreender o todo por meio da análise das partes que o formam é um grande desafio ao lidar com ambientes de incerteza.

Uma das formas de compreender e analisar o sistema de trabalho de uma equipe ágil se dá através das métricas de processo (há uma coletânea de conteúdo bacana sobre o assunto aqui no blog da Ptec).

Entender o fluxo a partir dos dados é uma maneira pragmática de incorporar uma filosofia de melhoria contínua, sem mudanças abruptas e caóticas e de forma transparente para todos que estão envolvidos no contexto (equipe, stakeholders, área de produtos, gestores, etc.). Parafraseando a comunidade Kanban, medir é uma ferramenta que ajudará a evoluir e não revolucionar um processo já existente.

Pessoalmente, eu gosto de quantificar o processo quando estou mapeando a realidade de uma equipe, pois exponho fatos (dados) para discussão e análise. Na minha experiência com equipes de desenvolvimento de software, venho percebendo que ter esse tipo de conduta ajuda a diminuir uma carga subjetiva que possa existir na equipe e é um jeito de confrontar crenças como “não precisamos melhorar”, “não temos problemas no processo” e “atuamos de forma colaborativa”.

No blog post de hoje, compartilharei uma coleção de métricas que ajudarão você a diagnosticar a saúde do proceso de uma equipe ágil.

Premissas

Antes de qualquer coisa, preciso deixar algumas ressalvas quanto ao uso das métricas.

Métricas devem ser usadas para evoluir o processo e não para gerar cobranças e comparações destrutivas.

Não caia na tentação de comparar equipes e medir o desempenho de um indivíduo. Se você ou a empresa no qual trabalha estão interessados em premiar resultados individuais, formulem um método que proponha avaliar o desempenho da pessoa a partir da opinião dos gestores, pares e clientes que tenham interagido com o resultado do trabalho do indivíduo. No caso de recompensar individualmente as equipes por seu resultado, fuja de métricas que não tenham relação direta com o resultado do negócio (ex: do que adianta a equipe ter entregue um número de funcionalidades no semestre sendo que o produto não teve um aumento de receita?).

Compartilho essa premissa para que você e sua equipe não se comportem de acordo como estão sendo medidos. Afinal, já diria Goldratt: “diga-me como serei avaliado e eu lhe direi como me comporto”.

Números sem contextos são perigosos.

Qualquer análise feita sem compreender as variáveis que compõe um cenário se torna superficial, enviesada e pobre. Se alguém lhe contar que o número de funcionalidades entregues em uma equipe é de 10 itens por semana, é possível concluir algo? Tal métrica é boa ou ruim? Qual o significado de entregue para aquela equipe? É software em produção ou entrega em um ambiente de homologação? Bem, pelos questionamentos anteriores é possível concluir que um número solto nada mais é do que um símbolo privado de qualquer significado.

Procure tendências e fuja da precisão. Dada a complexidade que é criar um produto de software, não busque ser determinístico em um mundo que é receptivo por natureza a uma realidade probabilística.

A lógica por trás da última premissa é: vivemos em um ambiente onde há risco, isto é, existe a probabilidade de insucesso em função de algum acontecimento incerto, cuja ocorrência não depende exclusivamente da vontade da equipe. Portanto, é pouco provável que a equipe saiba ao certo o prazo de entrega de uma demanda ou projeto. Ao invés de nos enganarmos com prazos que ratificam que as entregas acontecerão sempre na mesma data e na mesma forma, passemos a analisar o histórico de dados da equipe para projetarmos a chance de entregarmos algo.

As premissas compartilhadas ajudarão você a utilizar as métricas de forma efetiva. O Lucas Colucci escreveu um texto muito importante que apresenta alguns erros comuns ao utilizar métricas de processo.

Diagnóstico do processo

Dada as premissas compartilhadas acima, vamos ao que de fato interessa. As métricas listadas a seguir servirão para você mapear como está a saúde do processo de uma equipe. Como agilista, considero que as visualizações abaixo compõem o painel de análise (cockpit) de um fluxo de trabalho e devem estar disponíveis para que as equipes utilizem como material para a promoção de melhorias no processo (ex: uso das métricas em retrospectivas, análise do processo em reuniões diárias, etc.).

Trabalho em progresso

Monitorar o trabalho em progresso ajudará a equipe a ter consciência de qual é o montante de trabalho que o processo tem suportado ao longo do tempo. Gosto desse tipo de visualização, pois ela demonstra, por exemplo, se as equipes estão respeitado uma política de limite do trabalho em progresso.

No exemplo acima, temos uma situação onde a equipe estava com a quantidade de itens em progresso próximo de 10 por semana até que em determinado momento houve uma reconfiguração no número de pessoas, o que fez com que a quantidade de trabalho em progresso diminuísse. Um insight aqui é que essa visualização apresenta um histórico interessante da equipe, ajudando a identificar momentos em que ocorreram mudanças na estrutura do time, mudanças de rumo (as famosas pivotadas), impedimentos, etc.

Visando estabilizar o processo a partir da capacidade produtiva, é importante que o número de itens em WIP não entre em uma tendência de crescimento. Caso isso esteja acontecendo, é bem provável que a equipe precise de otimizações para que o WIP passe a diminuir. Como agilista, monitorar o WIP apoiará você a reverberar o seguinte mantra com a equipe: “vamos parar de começar e comecemos a terminar”.

Uma outra análise de WIP que tenho começando a fazer diz respeito ao tempo de vida dos itens que estão em WIP dentro de uma determinada semana. Essencialmente, a visualização leva em consideração os itens que estão em progresso naquela semana e contabiliza há quanto tempo eles se encontram dentro do fluxo de trabalho. Para facilitar a leitura do gráfico, faço um agrupamento por categoria onde considero as seguintes faixas: (1) 1 dia em WIP; (2) até uma semana em WIP; (3) de 1 à 2 semanas em WIP; (4) de 2 à 3 semanas em WIP; (5) de 3 à 4 semanas em WIP; (6) acima de 4 semanas em WIP.

Ainda sobre a estrutura da visualização, para as semanas que já passaram, é feita a contabilização e a classificação dos itens que estão em WIP no final do período. Já para a semana corrente, é realizada uma análise dos itens que estão em WIP no momento.

Aplicando em um exemplo, é possível perceber que, na quinta semana de monitoramento do tempo de vida do WIP da equipe acima, existiam dois itens que estavam há mais de um mês dentro do fluxo. Se a equipe, ao acompanhar sistematicamente seu fluxo de trabalho, perceber que as categorias de mais idade estão crescendo é bem provável que um gargalo esteja se formando em alguma etapa do processo e uma intervenção será necessária.

Tenha em mente que WIP representa esforço e energia que ainda não foram validados e quanto mais tempo a equipe passar carregando-o, menos feedback será recebido, mais lento será o processo de validação das hipóteses por detrás das iniciativas que originaram o trabalho e maior será o risco da empresa estar perdendo uma oportunidade de mercado.

Caso queira saber mais sobre WIP, não deixe de ler post Um estudo mais profundo sobre Limites WIP

Tempo de entrega

O lead time é uma métrica importante para que as equipes desenvolvam a capacidade de entender quanto tempo elas têm levado para concluir um item de trabalho. Além disso, equipes que desenvolvem a habilidade de analisar tal métrica conseguem identificar situações que geraram variabilidade no processo (ex: problemas em ambientes, saída de membros da equipe, falta de critérios de aceite claros nas demandas).

A primeira visualização que recomendo estar disponível para a equipe é o gráfico de dispersão do lead time. Ele oferecerá uma ideia se o tempo para que os itens sejam entregues está diminuindo ou não ao longo do tempo.

Conforme ilustrado no gráfico acima, gosto de combinar nessa visualização as seguintes informações: itens finalizados (representados no gráfico pelos pontos em azul) e em progresso (representados no gráfico pelos pontos em vermelho); a média móvel que leva em consideração os últimos 5 itens entregues (esse é um parâmetro totalmente arbitrário); e as informações de percentil 50 (mediana), percentil 75 e percentil 95.

Tais medidas de referência são úteis, pois, a partir do exemplo, trazem a tona constatações como:

• A média móvel tem variado ao longo do tempo.
• Baseado no histórico de itens concluídos, 50% deles foram finalizados em até 10 dias, 75% levaram até 16 dias para serem finalizados e 95% foram concluídos em até 34 dias.

Além disso, o gráfico de dispersão pode gerar respostas para questionamentos como:

• O que a equipe está fazendo para tratar os itens em progresso que estão se tornando casos extremos de lead time?
• O que é possível melhorar no processo para que haja uma diminuição no lead time?

Outra visualização benéfica para entender o tempo de entrega é o gráfico de histograma, pois, ao considerar cada lead time como uma categoria, o mesmo apresenta os dados de uma maneira mais concisa e que permite extrair informação sobre o comportamento da distribuição.

Conforme ilustrado no exemplo acima, o histograma permite que a equipe tenha resposta para indagações do tipo:

• Qual tem sido o lead time mais frequente?
• Os casos extremos de lead time são muito frequentes?
• Qual o formato da distribuição? Há uma concentração do lead time a esquerda ou a direita da distribuição? Existe mais do que uma moda? Geralmente distribuições bimodais representam fluxos de equipes que lidam com mais de um tipo de demanda em seu processo, pois apresentam concentrações semelhantes em diferentes categorias de lead time.

Ritmo das entregas

Medir e visualizar o throughput (vazão) é importante para que a equipe compreenda qual tem sido o montante de trabalho entregue em um período de tempo (exemplo: semana, quinzena, mês), bem como para que ela identifique se há a criação de uma tendência de aumento no número de entregas. Ao perceber que o throughput está em queda, a equipe pode buscar entender quais fatores estão afetando a vazão do processo.

Recomendo sempre que possível a quebra da visualização do throughput por tipo de demanda. Dessa forma, fica explícito para todos se a equipe está conseguindo:

• Equilibrar o número de entregas de valor (ex: funcionalidades) com demandas de falha (ex: bugs).
• Lidar com o urgente de forma sustentável. Volta e meia me deparo com equipes que classificam todo tipo de demanda que entra no fluxo de trabalho como urgente e atuam em cima delas, deixando de lado itens que serão importantes para o negócio no médio prazo.

No exemplo acima a equipe conseguiu equilibrar em grande parte das semanas entregas de história do usuário com correções de bug. Na semanas sinalizadas com as setas em vermelho, a equipe precisou atuar e entregar problemas críticos que estavam afetando a operação da empresa e por isso entregou apenas correções de bugs.

Análise da taxa de entrada e saída do fluxo

Além do uso do gráfico de CFD (escrevi um blog post completo para falar sobre essa visualização), gostaria de apresentar uma análise que não tenho visto muitos agilistas fazerem: relação entre as taxas de entrada e saída do fluxo de trabalho. Basicamente essa visualização compara a quantidade de itens que a equipe se comprometeu entregar com o número de itens entregues ao longo do tempo.

O que esse tipo de visualização pode trazer de insight? Vamos analisar um exemplo.

Baseado na imagem acima é possível fazer algumas deduções:

• Das 27 semanas analisadas, 10 delas tiveram uma taxa de entrada (itens que a equipe se comprometeu) maior do que a quantidade de itens entregues.
• Na semana 17 a equipe teve um pico de itens comprometidos para serem entregues. Isso ocorreu pelo fato da pessoa que era PO da equipe estar em vias de entrar de férias. Falando em estoques, sugiro a leitura do blog post do Guilherme Fré sobre o assunto.

Analisar a taxa de entrada e saída do processo apoiará a equipe no entendimento de se o ritmo de entrega está acompanhando a quantidade de itens comprometidos. Tenho visto equipes assumindo mais do que sua real capacidade. Tal tipo de comportamento gera desconfiança dos stakeholders pelo fato da equipe entregar menos do que é pedido e frustação da equipe por nunca conseguir entregar “tudo”.

Em um sistema perfeitamente estável, a taxa de entrada e saída deveria ser a mesma. Se você e sua equipe conseguirem desenvolver um processo onde na maior parte das semanas as taxas forem equivalentes (ex: para cada 4 semanas, 3 tiveram as taxas de entrada e saída iguais), isso demonstrará maturidade do fluxo de trabalho e representará um contexto altamente previsível.

Conclusão

Incorporar uma cultura que traga dados para sua equipe fará com que você monitore um processo que possui uma natureza essencialmente complexa (software) trazendo visibilidade do progresso para quaisquer interessados no que está sendo construído ou mantido.

Além disso, propor melhorias e evoluções baseadas em dados é um excelente caminho para a remoção de análises subjetivas e, até certo ponto, vazias. No fundo, espero que com esse blog post você, agilista, estimule que as pessoas utilizem menos o recurso do feeling quando estiverem analisando o comportamento do fluxo de trabalho de uma equipe.

Se você busca um material avançado em métricas, recomendo o livro que escrevi sobre o assunto Métricas Ágeis – Obtenha melhores resultados em sua equipe. Aproveite para dar uma olhada nas revisões feitas por quem já leu 😏

E você? Quais métricas tem utilizado para acompanhar a saúde do processo? Deixe suas experiências nos comentários abaixo!

jQuery( document ).ready(function() {
new RDStationForms(‘nurturing-agile-blog-post-guia-de-um-agilista-analisando-saude-do-processo-1d8b67d69ba6b19eaca3-html’, ‘UA-8268430-1’).createForm();
});