Pressione enter para ver os resultados ou esc para cancelar.

Desvendando o kanban: Sistema kanban ou Método Kanban?

O Sistema kanban, na sua forma mais básica é um sistema puxado e limitado, que permite a visualização do fluxo de trabalho, buscando a geração de valor por pessoas. Generalizando, é isso que o mercado entende por modelo ou sistema kanban. E assim foi definido originalmente, quando surgiu na indústria de produção como um “cartão visual” – traduzindo o termo.

Já o Método Kanban (idealizado por David J. Andersen), oferece uma abordagem evolutiva e incremental para mudança de processos e sistemas nas organizações. Na prática, o Método Kanban consiste em executar um sistema kanban focado em kaizen (promover pequenas alterações no processo, causando menor resistência à mudança) e gestão.

Você pode executar um Sistema kanban sem, efetivamente, utilizar o Método Kanban. Justamente daí surge a dúvida: k ou K? Espero que com as definições acima, você não tenha mais esta dúvida.

Falando um pouco mais sobre as bases do Método Kanban:

Princípios:

Propriedades:

Os princípios do Método Kanban são restrições que devem ser aceitas para qualquer iniciativa de implementação do método e como se pode observar, não são restrições de grande impacto, sendo fácil respeitá-las.

Ainda é possível fazer uma distinção, considerando as implementações menos profundas (que correspondem à maioria das implementações realizadas no mercado) e limitadas às duas primeiras propriedades, como Kanban básico. Enquanto isso, as demais propriedades podem nos ajudar a melhorar os processos, possibilitando uma aplicação mais avançada do método, ou seja, o Kanban avançado.

Mergulhando mais fundo no assunto, no sentido de uma aplicação avançada de Kanban, devemos considerar os conceitos de transição, kaizen, pensamento sistêmico, métricas, variabilidade, políticas explícitas e perfis de risco.

Pergunte-se: por que adotar o Kanban?

O processo de mudança acarreta uma perda de capacidade em função da curva de aprendizado. Normalmente se houve a metáfora da gestação: “9 mulheres não geram um filho em 1 mês”. Isso poderia ser verdade em uma linha de produção tradicional, mas não em desenvolvimento de software. Dobrar o tamanho de uma equipe não vai dobrar a sua capacidade, pelo menos não instantâneamente. Entenda por “capacidade” não apenas o resultado produtivo da equipe, mas também a comunicação, a habilidade técnica e estrutural, dentre outros.

Desta forma, grandes mudanças ocasionam maior perda de capacidade, o que diga-se de passagem, não é bom. No Lean, este tipo de mudança é conhecido como Kaikaku, uma revolução com quebras de paradigmas. O gráfico abaixo representa este tipo de transição:

Gráfico Kaikaku
Gráfico Kaikaku

Agora imagine que o gráfico acima representa um ano de capacidade de uma empresa, até a retomada da capacidade anterior perde-se tempo significativo não é mesmo?! Outra observação importante: pode ocorrer abandono às mudanças caso não haja um comprometimento efetivo na organização.

Com o Kanban, o objetivo é tornar a curva de aprendizado menor, retomando a capacidade anterior mais rapidamente e com menor resistência às mudanças. Agora veja o gráfico à seguir:

Evolução com o método Kaizen
Evolução com o método Kaizen

Esta é a cultura Kaizen, mais evolutiva e gradual do que revolucionária. Perceba que a retomada da capacidade anterior ocorre de forma muito mais rápida, podendo ainda, atingir capacidade maior à anterior logo em seguida.

Primeiro Kaizen

Durante uma implantação de Kanban, o primeiro kaizen serve para visualizar o processo e, a partir desta visualização, buscar disfunções no método como por exemplo o WIP alto, a falta de comunicação entre equipes de diferentes etapas do processo, os gargalos, bem como demandas de falhas (esta última, um fator muito importante).

Outra disfunção que pode ser observada no estágio do primeiro Kaizen é a alta variabilidade no throughout, uma das principais métricas do Kanban. Quando isso ocorre, o processo fica imprevisível, não sendo possível, por exemplo, prever as entregas.

Gráfico de throughput - ítens que foram entregues na semana
Gráfico de throughput – ítens que foram entregues na semana

De acordo com a prática do pensamento sistêmico, inicialmente não se deve alterar o processo, apenas visualizá-lo, observando o propósito do sistema. Outros padrões que podem ser observados através de pensamento sistêmico:

  • Fábrica de Bugs: demanda de falhas altas;
  • Software Inútil: funcionalidades não utilizadas;
  • Empresa de RH: pessoas insatisfeitas com o processo, causando alta rotatividade de colaboradores;
  • Entrega de Valor: entender o que agrega maior valor para os stakeholders e priorizar as demandas relacionadas.

Assim, com o Kanban implantado no processo atual, o mesmo será visualizado de forma que os problemas ficarão exposto e visíveis a todos. Em sistemas complexos, como um processo de desenvolvimento de software, muitas vezes só é possível deduzir o comportamento do sistema através dos resultados ou do output do sistema. Razão pelo qual, por exemplo, no Scrum as cerimônias de review e retrospect são realizadas após os Sprints, para se ter conhecimento dos resultados e com base nos mesmos buscar a melhoria contínua.

Dito isso, o Kanban surge com o intúito de promover mudanças de um cenário não desejado, como fábrica de bugs, produção de software inútil ou, uma empresa de RH, para um cenário de maior entrega de valor. Porém, mudanças são difíceis, principalmente em função do engajamento das pessoas mantendo o processo como algo habitual. Então é interessante que as mudanças do processo estimulem o engajamento das pessoas promovendo mudanças reais.

Políticas Explícitas

Outra propriedade do Kanban, menos praticada mas não menos importante, é tornar as políticas explícitas. Elas ditarão o comportamento da equipe e após o primeiro Kaizen (quando o processo atual já foi observado e as políticas foram explicitadas), em conjunto, pode-se fazer criticas e propor mudanças, como por exemplo: limitar o WIP, a política de deploys, a agenda de cerimônias e o padrão de comunicação entre os times, dentre outras. No entanto, as mudanças propostas deverão ainda levar em conta a cultura Kaizen, ou seja, uma menor curva de perda capacidade!

Segundo Kaizen – Limitar o WIP

Muitas vezes, quando não limitamos o WIP observamos que o processo acaba por ter uma variabilidade alta no throughput e na vazão das demandas, o que torna o sistema imprevisível. A partir do momento que criamos a política de limitar o WIP, o processo passa a ter menor variabilidade e sendo mais previsível. Claro, isso não ocorre instantâneamente, como podemos ver nos gráficos a seguir.

Gráfico WIP - work in progress
Gráfico WIP – work in progress
Gráfico WIP com novas políticas respeitando os limites
Gráfico WIP com novas políticas respeitando os limites
Gráfico WIP com sistema previsível e estável
Gráfico WIP com sistema previsível e estável
Gráfico do throughput com WIP limitado: menos variabilidade
Gráfico do throughput com WIP limitado: menos variabilidade

Na prática, o WIP baixo tem quase o mesmo efeito do time box e do Scrum, mas com menor resistência emocional das pessoas envolvidas no processo. Pode-se observar muito mais resistência em uma mudança que afete as etapas do processo, do que simplesmente reduzir a carga nestas etapas. E por que o WIP limitado e baixo diminui a variabilidade das entregas? Isso pode ser explicado pela Lei de Little sobre Teoria das Filas, onde temos:

É importante considerar estas três variáveis: vazão, tempo de entrega e quantidade de trabalho em progresso. Temos controle sobre a quantidade de trabalho em progresso e não temos controle sobre o tempo de entrega das demandas, que pode ser observado mas não controlado, dependendo da capacidade da equipe.

Relacionando WIP e Leadtime quando temos WIP baixo, consequentemente temos um Leadtime menor e da mesma forma, Leadtime menor e Throughput maior. Isso é a base de um sistema kanban e é matemático. Desta forma, no Kanban nós não temos, ou melhor ainda, não precisamos de estimativas. Ao invés disso, podemos predizer quando uma demanda será entregue e isso, com base nas métricas acima. Em um sistema complexo é inútil tentar prever o comportamento do sistema, já no Kanban, a previsibilidade é obtida através do comportamento observado, neste caso, o Leadtime.

Nos exemplos e gráfico mostrados até aqui, observa-se que a partir do momento que o WIP foi limitado a variabilidade diminui, o Leadtime diminui e estabilizou, como mostra o próximo gráfico:

Gráfico sobre como usar o lead time
Gráfico sobre como usar o lead time

Normalmente a raiz desta melhora está relacionada ao fato que a equipe passa a colaborar mais entre si e não que as pessoas estejam trabalhando mais rápido. E após a estabilização do Leadtime, o tempo que uma demanda leva para percorrer todas as etapas do processo é conhecido. Assim não precisamos estimar, basta conhecer o Leadtime médio.

Além da falta de limite ou de um limite alto no WIP, podemos citar também como outros fatores que causam variabilidade do Leadtime (impedimentos), o tipo e complexidade das demandas, ou ainda, troca de prioridade entre elas, problemas de comunicação entre a equipe e outros fatores mais. Uma abordagem que pode ser utilizada para tratar a variabilidade em função do tipo/complexidade da demanda, é classificá-la por exemplo, em pequena, média ou grande. Mas isso pode gerar uma complexidade extra e na maioria das vezes, não se faz necessário.

De tudo o que foi dito até aqui, Throughput e Leadtime são as métricas mais básicas do Kanban. É possível também avaliar o seu processo analisando métricas como demandas de falhas, de valor ou ainda, de melhorias. Assim, a idéia básica do Kanban é equilibrar demanda e capacidade. É muito mais fácil controlar a entrada de demandas para a equipe do que a sua capacidade, e essa demanda de trabalho pode ser controlada de diversas formas, entre elas, posicionamento de mercado, gestão de risco ou redução do número de demandas de falhas.

Por fim, pensando no modelo econômico Lean, que podemos resumir em duas palavras: custo e valor, vemos que o Kanban pode nos ajudar a reduzir custos e aumentar a entrega de valor. Com as duas últimas imagens fica fácil perceber que a redução dos custos, mesmo quando pequena, pode proporcionar um grande aumento na geração de valor.

Imagem 1: de redução de custo e aumento de valor
Imagem 1: de redução de custo e aumento de valor
Imagem 2: de redução de custo e aumento de valor
Imagem 2: de redução de custo e aumento de valor
Artigo elaborado com base da Palestra de Rodrigo Yoshiama realizada no evento Agile Brazil 2012 .

***
📣
Estamos contratando pessoas que desenvolvam software!
Mais informações sobre a vaga.
***