Quando iniciamos uma jornada que tenha como um dos objetivos elevar a maturidade do processo dos times, costumamos começar tornando visível o fluxo de trabalho destas equipes.

À medida que os times começam a enxergar as demandas fluindo pelas colunas do quadro kanban, aquele questionamento quase que inevitável surge:

Afinal de contas, posso mover os itens (cartões) para trás?

Há alguns poucos conteúdos sobre o assunto em inglês (Moving cards backwards, Avoiding going Backwards on Kanban, Kanban moving cards back), porém em português o único conteúdo que encontrei foi este vídeo bastante elucidativo do Rafael Buzon. Dada esta escassez decidi compartilhar nossa opinião a respeito.

Caso você esteja com pressa, esta é a nossa opinião: Evite mover itens para trás.

Agora se você dispuser de um pouco mais de tempo, vem comigo que vou explicar o porquê.

Por que recomendamos não mover itens para trás?

Imagine a seguinte situação: Um item de trabalho acaba de chegar em uma etapa de garantia de qualidade (coluna “Validando”) e alguns defeitos foram descobertos. Será necessário um esforço das pessoas desenvolvedoras para corrigir estes defeitos.

Suponha que a equipe optou por dar visibilidade para isso retornando o item de trabalho defeituoso para a etapa “Pronto para fazer”. Observe como esta movimentacão se reflete no quadro:

Confira a seguir as implicações desta escolha:

Complicações extras com os limites de trabalho em progresso (limite WIP)

Se você utiliza dos limites WIP para suavizar o fluxo de trabalho, mover itens para a esquerda pode complicar um mecanismo que deveria ser simples.

No exemplo, o item defeituoso estoura o limite da coluna de “Pronto para fazer”. E agora?

• Deixamos de resolver o problema para não estourar o limite?
• Ignoramos o limite e movemos de qualquer forma?

Acabamos de criar um dilema desnecessário. O quadro deveria induzir o time a tomar uma decisão rápida e não criar um debate improdutivo sobre as políticas do fluxo (que deveriam ser claras, diga-se de passagem).

Não haverá um sinal indicando que a prioridade é corrigir o defeito

O principal papel do quadro kanban é prover sinais visuais ao time, proporcionando tomada de decisão com autonomia e baixo custo de coordenação. Perceba que perdemos um pouco disso quando fizemos o item fluir para a esquerda:

• Ele acabou de se misturar com outros itens do backlog. E agora? O que deve ser feito primeiro? O quadro não comunica isso com clareza. Para que o item não seja esquecido, alguém vai precisar informar que aquele item em especial merece atenção (menos autonomia e mais custo de coordenação).
• Perdemos também o efeito swarming, que acontece quando o time colabora para remover um impedimento do fluxo, em qualquer etapa. Uma premissa para que isso funcione de maneira autônoma é que seja possível visualizar em que etapa o problema foi descoberto, o que já não é mais possível.

As métricas de processo possivelmente revelarão falsos positivos

Se você estiver (e espero que você esteja) medindo seu fluxo através de métricas de processo, mover itens para a esquerda pode não ser uma boa ideia.

Um dos grandes trunfos da instrumentação de um fluxo de trabalho com indicadores é a capacidade de diagnosticar problemas através da análise de lead time e das filas. Seria uma pena se estas métricas não falassem a verdade, não é mesmo? Veja:

• Se você estiver medindo o lead time e tiver o hábito de mover itens para trás quando encontra problemas, o lead time da etapa em que o item encontrou um bloqueio (“Validando”, por exemplo) não vai aumentar. Possivelmente isto vai acontecer em alguma outra coluna, como a “Backlog” ou “Fazendo”. Veja abaixo a comparação do lead time de uma mesma demanda, quando se move o item para trás e quando não se move:
• Ao analisar os gráficos como o Cumulative Flow Diagram (CFD) para fazer melhoria contínua, etapas que não são verdadeiramente problemáticas podem chamar sua atenção. Um tempo precioso pode ser perdido até que você entenda a real causa raiz do bloqueio e qual o plano de ação para sanar o problema.

Oportunidades de realizar melhoria contínua serão perdidas

A tendência de um sistema de trabalho, um sistema aberto, é se deteriorar se não houver iniciativas de melhoria. Se estamos negligenciando a melhoria contínua em nosso fluxo de trabalho, pagaremos o preço em breve, com juros e correção monetária.

Ter um conjunto de ferramentas que não nos alerta quando um problema acontece é uma maneira de incrementar esta dívida e fazer um voo cego, vulnerável aos riscos. Você já deve ter notado que mover itens para a esquerda quando se encontra um problema pode contribuir para isto, veja:

• Um item pode ser rejeitado inúmeras vezes na coluna “Validando”, voltar para o time de desenvolvimento e seguir sendo rejeitado em futuras tentativas. Isto é um sintoma de um problema de qualidade que precisa ser resolvido. Mover o item para trás toda vez que esse problema surgir vai mascarar sua causa raiz, tratando-o como um acontecimento corriqueiro. Isto não vai bloquear o avanço das outras demandas através do mecanismo de limite WIP, não vai doer nas pessoas. Se não dói não chama a atenção e uma oportunidade de melhoria vai ser negligenciada, uma pena.

O que fazer então?

Acredito que ficou evidente o que não se recomenda fazer ao encontrar bloqueios no fluxo de trabalho. Então vamos agora à parte onde compartilhamos maneiras de lidar com esta situação de maneira saudável.

Relembrando a situação, acabamos de encontrar um defeito durante a etapa de validação:

Da próxima vez que você se deparar com isto, tente o seguinte:

• Mantenha o item na coluna em que o problema foi encontrado.
• Dê algum tipo de destaque para o item problemático:
• Se você estiver usando um quadro físico, colar um post it chamativo sobre o item deve ser suficiente. É interessante que este post it descreva o problema a ser resolvido.
• Se você utilizar um quadro digital como no Trello ou JIRA, a maioria das ferramentas conta com uma funcionalidade de “bloqueio” que destaca o item desejado. Você também pode usar sub tarefas representando os problemas, para que o time consiga dar visibilidade para o progresso das correções.

O quadro vai ficar com uma aparência semelhante à esta:

Deste modo:

• Ao olhar para o quadro, ficaria evidente que um problema aconteceu, e que por ele estar mais à direita é mais importante eliminá-lo do que focar nas etapas anteriores. Isto tende a diminuir o lead time pois o time consumirá menos tempo pra responder ao problema e solucioná-lo. Abordamos este assunto em um blog post sobre daily meetings.
• Se um item fica bloqueado nesta coluna por muito tempo, gráficos como a distribuição de lead time e o CFD evidenciarão que há um gargalo ali. A coluna que vai chamar a atenção será claramente a “Validando”, onde a maioria dos problemas é descoberto em nosso exemplo. Esta informação é valiosa e vai proporcionar uma análise de causa raiz bem mais certeira.
• Se um item for corrigido diversas vezes e mesmo assim não satisfizer os critérios para sair da coluna “Validando”, tanto o quadro quanto as métricas passarão a evidenciar que há um gargalo ali, que algo está doendo e precisa ser remediado. Este é um belo convite à melhoria contínua.

Por que as pessoas sentem vontade de mover itens para trás?

Antes de seguir para o encerramento do texto, eu gostaria de propor um exercício de empatia. A frequência com a qual vivencio a situação que descrevi é considerável, o que me fez pensar:

Por que é tão intuitivo para as pessoas mover os cartões para trás?

Formulei então algumas hipóteses a respeito:

Favorece o status report

Ambientes onde a confiança é baixa tendem à microgestão. Reportar com precisão o que te mantém ocupado agora é incentivado em detrimento de dar visibilidade aos problemas do sistema.

Vejo isto se materializado naqueles dailies em que as pessoas falam o que estão fazendo e o que pretendem fazer, mas pouco se discute sobre os problemas que estamos enfrentando e como resolvê-los.

Em ambientes pouco colaborativos, é uma maneira de se eximir da culpa por um problema

Se o ambiente valoriza mais as contribuições individuais do que as coletivas e a responsabilidade de uma das pessoas do time é fazer a validação de qualidade dos itens de trabalho desenvolvidos, um acúmulo de itens na coluna “Validando” poderia denotar que esta pessoa não está conseguindo dar a vazão necessária ao trabalho, ou que o problema descoberto foi causado por ela (quando na verdade foi apenas descoberto na etapa em que ela costuma atuar).

É muito mais confortável transferir esta reponsabilidade para outra pessoa movendo o item para outra coluna.

Para ambos os casos citados, parece fazer sentido demonstrar as vantagens da colaboração para a saúde do fluxo de trabalho, e por que não, das pessoas envolvidas nele. Para ler mais a respeito de colaboração e gestão de fluxo, confira este ebook que escrevi: http://pages.plataformatec.com.br/5-estrategias-para-otimizar-fluxo-de-desenvolvimento-de-software.

Finalizando

Quero aproveitar o trecho final para destacar que a minha intenção não é mostrar o que é certo e o que é errado, é simplesmente discutir práticas que funcionaram melhor nas situações que nós já enfrentamos. Imagino que sim, deve haver algum cenário em que faça sentido mover os itens para trás, e tudo bem.

Outro ponto que gostaria de destacar é que é importante deixar as pessoas experimentarem um contexo, para que depois reflitam sobre como podem melhorar sua situação atual e façam a sua escolha. Para o assunto que foi levantado, não vejo problema algum em permitir que um time rode por algumas semanas movendo itens para trás para que depois seja apresentado ao outro modelo. Um bom momento para se fazer isso parece ser quando se inicia a adoção das métricas de processo.

E você? Já passou por esta situação com algum time? Já sentiu vontade de mover itens para a esquerda? Como lidou com isso? Quero ouvir sua opinião nos comentários!