Mudanças Evolucionárias 2— Performance & Resultados (Ep. 4)
Após uma reflexão e a compreensão de como avaliar performance de times (Leadtime vs Storypoints: Por uma discussão mais profunda sobre performance de times) e um entendimento do impacto gerado nas organizações quanto ao trabalho baseado por fatos e dados (Métricas, para além de performance de times), agora estamos trazendo alguns resultados na jornada de alguns times na qual o Vinicius Pacheco já começou na publicação anterior (Mudanças Evolucionárias 1).
O início
Em junho de 2019, de uma área recém formada, comecei a acompanhar dois novos times também recém criados. E de início, havia varios desafios como mudança de gestão de projeto para a de produtos, desenvolvimento de POs e formação de times com objetivo de apoiar e desenvolver a cultura ágil na área.
Ao final de 3 meses o cenário já era outro. Muito diferente de um “caos com cerimônias” como quando começamos, o trabalho já tinha uma organização e tinhamos um aderência significativa ao framework scrum. No entanto, mesmo os times tendo evoluído muito, eles pareciam ter batido numa espécie de teto invisível.
Até esse momento, eu tinha sido o gatilho de evolução deles, provocando mudanças conforme meu conhecimento e minha experiência, entendendo suas dores e dificuldades no acompanhamento do dia a dia. Ambos os times já haviam formado suas identidades, e a partir daqui, era necessário que as mudanças não viessem mais através de mim, mas sim que eles mesmos fossem criadores e responsáveis de seus processos evolutivos. E para que isso fosse possível, eu precisava fornecer mais informações e insumos se eu quisesse permitir que as melhorias continuassem acontecendo.
Então, desde outubro adicionei ao acompanhamento um novo enfoque: gerenciar o fluxo. Parafraseando William Edwards Deming, “não se gerencia o que não se mede”, logo, para gerenciar eu precisava medir. As sprints e seus eventos continuaram normalmente e a partir da segunda quinzena de novembro comecei a mostrar alguns números. E dezembro usei as retrospectivas de cada times para apresentar, respectivamente, os resultados do acompanhamento trimestral.
As métricas apresentadas seguiram as que eu e o Pacheco vínhamos disseminando e trazendo à reflexão para todos os times da empresa. Para demontrar aqui, vamos falar dos times Alpha e Ômega.
O Lead Time médio do time Alpha foi de 62 dias e para o time Ômega foi de 78 dias. Durante o período ambos times já haviam compreendido o fluxo de trabalho e diferenciaram as etapas de discovery (upstream) e delivery (downstream). Aprofundando, para o time Alpha o upstream foi de 2 dias e o downstream foi 60 dias. Já para o time Ômega, o upstream foi de 20 dias e 58 dias para downstream. Também foi medido a quantidade de trabalho simultaneo ou paralelo (WIP) na fase de delivery. Time Alpha teve WIP médio de 6 itens e o time Ômega, 9 itens.
Resumindo
Time Alpha
Lead Time 62 dias
Upstream Lead Time 2 dias
Downstream Lead Time 60 dias
WIP de 6 itens.
Time Ômega
Lead Time 78 dias
Upstream Lead Time 20 dias
Downstream Lead Time 58 dias
WIP de 9 itens.
Diagnóstico
Não é difícil perceber que o Lead Time de ambos os times estavam altos e não ficamos satisfeitos. Mas quando se trabalha com métricas, alguns cuidados são necessários e é importante observá-los. Primeiramente, a métrica é simplesmente um número como uma foto tirada de algum momento. Ela sozinha não diz nada ou diz pouca coisa, mas evidencia um fato ou sintoma. Segundo, uma correta avaliação ou interpretação de qualquer dado vai depender da informação gerada em conjunto de outros dados (Upstream, Downstream e WIP). E terceiro, as métricas devem gerar ações, e quanto mais informações se tiver sobre o seu fluxo, melhores serão as escolhas e as implementações delas. Nesse caso, coletamos e geramos também para apoio os gráficos de Cumulative Flow (CFD) e Lead Time Breakdown.
De fato, dizer que em média uma história de usuário em ambos os times demorava mais de 2 meses deixou-nos desconfortáveis, afinal nós eramos os donos daqueles números. E mesmo que em intensidades diferentes em cada uma das pessoas, tal desconforto gerou o sentimento de dono.
Lições e Melhorias
De posse do diagnóstico, em cada um do times, analisamos, refletimos e iniciamos melhorias para mudar aquele cenário, e mesmo que estivessemos revisitando algumas ações, o entendimento nos deu foco e maior engajamento.
No time Alpha, a conclusão e foco foi no upstream. Os números no Lead Time Breakdown relembravam que em praticamente todos os itens de trabalho houve uma alta dependência do PO já que a qualidade dos itens de trabalho que entraram para delivery era baixa. Sendo assim, os itens tanto do backlog quanto os já em progresso foram revalidados e o fluxo de trabalho na etapa de discovery foi esmiuçado e amadurecido, e outras pessoas do time também passaram a fazer parte desse processo.
Já o time Ômega, por sua, compreendeu que sua maior falha era a quantidade de trabalho em paralelo. Sendo assim, as ações do time envolveram também rever os itens de backlog e em progresso, melhorando a qualidade, mas principalmente diminuindo o tamanho deles para entrar para delivery, e primordialmente assumir o compromisso de “parar de começar e começar a terminar”.
Resultado
Três meses depois, eu fechava e compilava os mesmos dados para todos os itens fechados no trimestre. Segue os números:
Time Alpha
Lead Time 43 dias
Upstream Lead Time 26 dias
Downstream Lead Time 17 dias
WIP de 8 itens.
Mesmo com um WIP maior decorrente de mudanças de prioridades, o esforço do time em melhorar o discovery e seus artefatos, embora tenha feito essa etapa aumentar, resultou numa queda de 72% na etapa de delivery e numa melhora de 31% da métrica de Lead Time.
Time Ômega
Lead Time 38 dias
Upstream Lead Time 23 dias
Downstream Lead Time 15 dias
WIP de 4 itens.
A revisão do backlog e a quebra dos itens deu um pouco de trabalho, mas isso facilitou muito a etapa de delivery; o compromisso do time em terminar os itens antes puxar um novo provocou um WIP de 4 e na identificação de um sistema constante (CONWIP), que representou uma diminuição de 75% na fase de dowstream e uma melhora de 52% no LT.
Várias outras ações foram tomadas para melhoria do fluxo de trabalho, no entanto, não houve nenhuma ação disruptiva. Basicamente todas as melhorias aplicadas por ambos os times são as comumente faladas em times ágeis. A diferença aqui, foi que elas foram embasadas em métricas. Segundo o KMM (Kanban Maturity Model), organizações de baixa maturidade pedem e aceitam melhor uma abordagem mais emocional para promover a mudanças. A medida que elas vão amadurecendo, como foi nosso caso, começam a encaram melhor e a se guiar por abordagem mais técnica, ou seja, baseada em fatos e dados.
Agradecimentos
Meu agradecimento à todas as pessoas na Unicred do Brasil por entender o momento e se propôr a fazer algo diferente e novo. Ao incrível grupo de agilistas na qual tenho o prazer de sempre aprender algo novo. À área de Credito & Investimento onde atuo pelo engajamento e compromisso sem iguais e especificamente pelos times Area51 e Ursau pelo crescimento e evolução perceptíveis. E não menos importante, ao Jonatan Aguiar e ao Vinicius Pacheco na qual tenho o privilégio de tê-los nessa jornada.
