Concrete Logo
Hamburger button

Limitando o WIP

  • Blog
  • 2 de Julho de 2018

Antes de a 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 post, 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 (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 2 itens completos e 2 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 de 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 inspeccionar 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 questão? Use o campo abaixo. Até a próxima! o/

A agilidade está presente na Concrete desde o início, o que levou a empresa, hoje parte da Accenture Technology, a se tornar referência na transformação digital dos clientes. Criamos produtos digitais inovadores justamente por sermos uma consultoria de produtos, não apenas de tecnologia. No capítulo de Agilidade, a missão é capacitar os agilistas a maximizarem a entrega de valor, de maneira iterativa e incremental. Quer trabalhar com os melhores? Acesse: concrete.com.br/vagas