Antes da Scrum.org lançar seu Guia de Kanban para times Scrum (abril, 2018), muitas pessoas já uniam as regras e técnicas do Scrum e do Kanban para otimizar o desenvolvimento de um produto. Neste artigo, vou compartilhar o resultado do uso dos dois frameworks em um time. Vamos lá?

Um fato

Quem trabalha com desenvolvimento ágil deve estar mais do que acostumado a ver uma lista de tarefas e ideias para um produto e trabalhar no que é mais prioritário dessa lista, o primeiro item sendo o mais detalhado e pronto para ser feito e entregue. Por mais clara que seja a prioridade, é comum que membros do time de desenvolvimento comecem a trabalhar fora de ordem ou se comprometam a fazer duas coisas ao mesmo tempo, e no final das contas deixam algo pelo meio do caminho.

Entendendo o problema

Ao entrar num projeto novo ou em andamento, é importante perceber a interação entre as pessoas e com o trabalho.

Logo na primeira sprint foi possível perceber a forma com que cada pessoa tratava as prioridades e um fato recorrente: a sprint começava, cada um pegava uma coisa e criava uma fila enorme no final da sprint para o teste.

Consequência? O time nunca atingia seu objetivo e levava parte da sprint resolvendo pendências da anterior, para só no meio começar coisas novas.

Sistema puxado vs Sistema empurrado

O sistema empurrado movimenta grandes lotes de produto em uma direção independente da demanda. Esse tipo de sistema pode criar mais desperdício e gargalos. Em contrapartida, o sistema puxado depende da demanda. Se existe um espaço vago de um produto ou a possibilidade de realizar um novo trabalho, esse pequeno lote é trabalhado ou reposto.

O time fazia uma grande quantidade de trabalho e o acumulava em cada etapa, empurrando sempre para a próxima um lote grande de coisas a se fazer. Porém, conforme o fluxo se aproxima do final do sistema, mais se afunila a saída.

Começando a resolver – Visualizar o trabalho

É possível que em alguns momentos o time esteja tão imerso em desenvolver ou no próprio trabalho, que não olha para o todo. Para iniciar uma mudança, foi necessário mostrar o cenário atual e perguntar: como vocês vêem esses cenários?

Antes de tudo:

Qual a forma certa de ler o quadro?

Para essa pergunta, absolutamente 100% do time respondeu da esquerda para a direita. E isso está, de certa forma, errado.

O quadro deve ser lido da direita para esquerda, apesar de não ser uma forma convencional, dada que nossa escrita e leitura é feita da forma que o time respondeu. Mas é mais importante terminar um trabalho antes de começar outro.

Exemplo: durante uma Daily Scrum, um membro do time diz estar disponível para fazer algo novo. Há uma tarefa para validação e outra nova para começar. Vale mais começar algo novo e gerar mais um item para espera em breve ou gerar valor com algo que já está perto de entregar? Ao ensinar a forma de ler o quadro, os membros do time de desenvolvimento começam a se questionar e buscam fazer o que gera mais valor.

Cenários de sprint

Para o primeiro momento, pedi para que cada membro do time escolhesse uma dupla para conversar sobre o que aconteceria em seguida.

Com um quadro com o mesmo fluxo do time desenhado em uma mesa, peguei alguns posts its simulando as histórias e pedi para que olhassem e discutissem em dupla. Depois, mudei a posição e disse que aquele cenário estava no segundo dia da sprint. Seguimos nisso até o último dia da sprint. Os cenários ficaram da seguinte forma:

Primeiro dia

Segundo dia

Quarto dia

Sétimo dia

Último dia

Análise do time

• Coisas não planejadas entravam na Sprint, mas o que já estava não era negociado;
• Time preferia começar coisas novas ao invés de entregar algo;
• Cada desenvolvedor pegava um item para trabalhar;
• Trabalho ficava parado no final;
• O time nunca atingia o objetivo;
• Apesar de ser confortável a forma de trabalhar, o cliente não estava satisfeito.

A cilada de todos estarem ocupados

Quando todos do time estão sempre ocupados, trabalhando em tudo ao mesmo tempo, a entrega deixa de acontecer ou simplesmente não acontece. Para trazer esse problema para o time, fizemos uma dinâmica como a do vídeo “The resource utilization trap”.

WIP

Uma das práticas do Método Kanban é limitar o WIP (work in progress/trabalho em progresso). Com ele, o sistema antes empurrado é mudado para um sistema puxado. Não é possível começar algo antes que outra coisa acabe. O WIP permite evitar o desperdício. Por exemplo: em vez de ter cinco itens pela metade e nenhum completo, ter dois itens completos e dois em andamento. Além disso, ajuda a visualizar os gargalos de um fluxo.

Com essa ideia de terminar o trabalho, explicamos e definimos em consenso um WIP para o trabalho antes de começar coisas novas. Os limites ficaram da seguinte forma:

As colunas de desenvolvimento e Code Review, juntas, têm um WIP 4, e a coluna de Homologação tem WIP 1.

Resultados

• Tarefas pequenas que antes levavam muitos dias para ficarem prontas, agora levam, em média, dois dias;
• Houve um aumento de pair programming;
• Os membros do time começaram a se preocupar mais com homologação e testes;
• O quadro, antes ignorado, se tornou um artefato importante para inspecionar na daily e planejar o dia;
• O foco aumentou;
• O time tem mais momentos para aprender algo novo.

Coisas Inesperadas

• O time propôs testar a remoção da coluna de Code Review e, logo em seguida, percebeu que ainda precisava dessa visualização;
• Partiu do time a mudança no limite do WIP.

Conclusão

As práticas do método Kanban se complementam com os elementos e regras do Scrum. Quando combinados e respeitados, geram um grande valor para as equipes e produtos. Ainda tem alguma dúvida? Use o campo abaixo.

Até a próxima!

***

Este artigo foi publicado originalmente em: https://www.concrete.com.br/2018/07/02/limitando-o-wip/