Afinal, qual a diferença do Kanban do Lean para o Kanban do Agile?
No final de 1940, a Toyota encontrou um novo processo de engenharia que poderia ser empregado em seus negócios. Kanban é uma palavra japonesa e seu significado literal é “cartão” ou “sinalização”. É um método para a implantação de mudanças que não prescreve papéis ou práticas específicas. Em vez disso, oferece uma série de princípios que buscam melhorar o desempenho e reduzir desperdício, eliminando atividades que não agregam valor para a equipe.
A utilização de um sistema Kanban permite um controle detalhado de produção com informações sobre quando, quanto e o que produzir. O método Kanban foi inicialmente aplicado em empresas japonesas de fabricação em série e está estreitamente ligado ao conceito de “just in time”. Just in time (JIT) significa “no momento certo”. É um modelo japonês que procura eliminar estoques e agilizar a produção. Armazena-se o mínimo de matéria prima em estoque, apenas em quantidade que permita manter o processo produtivo no momento. O número de fornecedores também é reduzido para o modelo funcionar de forma eficiente.
O Kanban está relacionado com o conceito de Pull Systems (sistemas de produção puxados), a grande maioria das indústrias utilizavam o conceito de Push Systems (sistemas de produção empurrada). Um sistema de produção empurrada se caracteriza por iniciar a produção antes de ocorrer uma real demanda, ou seja, o processo recebe uma ordem de produção e executa, empurrando o resultado da operação atual para a operação seguinte. Um sistema de produção puxado se caracteriza por iniciar a produção quando um item é vendido, gerando demanda para a fabricação de outro, assim cada operação do processo é alimentada pela demanda da etapa anterior.
Mais recentemente, o Kanban eletrônico (e-Kanban) é utilizado em substituição ao método físico, evitando alguns problemas como a perda de cartões e proporcionando mais rapidez na atualização do quadro de tarefas. Além disso, atualmente, o Kanban é muitas vezes usado em conjunto com o Scrum ou em outras iniciativas ágeis, pois são duas metodologias usadas no desenvolvimento ágil de software.
Mais precisamente em setembro de 2006, o então diretor sênior de engenharia da Corbis (empresa fundada por Bill Gates), David J. Anderson, decidiu projetar um sistema Kanban que substituiria a então abordagem existente para atualização de aplicativos. Em janeiro de 2007, depois de uma série de lançamentos bem sucedidos, as melhorias de processos começaram a estagnar. Logo, Darren Davis, gerente de desenvolvimento, sugere a David J. Anderson que o fluxo de trabalho deveria ser visualizado e que um quadro branco, com alguns cartões colados, deveria ser pendurado na parede. A ideia havia surgido de um dos membros da equipe de Darren Davis e havia sido muito bem aceita pelo mesmo. Com o passar dos meses novas atualizações como, limite de quantidade de trabalho em andamento (WIP), foram implementadas. Os resultados preliminares do uso do Kanban na Corbis foi apresentado nas conferências, “Lean New Product Development” e “Agile 2007”. Desde então, o Kanban vem ganhando respeito na comunidade de desenvolvimento de software e mais empresas passaram a adotá-lo.
Dessa forma, o Kanban vem sendo reconhecido como uma forma de implementar métodos ágeis e gestão enxuta em empresas ao redor do mundo. Uma das vantagens é que o Kanban é um dos métodos de desenvolvimento de software menos prescritivo, se tornando adaptável a quase qualquer tipo de cultura. Ao contrário de outros métodos que forçam uma mudança desde o início, o Kanban busca a evolução, não a revolução.
Ele possui quatro princípios fundamentais, são eles:
- Comece com o que você faz agora;
- Concordar em buscar mudanças evolucionárias;
- Inicialmente, respeite os papéis, responsabilidades e cargos atuais;
- Incentivar atos de liderança em todos os níveis.
Os quatro princípios deixam claro que o método Kanban não é um processo apenas para se colocar em prática, é um método para impulsionar a melhoria, começando com o processo que você já tem. Os itens 1 e 3 dizem claramente para não se fazer qualquer alteração nem no processo, nem nos papéis, inicialmente. Os itens 2 e 4 falam sobre mentalidade, onde todos devem conseguir pequenos passos de melhoria permanente. O Kanban não é um destino, é uma direção e onde quer que você esteja, você sempre pode aplicar esses princípios. Adicionalmente, possui algumas práticas:
Visualizar o fluxo de trabalho (workflow)
Quando criamos um modelo visual do fluxo de trabalho da equipe, fica possível identificar o que realmente está sendo feito. O trabalho se torna visível, gerando uma serie de benefícios como, foco no “todo”, transparência e identificação de desperdícios. Todos podem enxergar o contexto do outro, levando instantaneamente o aumento da comunicação e colaboração. A visibilidade vai permitir que você perceba o impacto das mudanças.
Limitar a quantidade de trabalho em andamento (WIP)
A sigla WIP (Work in process) é muito usada quando falamos de Kanban e nada mais é do que o trabalho em andamento. Ao limitar o WIP, o ritmo da equipe se torna equilibrado, ela não se compromete com muito trabalho de uma só vez e reduz o tempo gasto em um item. Evitamos também problemas causados pela alternância de tarefas, reduzindo a necessidade de priorizar constantemente itens. Um ótimo exemplo de WIP pode ser encontrado no palácio imperial do centro de Tóquio, no Japão. Lá o Kanban é utilizado como uma forma de sinalizar a necessidade de puxar mais trabalho.
Gerenciar e medir o fluxo
Usando limites de trabalho em andamento você pode otimizar o seu sistema Kanban para melhorar o fluxo de trabalho da sua equipe, coletando métricas e até mesmo obtendo indicadores de problemas futuros. Dessa forma, fica possível otimizar o time to market, conhecido também, como lead-time. O Kanban promove a colaboração contínua e incentiva o aprendizado e a melhoria do seu trabalho. Porém, antes de melhorar é preciso saber onde. Você pode descobrir isso olhando e entendendo como o trabalho está fluindo, analisando as áreas problemáticas em que o fluxo está parado e indefinido, e em seguida implementando mudanças que favoreçam a melhoria. Torne a repetir esse ciclo para entender se realmente as mudanças estão tendo um impacto positivo ou não.
Tornar as políticas do processo explícitas
Há muitas maneiras de modificar um quadro Kanban para fazer políticas de processo explícitas. Uma delas, é redesenhar o quadro para especificar como os fluxos de trabalho devem ocorrer. Outra, é a utilização de limites de WIP para explicitar políticas sobre o quanto de trabalho em progresso podemos assumir. Não é possível melhorar algo que você não entende. Por isso, é preciso definir, divulgar e socializar o processo, assim todos terão uma ideia explícita de como as coisas funcionam e de como o trabalho realmente é feito.
Implementar loops de feedback
De acordo com a prática três, “gerenciar e medir o fluxo”, é necessário medir e otimizar o lead-time para que o processo se torne eficaz. Para saber isso, é necessário identificar o que os clientes pensam e quanto o produto contribui para atingir as suas necessidades. Há também a necessidade de loops de feedback dentro de um sistema Kanban para se certificar de entregar a funcionalidade esperada com a qualidade certa. Loops de feedback são também uma excelente maneira de minimizar riscos, dado que as decisões são validadas continuamente e os problemas de qualidade são exposto imediatamente.
Usar modelos para reconhecer oportunidades de melhoria
Se você não está melhorando continuamente, mas está cumprindo todos os outros requisitos do método Kanban, você está fazendo errado. É como utilizar uma metodologia ágil, mas não ser ágil. A prática de Kaizen é parte fundamental para usar o Kanban de forma eficaz. O Kanban sugere que modelos sejam usados para implementar mudanças contínuas, incrementais e evolutivas.
Assim, não há como não pensar o método Kanban dos projetos ágeis como uma aplicação do Kanban da Toyota, inclusive com o uso de outras filosofias como o Kaizen e do estabelecimento de indicadores como WIP, Lead Time, Cycle Time e até mesmo com balanceamento a partir do Yamazumi Chart. De qualquer forma, que traga bons frutos para a indústria de software assim como trouxe para a cadeia automotiva.
