Não Limitar o WIP (Work in Progress) é um erro

Não Limitar o WIP (Work in Progress) é um erro

A tarefa de implantar um limite de WIP (Work in Progress) para um time Kanban ou que está se transformando em ágil pode vir a ser um grande desafio. Em alguns momentos de minha carreira enfrentei forte resistência ao sugerir essa iniciativa. Entretanto, em outras oportunidades, obtive sucesso e alto engajamento da equipe em um curto espaço de tempo.

Nesse artigo pretendo compartilhar algumas lições aprendidas durante essas vivências e elencar pontos que fazem o ato de limitar o Work in Progress ser tão relevante para a eficácia do método Kanban. Somado a isso, no decorrer do texto serão apresentadas dinâmicas para tornar tangíveis os benefícios do limite de WIP, fundamentos matemáticos dessa abordagem e algumas técnicas que visam auxiliar o time a respeitar o WIP. Minha expectativa é poder colaborar com pessoas que estejam se empenhando na jornada de limitar WIP e eventualmente tenham desafios a superar.

O que é WIP (Work in Progress)

É sempre importante definir o conceito que estamos tratando. A simples tradução do termo para o português já apresenta uma boa definição do que é Work in Progress: Trabalho em progresso. O WIP, ou trabalho inacabado é tudo aquilo que está dentro de um sistema ou fluxo de produção que já iniciou a ser criado/desenvolvido e não está de fato pronto. Um exemplo é um lote carros em uma fábrica que faltam passar pelos testes mecânicos e elétricos.

Work in Progress - Trabalho em andamento WIP

No contexto da indústria é muito simples de identificar trabalho inacabado, como os produtos são físicos, rapidamente podem ser gerados grandes volumes em estoques. Todavia, na indústria do conhecimento, identificar estoques, gargalos e desperdícios não é tão simples pois os produtos em geral não são tangíveis. O método Kanban nos apresenta ótimas soluções para esse impasse que trataremos a seguir.

Por que Não Limitar o WIP (Work in Progress) é um erro

Particularmente, não sou afeito a essas afirmações prescritivas que ditam o que  é certo e errado. Também não sou adepto a procurar a bala de prata. O título desse post: “Não limitar o WIP é um erro” é,  na verdade, de autoria de David J. Anderson. A frase intitula uma seção de uma das suas primeiras obras: “Kanban: Mudanca Evolucionária de Sucesso Para Seu Negócio de Tecnologia” página 127.

No capítulo do referido livro, o pai do Kanban, relata experiências nas quais times ágeis da Yahoo optaram por iniciar a adoção do Kanban sem estabelecer limite de WIP. A justificativa para essa estratégia baseou-se no fato de que as equipes eram muito caóticas para lidar com o esforço que a adoção do  WIP iria introduzir. Seu plano era adotar o WIP em um segundo momento. O resultado foi que muitos times em um breve espaço de tempo abandonaram o Kanban sem visualizar melhorias consideráveis.

Por outro lado, ainda segundo David J. Anderson, times que impuseram limites de WIP desde o início tiveram um processo de melhoria e maturidade organizacional acelerado. Rapidamente os times passaram a entregar resultados de negócio superiores, com previsibilidade e softwares de alta qualidade.

Recentemente realizei a pergunta “Não limitar WIP é um erro?” para André Suman Pereira no Webinar do descomplicando agilidade e gostei muito da sua resposta. Recomendo fortemente seu blog. Ele abriu dizendo que, por definição, um sistema Kanban tem WIP limitado. E após um explicação dessa afirmação apresentou uma metáfora que adorei. “O limite do WIP ajuda o time a entender eu fluxo e melhorá-lo”… “o time passa a se comportar como se estivesse em um jogo de Xadrez, olhando para o quadro passa a decidir qual é o melhor movimento a realizar. Nesse cenário o WIP trata-se de um parâmetro que nos ajuda na tomada de decisão”.

Visualizando o fluxo de trabalho e o trabalho em progresso

A técnica de limitar o trabalho em progresso não é uma grande novidade. Na verdade é mais de uma das práticas de sucesso do Sistema Toyota de Produção ou Lean Manufactoring que foram adaptadas para o desenvolvimento de software.

Na indústria automobilística é muito fácil visualizar o que denominam no “chão de fábrica” de “trabalho inacabado”. Nesse cenário grandes quantidades de peças ou partes inacabadas de carros geram um estoque excessivo. Devido a seu volume, gargalos são facilmente identificadas e o grande desperdício é rapidamente evidenciado.

Por outro lado, na indústria do conhecimento é mais complexo identificar o trabalho inacabado e seus respectivos reflexos podem afetar na produtividade de um time ou de uma empresa como um todo.

Baseado nessa dificuldade o sistema Kanban foi mais uma vez beber na fonte do Lean Manufactoring e buscou de lá a gestão visual e o mapeamento de cadeia de valor  para criar o tão famoso Kanban Board. A partir desta criação é possível visualizar o fluxo de trabalho de um time, identificar gargalos, impedimentos e desperdícios.

Comprovação científica

A gestão visual nos ajuda e muito a identificar pontos de melhoria. Já tive experiências com times que a simples ação de criar um board com um mapeamento de fluxo de valor bem apurado e acompanhar visualmente o fluxo de trabalho gerou um grande número de insights para a melhoria contínua.

Mas como sair do mundo de hipóteses e suposições e partir para o empírico e para a ciência?

A tão aclamada lei de Little surge como um grande ponto de apoio científico para ajudar-nos nessa argumentação. Em 1961, John DC Little apresentou seu teorema em um artigo publicado no jornal acadêmico “Operations Research“. Em pouco tempo, sua lei ganhou notoriedade mundial devido à sua aplicação prática e importância teórica relacionada à Teoria das Filas.

Para o nosso contexto, o mais relevante da teoria diz respeito ao fato de comprovar que quanto maior a quantidade de trabalho em progresso em um sistema, maior será o Lead Time desse sistema. Saiba mais detalhes dessa relação no POD Cast da ContÁgil.

Abaixo, a expressão que representa a Lei de Litte:

Lead Time médio = WIP / Throughput

Comprovação prática

Esse conceito muitas vezes é contra intuitivo, prova disso é que frequentemente ouvimos pessoas falarem: “Eu sou extremamente produtivo quando faço muitas coisas ao mesmo tempo”.

Contudo, os estudos científicos sobre o tema são muito claros: “se acha que é bom nisso, na verdade você é pior do que a grande maioria”. Estudos da Universidade de Utah, liderados por David Sanbonmatsu indicam que pessoas que acreditam ser melhores ao executarem multitarefas na verdade possuem visões distorcidas sobre sua própria capacidade. As mesmas ao serem medidas mostram uma performance extremamente baixa.

Vamos às práticas:

Dinâmica Números Arábicos X Alfabeto X Números Romanos
(Muito grato ao Bruno Zanutto da PlataformaTec pela sugestão da dinâmica). 

Orientações da dinâmica

  1. Distribua folhas e canetas aso participantes;
  2. Solicite que em 30 segundos os participantes escrevam números arábicos sequenciais a partir do um. Exemplo: 1, 2, 3, 4…
  3. Em seguida, mais 30 segundos para escrever as letras do alfabeto em sequência. Exemplo: a, b, c, d…
  4. Então mais 30 segundos para escrever números romanos sequenciais. Exemplo: I, II, III, IV…
  5. Feito isto, informe que os participantes terão 1 minuto e  30 segundos para fazer o mesmo exercício, mas o primeiro número arábico, a primeira letra do alfabeto, o primeiro número romano, o primeiro número arábico, etc… Exemplo 1, A, I; 2, B, II;, etc.
  6. Concluída essa etapa, basta solicitar para que somem a quantidade total de itens escritos nos dois cenários. A expectativa indica que no segundo cenário a produtividade deve cair consideravelmente.

Dinâmica Múltiplos de 3 X Múltiplos de 4 X Letra de Música
(Muito grato ao Wesley Tiago Zapellini da PlataformaTec e ao Daniel Mello da Projectlab pela sugestão da dinâmica).

  1. Distribua folhas e canetas aos participantes;
  2. Solicite que em 30 segundos os participantes escrevam múltiplos de 3;
  3. Solicite que em 30 segundos os participantes escrevam múltiplos de 4;
  4. Solicite que em 30 segundos os participantes escrevam as palavras da letra de uma determinada música;
  5. Feito isto, informe que os participantes terão 1 minuto e  30 segundos para fazer o mesmo exercício da seguinte forma: Escreva um múltiplo de 3, escreva um múltiplo de 4, escreva uma palavra de uma música, escreva outro múltiplo de 3, escreva outro múltiplo de 4, escreva outra palavra de uma música e assim por diante.
  6. Concluída essa etapa, basta solicitar para que somem a quantidade total de itens escritos nos dois cenários. A expectativa indica que no segundo cenário a produtividade deve cair consideravelmente.

Comprovação Gráfica por que Não Limitar o WIP (Work in Progress) é um erro

A análise do Cumulative Flow Diagram é uma forma empírica de apresentar visualmente os achados da Lei de Little, baseada nos resultados do time. Basta construir o gráfico e mostrar para o time que nos momentos em que existe um maior número de trabalhos em progresso, o Lead Time é maior do que os momentos em que o time possui poucos trabalhos em progresso.

Eu gosto de evidenciar isso da seguinte forma? Primeiramente traço uma linha na vertical que se inicia na junção data a ser aferida com a primeira etapa do processo e finaliza na linha de trabalho concluído. Essa linha representa o WIP.

Cumulative Flow Diagram Lead Time VS WIP

Após isso traço uma linha na horizontal que se inicia na junção da data a ser aferida com a primeira etapa do processo e finaliza na linha de trabalho concluído. A linha horizontal representa o Lead Time.

Apresento essa comprovação Gráfica baseada em dados do time em questão. Geralmente todos concordam, contra fatos dificilmente há argumentos plausíveis.

 

Formas de ajudar o time a respeitar o WIP

Existem várias abordagens para ajudar os times a respeitar o WIP, quando estamos atuando com Boards virtuais a maioria dos aplicativos possuem recursos visuais ou regras de impedimentos de movimentação de itens baseados em limite de WIP.

Entretanto, quando trabalhamos com boards físicos não possuímos recursos para impedir que uma tarefa seja puxada para uma coluna com o limite do WIP já atingido. Eu acredito muito na força do Hábito,  dessa forma entendo que devemos facilitar para que o time adquira esse hábito. Uma abordagem que gosto muito está  descrita no posto do Bruno Zanutto da PlataformaTec: “Ajudando o Time a Respeitar Limite de WIP com um Truque Simples

Tenho utilizado uma outra abordagem em dois times nos quais atuo e isso tem gerado um resultado bem expressivo. Eu criei uma imagem de trabalho em progresso e colei meu avatar em cima. Sempre que alguma etapa do fluxo de valor tem seu WIP ‘estourado’ eu vou lá e colo a imagem como meu avatar. É incrível como o efeito psicológico gerado por essa pequena ação pode gerar. O simples ato de colar essa imagem já gerou represálias, questionamentos sobre o a motivação para o WIP, questionamentos sobre a eficácia do WIP, questionamentos sobre novas formas de trabalhar para respeitar o WIP,  mudança de WIP entre outras. E após essas manifestações sempre existiu um momento de reflexão e aprendizado coletivo, bingo!

Essa abordagem tem sido muito proveitosa para mim e inclusive foi um dos motivadores para escrever esse Post. Seguem abaixo algumas imagens que uso para evidenciar limite de WIP não respeitado.

WIP - Ajudando o time a respeitar o WIP

O mantra “pare de começar, comece a terminar” é um dos grandes lemas para os times que escolhem a jornada do Kanban para entregar produtos cada vez melhores.  Porém eventualmente surgem perguntas sobre quais ferramentas podemos utilizar para rapidamente colocar esse mantra em prática? Sem dúvida uma das ferramentas mais poderosas do Kanban é Limitar o WIP. Dessa forma estabelecemos um limite de trabalho em progresso no nosso sistema e conseguimos reduzir o Lead Time, ser mais produtivo e mais feliz.

Então, bora limitar o WIP pessoal?

English EN Portuguese PT Spanish ES
 

2 comentários em “Não Limitar o WIP (Work in Progress) é um erro

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *