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 apresenta as primeiras interpretações que podemos ter com este poderoso gráfico.
Já o segundo disserta sobre as métricas que podemos obter olhando para o CFD. E este terceiro é muito especial para mim, pois estende aquele escrito pelo meu grande e saudoso amigo Daniel Teixeira.
Neste artigo
O que você precisa saber sobre CFD antes de continuar a leitura
Este artigo é para visualizarmos, compreenderemos e atuarmos quando alguns padrões se formam. Ele tem como base o 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 com a analogia do Zoológico de CFD. Aqui reapresentarei os padrões demonstrando os pontos em que devemos ter 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 em relação à próxima.
A Figura 3 apresenta um CFD com 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 existam variações. Um item pode demorar um pouco mais, uma pessoa que não estava disponível, 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), mas elas 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 nosso cliente está sempre recebendo valor.
Deste ponto em diante, mostrarei os padrões que descrevem algum 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 determinada etapa do fluxo e não saem. Ao invés de pararmos, continuamos puxando mais itens para dentro daquela etapa.
Consequentemente, a quantidade de trabalho em progresso (WIP) aumenta conforme o tempo passa. O formato do gráfico fica parecendo com um jacaré de boca aberta.
Veja o CFD da figura 6. As coisas estavam indo bem até o quinto dia. Depois disso, os itens começam a entrar na etapa Construído e não avançam para Avaliando. Vamos colocar em formato de 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 itens na 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 fique amortecendo 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 dificulta um pouco.
É difícil acertar qual o Limite de WIP ideal e deixa pouca margem de manobra quando o Limite de WIP é atingido. Entretanto, não há certo e nem errado, apenas aquilo que o seu time se adapta melhor.
Uma vez que o WIP está limitado, deixamos o problema transparente. Agora, vamos ver como podemos 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 é: Independente da minha especialização ou preferência, qual é a movimentação mais estratégica que posso fazer para ajudar o meu time a entregar valor?
Olhando para o nosso exemplo, temos um acréscimo significativo da 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 estavam conseguindo 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ó é realizado em Entrega e tudo está parando em Construído.
O time deveria parar, dar dois passos para trás e ver qual seria a movimentação mais estratégica nesse momento. No caso, ajudar a 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, temos que 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 e nem uma sequência de passos. Apenas algumas ideias.
- Limitação do WIP e respeito a essa limitação. É 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 dentro 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 um aumento de 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 passa o item para outro time que faz 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 aqui. O grande desafio é que normalmente as empresas têm estruturas inteiras favorecendo a criação de dependências externas em silos de conhecimento.
Departamentos e diretorias inteiras são criadas para em função das especializações. Profissionais galgam posições e prestígio em suas áreas do conhecimento. Cargos de gestão são criados em função dessa estrutura. Muitas vezes é uma batalha que está muito além da nossa posição atual.
A dica que eu 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 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 para o ataque 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. A etapa inicial (ponto de compromisso) e final (ponto de entrega) parecem funcionar por rajadas.
Vamos ler o CFD da Figura 13. Entre o segundo e sexto dia os itens que estavam no 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 que o gráfico diz é que temos um dia que priorizamos os itens, 10 dias úteis para 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 subirá (Sprint Backlog). Temos uma Sprint aqui de 2 semanas (10 dias úteis).
No final, esse time faz a Reunião de Revisão (Sprint Review) e disponibiliza o incremento para o cliente. Logo em seguida, há uma nova Sprint Planning e assim vai.
“OK, mas onde está o problema?”
No fato desse time ter esperado o final da Sprint para disponibilizar o incremento do produto para o cliente. O Scrum Guide sempre foi claro em 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 o potencial de 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 com o final de semana) para começar a ganhar $1.000.000,00 por semana? Provavelmente não.
Nós já tratamos desse problema quando falamos 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 primário 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 as melhorias do 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 etapa; mais uma vez eles vão todos juntos para a próxima etapa. 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 logo em seguida ele desaba e todo 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 na 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 sobra é a fé 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, é esperado que todas as linhas estejam sempre em uma crescente. Na pior das hipóteses, a linha ficará em uma 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 um refluxo. Itens que já estavam na etapa Construído, foram para Avaliando, mas por algum problema voltaram (refluxo) para Construindo.
No primeiro artigo dessa série, discutimos sobre os problemas que ocorrem por causa do refluxo. Nós devemos sempre evitar o refluxo. As pessoas vão até o item, não é o item que deve voltar até as pessoas.
Uma outra possível causa, ainda pior, que pode provocar os dentes de tubarão acontece quando os itens estão sendo retirados do fluxo depois do 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 depois que iniciamos e antes de entregarmos?
Bicho-Preguiça
O Bicho-Preguiça aparece no CFD quando os itens ficam parados nas etapas deixando uma linha reta horizontal em que nada entra e nada sai.
Todavia, fique atento. Isso não quer dizer que o time está 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 o dia 11 e 14 houve uma “parada” no fluxo. Todas as etapas ficam na horizontal.
Nenhum item foi entregue em nenhuma etapa. Essa “parada” total é rara, é comum quando o time vai fazer um treinamento, um retreat ou algum tipo de recesso.
Aqui, temos alguns bichos-preguiça no nosso CFD. Para percebê-lo, você deve olhar 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 baseado em métricas e não em achismos.
Para aprender a desenhar um CFD desde o zero, participe do nosso treinamento de Kanban System Design.
