Você já ouviu falar em Limite de WIP e seus benefícios. A Lei de Little diz que o throughput tende a aumentar e o lead time tende a diminuir conforme se limita o trabalho em progresso. Existem atividades práticas muito lúdicas para mostrar o ganho em limitar WIP, e geralmente os times se mostram convencidos na hora… Porém, em muitas vezes, é só voltar para a correria do dia a dia para o limite de WIP ser desrespeitado.

A quebra do limite de WIP, muitas vezes impulsionada por pressão em entregas ou motivos similares, é mais do que o desrespeito a uma convenção: é a quebra de pelo menos dois princípios ágeis:

• Sustentabilidade: Processos ágeis promovem um ambiente sustentável, com patrocinadores, desenvolvedores e usuários sendo capazes de manter passos constantes.
• Revisão: “A contínua atenção à excelência técnica e ao bom design aumenta a agilidade.”

Como gerente de projetos ágeis, me senti desafiado a buscar soluções melhores para lidar com isso, e tive um bom achado nesse vídeo, que serviu de base para este blog post.

O quadro abaixo ilustra um board de projeto fictício, baseado em casos reais (talvez você tenha se deparado com algo bem parecido no seu time), de forma fácil de reproduzir em uma ferramenta como Jira ou Trello.

Kanban fala de gestão de filas (um pouco sobre isso aqui). Filas são estados no quadro onde o trabalho não está necessariamente sendo feito, mas sim esperando para ser feito.
Se analisarmos o quadro acima e ilustrarmos de outra maneira, sem mudar o fluxo, temos:

Em laranja, temos as colunas de fila. Esse agrupamento por “design”, “desenvolvimento” e “teste” considera unicamente o nome das colunas usadas no quadro tradicional, e as etapas em cada uma delas.

Olhando o quadro assim, aparentemente não tem nada anormal. Mas vamos adicionar algumas issues:

Uma equipe não tão familiarizada e madura com os conceitos de Kanban, ao olhar a imagem acima, teria alta probabilidade de dizer que ”a equipe de testes não está dando conta”.

Quando o trabalho de desenvolvimento termina, o cartão é movido para a coluna “ready to test“. Para uma equipe com baixa maturidade em Kanban, enviar o item para a coluna “ready to test” alimenta o pensamendo de “acabei a minha parte, vou puxar outro card”. A própria nomenclatura da coluna colabora com a ideia de que acabou o desenvolvimento e, agora, aquele item é problema responsabilidade da equipe de testes. Isso parece muito com um sistema empurrado, o contrário do que o Kanban prega, o sistema puxado.

Aqui entra a proposta deste texto: vamos fazer uma pequena alteração nessas colunas, mantendo os cards nas mesmas posições relativas, mas deixando as filas à direita:

Adicionamos uma etapa “backlog” do lado esquerdo e invertemos a posição das filas.

Olhando agora, será que evidenciamos que o problema pode ser o time de desenvolvimento estar produzindo num ritmo muito maior que a capacidade do sistema? Kanban não é sobre aproveitamento de recursos (não se trata de máquinas que, se não trabalharem 24/7, vão gerar prejuízo), mas sim sobre otimizar o fluxo.

Olhando no agrupamento de “desenvolvimento”, a coluna cheia agora está lá dentro. Fica difícil para o detrator do limite de WIP alegar que “não tem nada na fila dele”. Se tem coisa no “done”, tem coisa na etapa dele. O item só sai de “desenvolvimento” quando ele é puxado para a coluna “doing” de teste. Este é o sistema puxado. Será que essa visão não ajuda o time a promover colaboração e auto-organização? No exemplo, o time de desenvolvimento poderia ajudar nos testes para esvaziar a fila de “Desenvolvimento – Done“.

Tem tudo a ver com como nosso cérebro interpreta, às vezes subconscientemente, a disposição da informação.

Vale ressaltar que em times maduros, essa abstração talvez não faça diferença, pois as pessoas já sabem que os itens no quadro pertencem a todos do time, e o que realmente importa é entregar valor no fim.

Apenas para sua melhor visualização, caro leitor, vamos voltar ao quadro original, reordenando as colunas:

Como está o quadro do seu time? Quer testar essa pequena mudança e contar pra gente como foi?