O Cumulative Flow Diagram

Uma das coisas que mais me preocupam no mundo Agile atual são certas miopias. Implementações Scrum pipocam aqui e alí, e como já havia comentado aqui no blog, as empresas grandes estão acordando para Agilidade. Nas minhas andanças em clientes em São Paulo e outras cidades (fora o contato com mais de 30 clientes do mundo todo pelos produtos FlowKaizen e Wiphub, ambos da Aspercom) tenho escutado uma conversa bastante comum:

Aqui na XPTO Tech temos um projeto piloto que queremos que seja ágil. O escopo dele não irá mudar tanto, nós analizamos tudo muito bem e investimos um mês e meio na construção do backlog. Agora chegou a fase de começar a rodar Sprints…

Um dos maiores problemas do Agile é ele ter nascido na TI, ser um assunto de TI e defendido fervorosamente por “programadores”. Essa conversa acima é bastante comum. Nessa mentalidade o Agile é relegado a um assunto “técnico”. Várias vezes já discuti com CIOs, CTOs e Gerentes sobre essa visão equivocada. Uma das maiores armas para mudar essa forma de pensar é criar visualizações do problema (prática Kanban). Um Cumulative Flow Diagram (ou simplesmente CFD) pode auxiliar nesta visualização. Veja o gráfico a seguir:

Este gráfico é de um cliente real da Aspercom. O CFD é um gráfico bem simples. Ele demonstra a quantidade de trabalho acumulado demonstrando a saúde do fluxo do processo. No eixo X temos o tempo e no eixo Y temos o número de itens de trabalho que podem ser demandas, funcionalidades, stories, bugs, casos de uso e etc. Neste gráfico a camada amarela demonstra o escopo (ou backlog) do projeto. A camada vermelha é o trabalho em progresso (work-in-progress ou simplemente WIP – trabalhos iniciados mas não terminados). A camada azul demonstra as entregas (isto depende da sua definição de entregue, uma grande discussão que pode ficar para outro artigo).

Observando este gráfico acima você consegue advinhar o que aconteceu neste projeto? O CFD conta uma história clara: entre as semanas 1 e 6 a equipe puxava novos trabalhos mesmo sem terminar os trabalhos antigos. Isso congestionou o fluxo de trabalho até a semana 7, quando começamos a usar Kanban colocando uma meta de ter somente 10 itens no WIP. O Kanban mostrou gargalos e impedimentos organizacionais que foram resolvidos gradativamente. Da semana 7 até a semana 10 tivemos um período de adaptação, onde nenhum novo item foi puxado do escopo até conseguimos chegar na meta de 10 itens no WIP. A partir da semana 9, com o WIP limitado, note como a inclinação da camada azul se tornou mais estável e previsível. Este gráfico explica muito bem a razão do Kanban limitar WIP e os ganhos econômicos dessa prática: mais agilidade, menos filas, menor leadtime entre outras coisas. Como falei, este gráfico é real e tenho visto este padrão em diversas equipes usando Kanban (e/ou Scrum).

O Cumulative Flow Diagram – como outras métricas Lean – mostra a saúde do sistema sem alterá-lo. O CFD não é usado como meta ou objetivo como um Burndown Chart. O CFD cria uma visualização de “estoques” de trabalho a fazer e trabalho em progresso. Alguns CFDs possuem 4, 5 e até 10 camadas, separando o WIP em Análise, Desenvolvimento, Testes e etc… Assim ele pode evidenciar se o trabalho se acumula mais em alguma etapa específica do processo. Ultimamente tenho usado a prática “WIP é WIP”, isto é, se está em progresso é WIP, não importando qual o estado do trabalho. Isso facilita a construção do gráfico e torna o CFD uma ferramenta mais simples. Veja mais este exemplo.

Antes de continuar a leitura, tente analisar este processo. Se você compreendeu o conceito até aqui você deve ter chegado a conclusão que este é um processo cascata. Todo o escopo foi levantado prematuramente, todo trabalho foi feito como um grande lote único e a implantação foi “Big Bang”. Claramente esta equipe correu muitos riscos de qualidade em ter um WIP tão alto, pois não tinha os resultados palpáveis do trabalho (veja as entregas – a camada azul). Um processo cascata simplesmente não tem fluxo. É imprevisível.

Veja mais um exemplo:

O CFD idealmente deve começar a ser plotado assim que o projeto começou a ser discutido e não quando iniciou a implementação. A corrente de valor é muito mais que a construção e o CFD deve mostrar outras áreas da empresa que podem não ser ágeis (como exemplo uma área de produto ou marketing que fica cozinhando o escopo e depois pede urgência). Essa visão holística do CFD demonstrará o problema da XPTO Tech citada no inicio do artigo, oferecendo oportunidades de melhoria. A falta dessa visualização do nascimento e crescimento do escopo é uma falha que vejo na maioria dos Burndown Charts. Outra falha do Burndown Chart é ele não rastrear WIP.

Neste gráfico “pronto” (done) é software em produção, assim, vemos que esta equipe fez dois releases grandes. Este é um padrão que tenho observado em algumas equipes saindo do cascata e indo para o Scrum: o escopo cresce prematuramente e os releases são grandes. Verifique como se comportou o escopo (faixa amarela) – o gráfico mostra que um grande release planning de várias semanas aconteceu no início, seguido de mais um aumento de escopo (mais um release planning, talvez) a partir da 10a. semana. Isso nos leva a um questionamento: Rodar Sprints para vencer um backlog ou roadmap que demorou semanas para ser elaborado em outra área é ágil? Note o quanto de atraso o projeto teve nas semanas iniciais. Agilidade é uma estratégia para iterar sobre o problema e a solução. O CFD deixará claro se isso não é verdade na sua empresa.

Analisar a camada amarela de um CFD nos diz muita coisa: se ela estiver muito larga significa que a expectativa sobre o projeto está alta. Isto é um risco, pois pode demonstrar, como exemplo, que o Product Owner está especulando demais sobre o escopo sem entregar valor. O CFD também demonstra claramente para o PO que colocar mais coisas no Backlog não faz a equipe andar mais depressa.

O CFD é uma ferramenta que tem me auxiliado muito em diversos ambientes, pois é uma métrica independente do ciclo de vida do processo (cascata, timebox ou fluxo contínuo). Essa versatilidade é importante para mudanças incrementais de processos – os gestores e a equipe resistem muito a mudanças até compreenderem o real problema. Você pode pode passar a usar um CFD sem mudar seu processo atual e usar Kaizen para melhorá-lo incrementalmente. Visualizações e métricas ajudam uma empresa a tomar melhores decisões sobre os processos.

Muitas pessoas me perguntam o que seria o CFD “ideal”. A resposta é simples: Quanto menos estoques, mais Lean é. Se o processo está melhorando os estoques estão diminuindo e não aumentando. Veja este gráfico de um projeto interno real da Aspercom:

Este seria o gráfico típico de uma Lean Startup: o problema sendo “experimentado” junto ao desenvolvimento, sem longos backlogs, com baixo WIP e releases constantes. Mais uma vez, o CFD nos mostra a saúde do fluxo. Ele não deve ser usado como meta de entrega ou para pressionar a equipe, empurrando o sistema de trabalho. Uma citação que gosto muito é:

“When a measure becomes a target, it ceases to be a good measure.”
Goodhart’s law

Métricas observam um sistema de trabalho e idealmente não devem modificá-lo. Você pode usar as métricas Lean mesmo em um processo Scrum. Primeiro para observar o sistema além das Sprints e segundo para entender filas, trabalho em processo e a fluidez dentro da própria Sprint.

About The Author

rodrigoy

Instrutor e Consultor Sênior - ASPERCOM

Deixe sua opinião!

20 Comments

  • Excelente artigo.

  • Gabriel Oliveira

    Reply Reply 03/04/2012

    Onde posso conhecer mais formas gráficas de mostrar a evolução/andamento do projeto ?

  • O que o CFD não te atende?

  • Paula

    Reply Reply 10/04/2012

    Eu mapeio como backlog apenas o que eu tenho já detalhado ou tudo que eu já sei que o cliente já me disse que queria, deixando o detalhamento para a sprint que ele será entregue em parte ou no todo?

    Obs.: Ainda não consigo ver realmente uma revolução nessas coisas. Acho bom existir um aglutinador dessas ideias, mas não vejo nos modelos antigos nada que não permitisse que isso fosse feito. O problema e a solução passam sempre pelas pessoas certas.

    • Cada camada do Cumulative Flow pode ser interpretada à sua maneira. Se no seu time backlog é o esforço de detalhamento assim o considere. Se é somente escrita de histórias que assim seja.

      Não entendi o que você quis dizer com revolução. Cumulative Flows são práticas antigas em Lean Product Development.

  • Excelente artigo sobre CMMI!

    • Não me lembro de ver Cumulative Flows no CMMI… fontes?

      • Roberto Slomka

        Reply Reply 10/08/2012

        Olá Rodrigo, o comentário foi uma forma divertida e – claro – provocativa (no bom sentido) de derrubar barreiras. Alguns agilistas acreditam que Agile e CMMI sejam como água e azeite, principalmente quando conhecem organizações onde o processo criado sob a inspiração do CMMI é deturpado por burocratização, e em contrapartida acabam criando barreiras em torno das idéias e se fechando em guetos virtuais. Como um colega me indicou este artigo, respondi com certa ironia para provocar a reação. Em verdade o Agile endereça muitas das necessidades de gestão que o CMMI aborda e desta forma o CFD está sim no modelo, ainda que implícito, como as necessidades de gestão de escopo e de requisitos. Pra não deixar de citar uma fonte interessante sobre o tema: http://www.sei.cmu.edu/library/abstracts/reports/08tn003.cfm (SEI: CMMI or Agile: Why Not Embrace Both!) Abraço!

        • Roberto, não tenho críticas ao modelo CMMI, mas sim a essa parte má interpretada do mercado. Atualmente métricas da saúde do processo tem me ajudado muito em consultorias para melhoria do processo.

  • Parabéns pelo post Rodrigo!

    No projeto relativo ao último gráfico (o ideal), como foi o levantamento de requisitos desse projeto?

    Estou acostumado a utilizar o conceito de MVP, o que normalmente reduz o escopo inicial de um projeto. Mas mesmo usando este conceito normalmente o backlog começa com bastante coisa.

    No caso do último gráfico a equipe começou a desenvolver quando o backlog tinha apenas 5 itens.

    • Olá Nicolas. O levantamento foi totalmente “on the fly”. Antes mesmo de pensar no MVP já existem alguns experimentos que podem ser colocados no ar como a Landing Page, o compartilhar em redes sociais e o conceito visual. Neste projeto, o primeiro deploy na semana 3 na verdade não era o MVP. O MVP foi ao ar mesmo na semana 6. Se a Landing Page não tivesse acessos ou shares nem valeria a pena pensar no MVP (neste caso).

      Lembro também que era uma equipe de somente 2 pessoas inicialmente (eu e um web designer).

  • Excelente artigo!

  • Rodrigo

    Reply Reply 11/03/2013

    Olá Rodrigo, tudo bem?

    Achei bem interessante a abordagem do CFD. Gostaria de saber qual seria o passo a passo para construí-lo no excel. Tem como?

    Obrigado.

    • O Excel tem como fazer esse gráfico “empilhado”. Basta você fazer uma tabela semanal com “Backlog”, “In Progress”, “Done” e fazer o gráfico. É simples!

  • Luciene

    Reply Reply 14/09/2014

    Rodrigo, o Wiphub.com ainda é um produto da Aspercom? Está em funcionamento?

    Obrigada.

  • Wemerson Souto

    Reply Reply 20/06/2016

    Quando vc diz:
    “Ultimamente tenho usado a prática “WIP é WIP”, isto é, se está em progresso é WIP, não importando qual o estado do trabalho”

    No caso de scrum o que esta selecionado para o Sprint e não foi iniciado esta no WIP em progresso?

    • rodrigoy

      Reply Reply 07/07/2016

      No caso do Scrum você pode pode considerar que entra no WIP assim que o planning termina. Se você quiser ver as filas dentro da Sprint você pode quebrar o WIP em mais camadas no Cumulative Flow.

  • Carolina

    Reply Reply 06/07/2016

    Rodrigo, ainda não consegui montar um CFD. Seria possivel ter acesso a algum modelo?

    Grata

    • rodrigoy

      Reply Reply 07/07/2016

      Te mandei no email!!!

Leave A Response

* Denotes Required Field