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.
Excelente artigo.
Onde posso conhecer mais formas gráficas de mostrar a evolução/andamento do projeto ?
O que o CFD não te atende?
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?
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!
Pingback:Treinamento Kanban credenciado LKU em todo Brasil! | Débito Técnico
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!
Rodrigo, o Wiphub.com ainda é um produto da Aspercom? Está em funcionamento?
Obrigada.
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?
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.
Rodrigo, ainda não consegui montar um CFD. Seria possivel ter acesso a algum modelo?
Grata
Te mandei no email!!!
Se possível gostaria de ter acesso ao modelo de um CFD no excel. Se puderes enviar agradeço!
Lane, tente esse. Não é excell, mas funciona. Leia as instruções.
http://bit.ly/metricaskb
Rodrigo bom dia
Como vc recomenda contar o tempo de um cartão no quadro kanban?
Num quadro “raiz”, ou seja, em papel na gestão à vista.
Algum tipo de marcação no cartão?