Como identificar padrões (e evitar disfunções) no Cumulative Flow Diagram (CFD)? O presente artigo é o último de uma série de três que escrevemos sobre Cumulative Flow Diagram (CFD). O primeiro foi sobre como construir um CFD e apresentou as primeiras interpretações que podemos ter sobre este poderoso gráfico. Já o segundo disserta sobre as métricas que podemos obter ao olhar para o CFD. E este terceiro é muito especial para mim, pois estende aquele escrito pelo meu grande e saudoso amigo Daniel Teixeira.
O que você precisa saber sobre CFD antes de continuar a leitura
Este artigo é para visualizarmos, compreendermos e atuarmos quando se formarem alguns padrões. Ele baseia-se no artigo do Daniel, escrito em 2017. Recomendo que você o leia também: Como ler um CFD – Padrões de disfunções.
Lá, o Daniel apresenta os padrões por meio da analogia do Zoológico de CFD. Aqui reapresentarei os padrões, demonstrando os pontos de atenção e possíveis soluções para as disfunções que provocam alguns desses padrões.
Para facilitar o entendimento, utilizaremos o fluxo de trabalho a seguir, o mesmo do segundo artigo desta série.
Ao longo deste artigo, vou trazer aqui para você:
- Animais do Zoológico CFD — Baleia Penteada, Boca de Jacaré (e suas possíveis causas) e Pescoço da Girafa;
- Analogia do Cachorro-quente;
- Animais acrescentados por mim — “Dente de Tubarão” e “Bicho Preguiça”.
A Baleia Penteada
O primeiro animal do nosso zoológico bem moderno (tem até baleia) é o padrão que descreve o bom andamento de um fluxo de trabalho. Nele, a quantidade de trabalho em progresso (WIP) permanece sem grandes variações entre uma etapa e outra do fluxo. É como se cada etapa formasse uma linha paralela à próxima.
A Figura 3 apresenta um CFD de uma Baleia Penteada perfeita. Não há variação entre as etapas e o trabalho em progresso (WIP) de cada uma delas é estático e linear. Esse é um modelo teórico, já que, no dia a dia, é normal que haja variações. Um item pode demorar um pouco mais: uma pessoa que não estava disponível ou um gargalo no fluxo. Enfim, algumas variações são comuns.
A Figura 4 apresenta uma Baleia Penteada mais factível. Há pequenas variações nas etapas do fluxo (aumento do WIP), que são corrigidas rapidamente e voltam ao estado anterior, mantendo um fluxo de entrega constante.
A Baleia Penteada é aquele padrão que nós queremos ter no nosso trabalho. É um fluxo que garante que não estamos puxando mais trabalho do que conseguimos entregar e que nosso cliente está sempre recebendo valor.
Deste ponto em diante, apresentarei os padrões que descrevem um tipo de disfunção que atrapalha o progresso do item ao longo do fluxo.
Boca de Jacaré
Essa é uma das disfunções mais comuns, se não a mais comum. Nela, os itens entram em uma etapa específica do fluxo e não saem. Em vez de pararmos, continuamos puxando mais itens para aquela etapa.
Consequentemente, a quantidade de trabalho em progresso (WIP) aumenta à medida que o tempo passa. O formato do gráfico fica parecendo um jacaré de boca aberta.
Veja o CFD da figura 6. As coisas estavam indo bem até o quinto dia. Depois disso, os itens passam para a etapa Construído e não avançam para a etapa Avaliando. Vamos organizar em uma tabela para vermos o que aconteceu ao longo do tempo.
| Dia | Backlog | Refinando | Priorizado | Construindo | Construído | Avaliando | Avaliado | Entregando | Entregue |
| 1 | 20 | ||||||||
| 2 | 19 | 1 | |||||||
| 3 | 18 | 1 | 1 | ||||||
| 4 | 17 | 1 | 1 | 1 | |||||
| 5 | 15 | 1 | 1 | 2 | 1 | ||||
| 6 | 14 | 1 | 1 | 1 | 2 | 1 | |||
| 7 | 11 | 1 | 1 | 1 | 4 | 1 | 1 | ||
| 8 | 8 | 1 | 1 | 1 | 6 | 1 | 1 | 1 | |
| 9 | 5 | 1 | 1 | 1 | 8 | 1 | 1 | 1 | 1 |
| 10 | 3 | 1 | 1 | 1 | 10 | 1 | 1 | 1 | 1 |
| 11 | 0 | 0 | 1 | 2 | 12 | 1 | 1 | 1 | 2 |
| 12 | 0 | 0 | 1 | 2 | 8 | 2 | 2 | 1 | 4 |
| 13 | 0 | 0 | 0 | 1 | 6 | 1 | 2 | 2 | 8 |
| 14 | 0 | 0 | 0 | 0 | 3 | 3 | 3 | 2 | 9 |
| 15 | 0 | 0 | 0 | 0 | 1 | 2 | 2 | 2 | 13 |
Perceba que os itens do dia 6 em diante chegaram à etapa Construído e alguns até saíram, mas a vazão dela não foi suficiente e o trabalho se acumulou, ou melhor, “engargalou”. A partir do dia 12, o jacaré começou a fechar a boca e o fluxo voltou ao normal aos poucos.
Possíveis causas para a Boca de Jacaré
A falta de limitação de WIP e o excesso de dependências externas podem ser grandes responsáveis por formar uma Boca de Jacaré no seu gráfico.
Colunas não limitadas ou limites não respeitados
Uma das causas mais comuns da Boca de Jacaré é a falta de limitação do Trabalho em Progresso, o famoso Limite de WIP. Este tem que ser utilizado em todas as etapas e deve ser respeitado. Sem ele, acabamos criando um amortecedor (buffer) que tende a crescer indefinidamente.
A primeira coisa que a pessoa que facilita o time tem que fazer é limitar o WIP para evitar que qualquer estágio amortecesse o fluxo de trabalho.
Você pode limitar também cada estágio do seu fluxo de trabalho. Particularmente, se o fluxo do seu time for muito grande, acho que isso dificulta um pouco.
É difícil acertar qual é o limite ideal de WIP e deixa pouca margem de manobra quando esse limite é atingido. Entretanto, não há certo nem errado, apenas aquilo a que o seu time se adapta melhor.
Uma vez que o WIP está limitado, deixamos o problema transparente. Agora, vamos ver como fechar essa Boca de Jacaré.
Uma técnica pontual que podemos utilizar é o Enxame (Swarm). Ela funciona da seguinte forma. Quando atingimos o Limite de WIP, o ideal é que o time inteiro dê dois passos para trás, olhe o fluxo mapeado no Quadro de Tarefas da direita para a esquerda (Entregue para Backlog).
A pergunta que os membros do time devem fazer é: Independentemente da minha especialização ou preferência, qual é a ação mais estratégica que posso realizar para ajudar o meu time a entregar valor?
Olhando para o nosso exemplo, observamos um acréscimo significativo na coluna de espera Construído. Isso mostra que os profissionais responsáveis pela construção continuaram construindo, construindo e construindo. Mas as pessoas da avaliação não conseguiam avaliar na mesma velocidade. Formou-se um grande gargalo no fluxo de trabalho.
Esse deveria ser o lema de todo time. Não adianta ter muita iniciativa sem acabativas. No nosso exemplo, não adianta continuar construindo se o valor só é cobrado na Entrega e tudo está parando em Construído.
O time deveria parar, dar dois passos para trás e avaliar qual seria a movimentação mais estratégica nesse momento. No caso, ajudar na avaliação. Poderíamos fazer alguns acordos para evitar problemas.
Por exemplo: “Eu só avalio o que eu não construí.” O time iria, como um enxame, atacar o gargalo para resolver o problema. Entretanto, essa é uma solução temporária. Uma vez resolvido, precisamos buscar soluções definitivas para que a disfunção não volte a ocorrer.
Abaixo segue uma lista de possíveis soluções para resolver o problema da Boca de Jacaré de forma definitiva. Não é uma lista exaustiva e está na ordem que eu, Avelino, prefiro tentar. Não é uma regra nem uma sequência de passos. Apenas algumas ideias.
- Limitação do WIP e respeito a ela. É obrigatória e já falamos sobre ela.
- Automatizar parte do processo de avaliação.
- Colocar pessoas de Construção trabalhando junto com Avaliação para que a etapa de Construção seja modificada, tornando o trabalho da Avaliação mais eficiente.
- Treinar mais pessoas do time para auxiliar nas etapas de avaliação.
- Contratar mais alguém para auxiliar a avaliação. Entretanto, muito cuidado. Aumentar o time nem sempre garante maior eficiência.
Dependência Externa
Outro problema que costuma gerar bocas de jacarés é quando temos dependências externas no nosso fluxo de trabalho. Por exemplo: O meu time prioriza, constrói, mas não avalia. Ele encaminha o item para outro time que realiza a avaliação.
Nesse caso, teremos o problema de assimetria de prioridades. Um item que pode ser ultra importante para o meu time pode ser irrelevante para o outro. Quanto mais dependências, mais bocas de jacarés são esperadas no seu CFD.
A solução para esse problema não é simples. Já comentamos sobre ela nesse artigo. O grande desafio é que, normalmente, as empresas têm estruturas inteiras que favorecem a criação de dependências externas em silos de conhecimento.
Departamentos e diretorias inteiras são criados com base nas especializações. Profissionais galgam posições e prestígio em suas áreas do conhecimento. Cargos de gestão são criados com base nessa estrutura. Muitas vezes é uma batalha que está muito além da nossa posição atual.
A dica que posso dar é: seja transparente, mas sem ser arrogante. Há uma trinca que devemos ter quando formos discutir esse assunto principalmente com a alta gestão (C-Level). Primeiro, são os fatos e os dados.
Qual o lead time do time? Qual é o System Lead Time? Qual o Cycle Time das dependências externas ? Abordamos esses assuntos no segundo artigo dessa série.
Segundo, ligue os pontos. Dado que os fatos são esses, quais os impactos que eles provocam nas métricas de eficácia (Receita, Churn, Satisfação do Cliente, RoI…)?
Por fim, vá sempre com um conjunto de possíveis soluções. Se você for para uma discussão dessas com uma única solução, por exemplo, abolir a dependência externa e internalizar 100% do trabalho deles, é provável que esse outro time entre na defensiva e inicie uma batalha pela sobrevivência e contra o seu.
Cachorro-Quente
Eu sei, eu sei, Cachorro-Quente não é um animal, mas é uma analogia. O padrão Cachorro-Quente forma escadinhas em que o trabalho horas está zerado, de repente aumenta e, em seguida, diminui. As etapas iniciais (ponto de compromisso) e finais (ponto de entrega) parecem funcionar em rajadas.
Vamos ler o CFD da Figura 13. Entre o segundo e o sexto dia, os itens do backlog foram priorizados. No sétimo dia, 6 itens foram priorizados. Eles foram desenvolvidos até o décimo quinto dia (10 dias úteis desde o início).
Um dia depois, iniciou a entrega (delivery). Nesse mesmo dia, foram priorizados mais seis itens, que foram desenvolvidos até o vigésimo quinto dia (10 dias úteis desde o início do segundo ciclo).
O gráfico mostra que temos um dia em que priorizamos os itens e 10 dias úteis para o desenvolvimento (Construção + Avaliação). Depois, passamos tudo para produção e, nesse mesmo dia, há uma nova priorização. Com que tipo de framework isso se parece?
Se você disse “Scrum”, acertou e errou ao mesmo tempo. Você acertou porque, realmente, o Scrum acaba promovendo um formato tipo Cachorro-Quente.
Quando fazemos a Reunião de Planejamento da Sprint (Sprint Planning), a quantidade de itens (WIP) em Priorizados realmente aumentará (Sprint Backlog). Temos uma sprint de 2 semanas (10 dias úteis) aqui.
No final, esse time realiza a Reunião de Revisão (Sprint Review) e disponibiliza o incremento ao cliente. Logo em seguida, há uma nova Sprint Planning e assim vai.
“OK, mas onde está o problema?”
No fato de esse time ter esperado o final da Sprint para disponibilizar o incremento do produto ao cliente. O Scrum Guide sempre foi claro ao dizer que não é preciso esperar o final da Sprint para disponibilizar o incremento. Ele pode ser feito durante a Sprint.
Imagina que você tem um item que, quando for entregue, tem potencial para gerar $1.000.000,00 de receita por semana. Você começou a sua Sprint de dez dias úteis na segunda-feira e, na terça, esse item já está pronto para ser entregue. Você vai esperar 9 dias úteis (11 se contar o final de semana) para começar a ganhar $1.000.000,00 por semana? Provavelmente não.
Nós já tratamos desse problema ao falarmos sobre a revisão do Scrum Guide na versão de 2017. Isso foi reforçado no Scrum Guide de 2020. Faço aqui uma citação direta dessa última versão:
“No entanto, um incremento pode ser entregue aos stakeholders antes do final da Sprint. A Sprint Review nunca deve ser considerada um marco para liberar valor.”
Ken Schwaber and Jeff Sutherland, Scrum Guide 2020 – Português Brasil, P.13
Tenha em mente que a Reunião de Revisão da Sprint (Sprint Review) tem como objetivo principal obter feedback dos clientes. Ela não é uma reunião de aprovação/reprovação do que foi construído.
Por experiência, ela é muito melhor quando você já fez a entrega do incremento e tem métricas de eficácia para discutir melhorias no produto.
Pescoço da Girafa
Esse padrão funciona da seguinte forma: em um momento, eu tenho todos os itens em uma etapa; depois, eles vão juntos para a próxima; mais uma vez, eles vão todos juntos para a próxima. O gráfico CFD fica mais ou menos assim:
Perceba que, nesse padrão, o WIP de uma etapa aumenta vertiginosamente durante alguns dias e, em seguida, desaba, e todo o WIP vai para a próxima.
Com qual método ele parece? O bom e velho Cascata (Waterfall). Quem analisa, analisa tudo. Depois passa para o design que desenha tudo, depois passa para os desenvolvedores que desenvolvem tudo e por aí vai.
O que eu devo fazer se o CFD do meu time estiver assim ou próximo disso? Minha recomendação sincera é: imprima o Salmo 23, mais especificamente o verso 4, cole bem à frente do seu computador e leia-o todo o dia.
Já que não entregamos nada, não coletamos feedback, não atualizamos o backlog e demoramos horrores para fazer uma entrega, o que nos resta é a fé de que tudo vai dar certo no final. 😃😃😃
“Ainda que eu ande pelo vale da sombra da morte, não temerei mal nenhum, porque tu estás comigo; o teu bordão e o teu cajado me consolam.”
Salmos 23.4 (ARA)
Se possível, comece a mudar esse método o quanto antes. Pense que:
Dente de Tubarão
Meu amigo Daniel escreveu até o Pescoço da Girafa. Infelizmente não tenho a mesma criatividade dele para dar nomes aos animais do zoológico. Mas um padrão que costumamos encontrar por aí é a subtração de WIP do fluxo de valor após o ponto de compromisso. Formando uma espécie de Dente de Tubarão no CFD.
O CFD é um gráfico cumulativo. Logo, espera-se que todas as linhas estejam sempre em crescimento. Na pior das hipóteses, a linha ficará em uma posição horizontal (180°).
Quando uma linha desce, é algo inesperado. Veja o que aconteceu com a etapa “Construindo e Construído” nos dias 11 e 13. A linha do construído cai e forma um “dente” no CFD que não deveria existir.
Isso provavelmente é consequência de refluxo. Itens que já estavam na etapa Construído foram para a etapa Avaliando, mas, por algum problema, voltaram (refluxo) para a etapa Construído.
No primeiro artigo dessa série, discutimos os problemas decorrentes do refluxo. Nós devemos sempre evitar o refluxo. As pessoas vão até o item; não é o item que deve voltar a elas.
Uma outra possível causa, ainda pior, que pode provocar os dentes de tubarão ocorre quando os itens são retirados do fluxo após o ponto de compromisso.
Nesse caso temos um grandíssimo problema para resolver. Por que estamos fazendo coisas que se tornam tão irrelevantes que são descartadas logo após iniciarmos e antes de entregarmos?
Bicho-Preguiça
O Bicho-Preguiça aparece no CFD quando os itens ficam parados em uma etapa, deixando uma linha reta horizontal em que nada entra nem sai.
Todavia, fique atento. Isso não quer dizer que o time esteja parado, sem fazer nada. Apenas que os itens de trabalho estão parados nas etapas do fluxo de valor.
Neste exemplo, temos um fluxo que caminhava muito bem, mas entre os dias 11 e 14 houve uma “parada”. Todas as etapas ficam na horizontal.
Nenhum item foi entregue em nenhuma etapa. Essa “parada” total é rara; é comum quando o time faz um treinamento, um retreat ou algum tipo de recesso.
Aqui, temos alguns bichos-preguiça no nosso CFD. Para percebê-lo, você deve olhar para a linha posterior à etapa que está analisando.
Por exemplo, há um Bicho-Preguiça em Construído entre os dias 8 e 10. Há outros bichos-preguiça em Refinando, Priorizado e Construindo nos dias 8 e 9, e depois, mais uma vez, nos dias 10 e 11. Mais um bichinho em Entregando entre os dias 12 e 13.
Conclusão: com o CFD, temos mais métricas e menos achismos!
Eu trouxe aqui alguns padrões de funções e disfunções que podemos observar no CFD. Saber identificá-los é muito importante para que tomemos decisões de melhoria do fluxo de trabalho sempre baseadas em métricas e não em achismos.
Para aprender a desenhar um CFD do zero, participe do nosso treinamento de Kanban System Design.
