Por que limitar o WIP (Work In Progress)?

POR QUE LIMITAR WIP?

A limitação de WIP é um princípio do Método Kanban cuja efetividade de aplicação é subordinada ao cumprimento anterior dos outros princípios. O método predica que devemos, a partir do cenário atual de um processo, visualizar e gerenciar o fluxo, tornando explícitas as políticas de gestão, e abraçando mudanças de forma iterativa e evolucionária. Isso significa que a recomendação é de que, a princípio, devemos evidenciar as disfunções, e não lutar contra elas de imediato.

Quando identificamos um acúmulo, crônico ou pontual, de atividades em um ponto específico do fluxo, dizemos que há um gargalo no processo. Isso significa, basicamente, que volume (e frequência) de entrada de demanda é maior do que o de saída, e, portanto, este é o ponto que dita todo o ritmo de entrega. O trabalho de solução destes gargalos é um dos maiores desafios ao se trabalhar com o método Kanban, pois exige pensamento sistêmico da equipe toda para tomar decisões que beneficiem a todos, e a consciência de que a eliminação de um gargalo tende a favorecer o nascimento de outro.

Logo, a visualização fidedigna, rápida e clara do fluxo é imprescindível para que se possa executar o trabalho evolucionário de mudança processual.

Isto feito, pode-se dar o segundo passo de evolução do board: a limitação de trabalho em progresso. Quanto mais trabalho a ser realizado ao mesmo tempo, mais cada um demorará para ser entregue para o cliente. Neste sentido, a ferramenta de limitação de WIP tem como principal objetivo restringir o fluxo de entrega à capacidade da equipe e do processo, estabelecendo um número máximo (e mínimo, dependendo do contexto) de itens que podem transitar pelo fluxo, pela coluna, ou pela fase. Isto facilita a visualização dos pontos de dor, visando otimização a médio prazo, e “constrangimento” a curto prazo — time sente, de fato, os pontos de dor do processo, por não poder progredir na atividades. Limitando o número de atividades, fazemos menos, pois não podemos continuar puxando novos itens para o fluxo quando os outros estiverem bloqueados, mas entregamos mais valor na mão do usuário, pois paramos de começar, e começamos a terminar.

COMO?

Primeiro, é importante tentar estabelecer uma correlação entre capacidade e número de pessoas da equipe. Por meio de experimentação, temos que chegar a um número de itens que não seja baixo demais a ponto de empacar o processo, nem tão alto a ponto de desvirtuar o experimento. Por mais que se possa pesquisar e desenvolver fórmulas que sugiram limites de WIP iniciais, o melhor método para introduzir este conceito é discuti-lo com a equipe em frente ao board, refletir sobre os prós e contras de cada abordagem, e iterar conforme necessário. Por fim, não existe um momento específico em que se deva realizar aumentos ou diminuições, mas é fundamental que respeitemos os limites durante algum tempo para colher resultados efetivos. Se forem feitas muitas alterações em sequência, sem as devidas ponderações, é possível que a ferramenta se banalize, e passe a ser simplesmente um informe de quantidade de atividades, não um mecanismo de restrição.

E AQUELE TAL DE SLACK TIME?

Considerando que pode haver um momento em que todos os itens estão bloqueados, não parece fazer sentido, num primeiro momento, que se respeite fielmente os limites de WIP, pois isso inevitavelmente significaria ficar parado. E encarar este fenômeno como algo que deve ser reforçado é contraintuitivo, e exige certa desconstrução cultural, uma vez que sempre aprendemos que o sistema eficaz é aquele que está sempre com 100% de esforço de operação (o que, na verdade, é um sistema em stress).

Ora, considerando que queremos promover o pensamento sistêmico do time, e incentivar a colaboração, não é correto que um membro da equipe continue puxando demandas para não ficar parado, enquanto o gargalo segue aumentando. O método kanban pretende inserir esta folga no sistema, pois este tempo “ocioso” cria espaço para melhorarmos nossa maneira de trabalhar. Ele permite que a equipe faça cursos, brainstorming, otimizações, atualizações de documentação, ou qualquer outra atividade que seja importante, de valor, e habilite mais efetividade para o nosso trabalho.

E AGORA?

Assim, vemos que não é necessário um grande preparo pra operacionalizar a inclusão de limites de WIP dentro de um fluxo kanban. Basta que se mapeie minimamente as etapas lógicas do processo, e, tendo em vista a capacidade da equipe, se estabeleça um número inicial que faça sentido para não atravancar nem liberar demais o fluxo, alterando-o de acordo com as melhorias almejadas. Queremos evidenciar os pontos de dor, endereçá-los conforme necessário, e principalmente, parar de começar, e começar a terminar.