MISSÃO: KANBAN - Parte III- Limitar o Work in Progress

Dando sequência à série de posts Missão: Kanban (clique aqui para ler o primeiro post da série), no post de hoje falaremos sobre o quarto encontro com o time de desenvolvimento, que teve como objetivo principal limitar o work in progress.

Recordando que a série Missão: Kanban está sendo compartilhada em cinco posts com publicação semanal e que este é o quarto post da série (a agenda de publicações completa com o link dos posts anteriores está disponibilizada no final deste post).

TENHA UMA BOA LEITURA!

§ Tarefas

• Compreender as diferenças entre um sistema empurrado e um sistema puxado;
• Limitar o Work in Progress do fluxo de trabalho.

§ Resultado esperado

• Definição de WiP para entrada no fluxo downstream, tarefas e filas;
• WiP divulgado no board virtual.

Após três encontros de construção e entendimento de um fluxo de trabalho puxado, chegou o momento de tomarmos uma das decisões mais importantes para introdução do Sistema Kanban: Limitar o trabalho em progresso (que será nominado como WiP — Work in Progress). Mas porque limitar o WiP é tão importante?

À primeira vista, é natural que propor a limitação do WiP de um time de desenvolvimento soe estranho, afinal, estávamos migrando nosso método de trabalho para termos um ganho no processo, logo, não parece fazer sentido estabelecer um limite de itens que iremos trabalhar. Entretanto, limitar a quantidade de tarefas por etapa tem como consequência a delimitação de demandas, além de impedir o acúmulo de estoque (evitando perdas para a organização), mantém o processo estável e garante maior previsibilidade quanto às entregas. Ou seja, traz mais foco ao time de desenvolvimento, além de institucionalizar um sistema puxado.

Se o time não estabelece limites para o WiP, é muito provável que acabe operando um sistema empurrado, o que foge do nosso objetivo. Desse modo, debatemos as características de cada sistema (empurrado e puxado) para que o time identificasse as diferenças e enxergasse valor na adoção do sistema puxado e o compreendesse como parte fundamental do sistema Kanban.

COMPREENDER AS DIFERENÇAS ENTRE UM SISTEMA EMPURRADO E UM SISTEMA PUXADO

Sistema Empurrado

Um sistema empurrado é aquele em que a produção é baseada na demanda, sem respeito à capacidade do sistema.

Podemos dizer que tem o objetivo de produzir o máximo possível e entregar em grandes lotes.

Sistema Puxado

Um sistema puxado é aquele em que os participantes “puxam” o trabalho quando há capacidade disponível para executá-lo. Possibilitando um ritmo sustentável e equilíbrio entre capacidade e demanda.

Antes de começar é importante lembrar que não há fórmula mágica para calcular a limitação do WiP. Inclusive, é possível definir um limite inicial de WiP de maneira empírica e observar durante o tempo se ele funciona bem. Caso o limite inicial não esteja funcionando bem no fluxo de trabalho, deve-se ajustá-lo para cima ou para baixo. É necessário ter em mente que, quando falamos de sistema Kanban, estamos falando de começar com o que se tem e buscar evolução contínua.

Também é importante que todo o time de desenvolvimento e o PO estejam presentes neste momento de limitação de WiP para construção de um consenso e, com isso, manter a disciplina do limite do WiP e evitar que a prática seja abandonada.

LIMITAR O WORK IN PROGRESS DO FLUXO DE TRABALHO

Para a tarefa de limitação de WiP, utilizamos a ferramenta MIRO (https://miro.com/), onde reproduzimos o board virtual do time, com post-its nas cores azul e rosa, representando, respectivamente, as colunas “doing” e “done” em cada etapa, conforme imagem abaixo (como o time não está realizando automação de testes no momento, esta etapa foi suprimida da reprodução e da atividade):

Desse modo, foi definido que as etapas de Análise, Prototipação e RDM não teriam limitação de Wip, bem como o “Done” da etapa de homologação. Já as etapas de Refinamento, Ready, Desenvolvimento e Testes teriam limite de WiP, bem como o “Doing” de homologação.

Após definirmos quais etapas teriam limitação de WiP, dividimos a tarefa em 3 passos:

§ Limitar a entrada

§ Limitar as tarefas

§ Limitar as filas

Limitar a Entrada

Para definir o tamanho da fila de entrada, primeiro tivemos que definir a periodicidade de reabastecimento do fluxo. Como o time decidiu seguir com a periodicidade quinzenal (tamanho das sprints do time quando atuava com Scrum) foi acordado que o WiP seria a métrica de Capacity do time (medição similar ao Throughput).

A fila de entrada está representada no fluxo de trabalho através da etapa Ready.

Limitar as Tarefas

Para limitarmos as tarefas no fluxo de downstream, optamos por utilizar uma fórmula de quantidade de itens por pessoa, conforme a complexidade de cada etapa. Neste caso, foi definido que os desenvolvedores trabalhariam em um único work item cada na etapa de desenvolvimento e os testadores poderiam atuar em até dois work itens simultâneos, assim como o PO, que poderia homologar até dois work itens.

Em nosso fluxo de trabalho as tarefas estão representadas através da coluna “doing” das etapas de Desenvolvimento, Testes e Homologação.

Para as tarefas da etapa de Refinamento usamos um método um pouco diferente. Primeiro definimos a fila (a coluna “Done”) da referida etapa, responsável por abastecer o downstream, e aplicamos uma regra em que o WiP da tarefa deveria ser equivalente a 50% do WiP da fila de Refinamento. Vale lembrar novamente que não precisamos acertar de primeira, logo, não não foque na busca do WiP ideal, mas sim na experimentação.

Limitar as Filas

Quando um trabalho é finalizado e está à espera para ser puxado para o próximo estágio no seu fluxo de trabalho, diz-se que ele está “enfileirado”. Mas qual deve ser o tamanho dessa fila? Sem dúvidas o tamanho da fila deve ser o menor possível, entretanto, ela ainda precisa ser grande o suficiente para garantir a absorção das variabilidades do fluxo de trabalho e evitar que o sistema Kanban sofra do comportamento “pare-avance”.

A necessidade de absorver as variabilidades nos fez utilizar um método diferente do aplicado na limitação das tarefas. No nosso fluxo de trabalho as filas estão representadas através da coluna “done” das etapas de Refinamento, Desenvolvimento, Testes e Homologação. As limitações das filas foram definidas conforme abaixo:

• Fila da etapa de Desenvolvimento — Deve comportar o WiP das tarefas de Desenvolvimento + 1 work item;
• Fila da etapa de Testes — Deve comportar o WiP das tarefas de Testes + o WiP das tarefas de Homologação;
• Fila da etapa de Refinamento — Deve comportar o WiP da etapa Ready + 50% do mesmo Wip.

IMPORTANTE(!): Foi acordado entre o time que o limitador de WiP não terá efeito sobre os work itens da classe de serviço Expedite, devido à urgência que os itens devem ser tratados. Segue abaixo o resultado do trabalho do time:

Limitar o WiP foi um processo tão trabalhoso quanto gratificante, entretanto eu gostaria de me atrever a dar uma pequena sugestão: Não desperdice tempo tentando determinar um limite de WiP perfeito. Escolha um número próximo, dê apoio para que o time evolua o processo e ajuste empiricamente quando necessário. Sabe aquele ditado que diz que “as melancias se ajustam com o andar da carruagem”? É basicamente isso. Com o passar do tempo, com a coleta e análise das métricas o WiP ficará mais claro, bem como a necessidade de ajuste ou não.

Para efeito de comparação, o time que atua com produtos de investimentos optou por um método mais simples: replicou o número do Capacity (utilizado para limitar a entrada) também para limitar tarefas e filas. Como dito anteriormente, não há fórmula mágica para calcular a limitação do WiP, então foque no simples e utilize as informações que você já possui.

APRENDIZADOS ADQUIRIDOS NO ENCONTRO

§ Delimitar a quantidade de tarefas por etapa tem como consequência a delimitação de demandas também, e isso traz foco ao time;

§ Estabelecer limites vai impedir o acúmulo de estoque e auxiliar a manter o Lead Time estável;

§ Com menos trabalho no sistema, o gerenciamento fica mais simples;

§ Se o time não estabelece limites para o WiP, é muito provável que acabe operando um sistema empurrado;

§ Limites de WIP devem ser estabelecidos para um número médio de itens por pessoa;

§ Limites de fila devem ser mantidos pequenos, mas grandes o bastante para absorver a variação natural do tamanho dos itens, a duração das tarefas e garantir o melhor desempenho na manutenção do fluxo do sistema;

§ Todos os limites de WIP podem ser ajustados empiricamente;

§ Não se deve desperdiçar tempo tentando determinar um limite de WIP perfeito.

Muito obrigado a todos que chegaram até o fim deste post, e até a próxima semana, quando falaremos sobre o 5º encontro com o time e os próximos passos da aplicação da melhoria contínua.

AGENDA DE POSTAGENS

• 17/06/2020 — Seção 1 (Idealizando a Missão: Kanban) — Leia aqui!;
• 24/06/2020 — Encontro 1 (Mapear o Fluxo de Trabalho) — Leia aqui!;
• 01/07/2020 — Encontro 2 (Estabelecer as Classes de Serviço) e 3 (Tornar as Políticas Explícitas) — Leia aqui!;
• 08/07/2020 — Encontro 4 (Limitar o Work in Progress); e
• 15/07/2020 — Encontro 5 (Gerenciar o Fluxo de Trabalho) e Seção 3 (Considerações Finais e Próximos Passos).