O método Kanban foi concebido como um caminho alternativo à agilidade organizacional. Ao invés de grandes mudanças, o Kanban propõe uma abordagem evolucionária, onde pequenas melhorias são integradas na prestação de um serviço ou desenvolvimento de um produto.
Nascido dentro do Sistema Toyota de Produção (TPS), o kanban (com k minúsculo) era um cartão utilizado para sinalizar conclusão de etapas do processo e tornar o fluxo puxado. Mais tarde, David J. Anderson criou o método Kanban (com K maiúsculo) e popularizou o seu uso no desenvolvimento de produtos e serviços. Neste guia detalharemos o funcionamento deste segundo. ;)
- Entendendo um sistema Kanban
- Sistema empurrado
- Sistema puxado
- Os princípios básicos do método Kanban
- As 6 práticas gerais de um sistema Kanban
- Quando usar o método Kanban?
- Vantagens sobre o Scrum
- Como implementar um sistema Kanban
- Elementos de um sistema Kanban
- Métricas de um sistema Kanban
- As limitações do Kanban
- Método Kanban & Autogestão (O2)
- E tem muito mais que ainda não está aqui
Entendendo um sistema Kanban
Um sistema Kanban é composto por um fluxo de valor, onde unidades de trabalho trafegam da esquerda para a direita. Cada etapa do processo adiciona mais valor ao item, sendo que quando ele chega ao final do processo, ele está “concluído”. Esse fluxo de valor pode ser o desenvolvimento de um software, a prestação de um serviço (como atendimento ao cliente) ou até a criação de um produto físico.
Vamos supor que fazemos parte de um time de desenvolvimento de um aplicativo. O nosso processo atual tem algumas etapas, que podemos mapear na forma de colunas “Backlog”, “Design”, “Desenvolvimento”, “Testes”, “Deploy” (implantação) e “Pronto”. Neste quadro Kanban, as unidades de trabalho representam coisas que geram algum benefício ao cliente/usuário final, como novas funcionalidades, correção de defeitos ou melhorias na interface do produto. O valor é gerado somente quando um item alcança a última etapa:
Apesar de conter etapas sequenciais e cartões, isso ainda não é um sistema Kanban. Vamos fazer mais duas mudanças para tornar o fluxo puxado:
- Dividir as colunas intermediárias em dois estágios: “fazendo” e “pronto”;
- Adicionar limites de trabalho em progresso
Feitas essas mudanças, o nosso quadro ficaria assim:
Vamos analisar como isso funcionaria na prática. Supondo que você é o especialista em Design do time e que você está trabalhando em uma funcionalidade. Após você concluir a sua atividade, você movimenta o cartão para a etapa “Pronto” da coluna “Design”. Se um desenvolvedor (que atua na etapa “Desenvolvimento”) está livre, ele pode perceber que você sinalizou a conclusão da sua parte e então “puxar” o cartão para a etapa “Fazendo” da coluna “Desenvolvimento”.
Repare que o limite “1” da coluna “Design” é válido tanto para “Fazendo” quanto “Pronto”. No caso acima, temos um item que foi concluído pelo Designer, mas ainda não foi puxado. O que o Designer faz nesse caso? Nada. Ele apenas aguarda alguém puxar o item para Desenvolvimento. Nesse caso o slot seria liberado e ele poderia trabalhar em outro item.
Claro que na prática se não houver slot disponível o membro do time não vai ficar simplesmente parado. Em um sistema Kanban, estimulamos as pessoas a olharem para o fluxo como um todo e buscarem formas de aumentar a vazão. Pode ser que o Designer possa ajudar alguém no Desenvolvimento. Pode ser que ele use esse tempo para pensar em melhorias. O que importa é não ficar simplesmente trabalhando na própria função, pois isso aumentaria o estoque e prejudicaria o fluxo.
Parece contra intuitivo, mas a teoria das filas comprova. A ociosidade no fluxo aumenta a vazão. Para entender os porquês, você vai precisar estudar um pouco de matemática (esse livro é um bom começo).
Como os itens são puxados apenas quando há capacidade disponível, raramente há sobrecarga. Isso é que o chamamos de sistema puxado. Ele é um contraste à forma tradicional de trabalhar, que chamamos de sistema empurrado. Vamos entender a diferença entre os dois para compreender melhor um sistema Kanban. ;)
Sistema Empurrado
Um sistema empurrado é aquele em que a produção é baseada na demanda, sem respeito à capacidade do sistema. Em geral, no paradigma empurrado tenta-se produzir o máximo possível e em grandes lotes, sem considerar a real necessidade dos clientes. Neste tipo de abordagem, a estratégia de marketing e vendas também é focada em vender e “empurrar” os produtos para o cliente.
No nosso exemplo do time de desenvolvimento de um aplicativo, um gestor poderia atribuir diversas tarefas aos membros do time, exigindo que todos se mantivessem ocupados e trabalhando 100% do tempo, cada um na sua função. Além disso, é provável que esse time desenvolvesse um grande número de funcionalidades inúteis e que não gerassem valor para o cliente final. Afinal, todos estariam preocupados em fazer bem a sua função, e não em entregar valor para o cliente.
Os principais efeitos colaterais de um sistema empurrado são sobrecarga, demoras nas entregas, grandes lotes e burnout das pessoas.
Sistema Puxado
Um sistema puxado é aquele em que os participantes “puxam” o trabalho quando há capacidade disponível para executá-lo. Isso é possível quando atribuímos limites para as unidades de trabalho em progresso. Um sistema puxado nunca irá sofrer com sobrecarga se os limites forem estabelecidos corretamente. Nesse paradigma busca-se atingir um passo sustentável, ou seja, um equilíbrio entre a capacidade do time e o que é demandado dele.
O método Kanban é apenas uma forma de construir um sistema puxado. Outras variações também existem, como CONWIP e DBR.
Agora que conhecemos a diferença entre empurrado e puxado, vamos entender um pouco mais sobre os princípios e propriedades básicas de um sistema Kanban.
Os princípios básicos do método Kanban
Em seu livro Kanban: successful evolutionary change for your technology business, David J. Anderson descreve os princípios básicos do método Kanban:
Comece com o que você tem hoje. O método Kanban propõe uma abordagem evolucionária e incremental. Por mais que você esteja muito insatisfeito com a forma como as coisas são feitas no processo atual, não mude tudo logo no início. Fazer grandes mudanças pode aumentar a resistência das pessoas, além de ser muito arriscado para a organização.
Busque mudanças incrementais e evolucionárias. Depois de partir do seu processo atual, busque pequenas mudanças. Formule hipóteses com base na sua observação do comportamento do sistema. Seja curioso e faça experimentos.
Vamos supor que o seu sistema possui uma coluna onde um grande documento é produzido que detalha o que deve ser feito. Talvez você desconfie que o nível de detalhe seja grande demais e que isso é um provável desperdício. Formule a hipótese: Se nós simplificarmos o documento, teremos uma redução do Lead Time do processo. Você pode estar certo ou não. Faça um experimento, meça os resultados e compare.
Respeite o processo atual, papéis, responsabilidades e títulos. É provável que na organização em que você está implementando o método Kanban existam cargos e autoridades definidas. Talvez essa estrutura esteja atrapalhando o fluxo, na sua visão. Mas ao mesmo tempo, é também muito provável que boa parte dos processos atuais simplesmente funcione. Por isso é importante respeitar o que já está posto e perseguir a melhoria contínua a partir disso.
As 6 práticas gerais de um sistema Kanban
David J. Anderson descreve 6 práticas gerais das implementações de sucesso do método Kanban. Podemos dizer que sem elas, você ainda não está fazendo “Kanban”. Por isso que dissemos que o quadro inicial (que não tinha limites de trabalho em progresso) ainda não poderia ser considerado um sistema Kanban: ele falhava em uma das 6 práticas gerais.
As 6 práticas são:
Visualize o fluxo de trabalho. Você não pode gerenciar o que não pode ver! E se tratando de trabalho do conhecimento, esta afirmação é ainda mais verdadeira. Na Toyota, o estoque excessivo de carros poderia ser facilmente visualizado, já que um carro é um produto físico. Mas e todas as funcionalidades de um sistema que foram começadas, mas não terminadas? Ou todos os tickets de atendimento que foram abertos, lidos, mas não respondidos? O trabalho do conhecimento é intangível. É por isso que precisamos estabelecer formas tangíveis de visualizar o fluxo e as unidades de trabalho.
Limite o trabalho em progresso. Se você não estabelecer limites para o trabalho em andamento, é muito provável que você ainda esteja operando um sistema empurrado. Em geral, todas as etapas em um fluxo são limitadas, com exceção da última. Estabelecer limites vai impedir o acúmulo de estoque e também vai manter o Lead Time estável. Em geral, quanto mais itens houverem em andamento, maior é o tempo de entrega.
Gerencie o fluxo. No Kanban, focamos os esforços na otimização do sistema como um todo. A gestão tradicional empurrada foca em manter todas as pessoas ocupadas e gerenciar o trabalho delas. Isso não é feito no método Kanban. Se tentarmos otimizar uma parte do sistema (o trabalho de um desenvolvedor), isso provavelmente levará a uma situação sub-ótima globalmente. Esse fenômeno chama-se otimização local. Leia mais sobre como isso acontece com as metas.
Torne as políticas de processo explícitas. Ao trabalhar com um fluxo Kanban, você vai perceber que muitas regras de processos, papéis e definições não são claras para os participantes do fluxo. Vai surgir muita confusão sobre o significado de uma determinada coluna do fluxo, por exemplo. É importante que você aproveite essas oportunidades para esclarecer as políticas do processo e torná-las explícitas. Isso significa registrá-las em algum local acessível para todos. Parte importante de jogar o jogo é conhecer as regras.
Implemente ciclos de feedback. Nenhum processo pode evoluir sem ciclos de feedback. David J. Anderson propõe alguns rituais específicos para retroalimentar o sistema e permitir com que os participantes se adaptem comparando a situação atual do processo com as expectativas das partes interessadas.
Melhore colaborativamente. No final, as limitações de trabalho em progresso irão introduzir desconfortos e iniciar conversas sobre o fluxo. O que se busca em um sistema Kanban é um fluxo suave e constante. No entanto, não é isso que vai acontecer no início. É importante estabelecer um processo de melhoria colaborativa, onde o grupo constrói um entendimento compartilhado sobre os problemas encontrados e a partir daí propõe experimentos para melhorar o fluxo.
Quando usar o método Kanban?
Praticamente qualquer processo de desenvolvimento ou prestação de serviço pode ser melhorado com o método Kanban. No entanto, quanto maior e mais complexa a cadeia de valor desse produto/serviço, maior é o benefício em aplicá-lo.
Cadeias longas geralmente possuem muitas pessoas envolvidas, handovers e fontes de desperdício. Isso significa maiores oportunidades de melhoria. Por outro lado, se o processo for extremamente simples, provavelmente o esforço de aplicar o método é maior do que o benefício obtido.
Vantagens sobre o Scrum
Na comunidade ágil, o Scrum é o principal “concorrente” do Kanban. A palavra concorrente está entre aspas, porque a comparação não é justa. Primeiro, porque são coisas diferentes. O Scrum é um framework, enquanto que o Kanban é um método. O primeiro é muito mais prescritivo e o segundo muito mais flexível.
Deixando essa diferença de lado, quando aplicados em desenvolvimento de produtos digitais, o Kanban tem as seguintes vantagens sobre o Scrum:
Múltiplos focos. O método Kanban permite múltiplos focos de atuação. Se o seu time dá manutenção em um produto legado, e ao mesmo tempo desenvolve um novo, isso não é problema para o Kanban. Já o Scrum exige um time dedicado para o desenvolvimento de um único produto, com um único Backlog.
Entregas constantes. O método Kanban trabalha com fluxo contínuo, enquanto que o Scrum usa Sprints com timebox. Ambas as abordagens permitem entregas constantes, mas o Kanban permite ciclos ainda menores que o Scrum.
Mais evolutivo. Por ser mais prescritivo, o Scrum pode exigir que a sua organização mude radicalmente. Por exemplo, um dos requisitos do time de desenvolvimento no Scrum é que ele seja pequeno, multidisciplinar e auto-organizado. Dependendo da sua estrutura organizacional, essa mudança pode exigir uma grande reengenharia. Já o método Kanban é bem enfático na melhoria incremental e diz: comece onde você está.
Como implementar um sistema Kanban
Os princípios e as propriedades que vimos na seção anterior fornecem um caminho de implementação interessante. Segui-los em ordem já é um bom começo.
Por exemplo, o primeiro princípio é: comece de onde você está. Essa é uma boa dica. Não faça mudanças abruptas na implementação de um sistema Kanban logo de cara. Podemos ver também que a propriedade limite o trabalho em progresso vem depois de visualize o fluxo de trabalho. Isso também nos mostra que é importante primeiro enxergar o que está acontecendo na organização antes de sair aplicando as restrições, por mais que elas sejam “básicas”.
Elementos de um sistema Kanban
Um sistema Kanban possui diversos elementos e práticas atreladas. Nesta seção, veremos os mais comuns. E o primeiro de todos é…
Quadro Kanban
Sim, o quadro. Ele é uma forma simples de visualizar o andamento do fluxo e o progresso dos itens de trabalho, mas não a única. No seu livro, David J. Anderson descreve alguns exemplos de sistemas Kanban sem uso de um quadro
Atenção: ter um quadro Kanban não significa ter um sistema Kanban. Por exemplo, o uso de um quadro de tarefas (normalmente referido como quadro Kanban), é muito comum em times ágeis que praticam Scrum. Isso não implica necessariamente que há um fluxo puxado, com limites de trabalho em progresso e um processo de melhoria contínua estabelecido (o método Kanban).
Cartões
Dentro do quadro, temos cartões que simbolizam unidades de trabalho. Ao usá-los em trabalhos do conhecimento, conseguimos tornar visível o “estoque”, que é normalmente intangível.
No método Kanban é importante visualizarmos o trabalho em progresso, porque ele é desperdício em potencial. Por exemplo, todas as telas que um designer desenhou, mas que ainda não foram implementadas no produto, podem se tornar “lixo” se a empresa mudar a sua estratégia de atuação e aquilo perder prioridade. Trabalho em andamento é dinheiro que já foi investido, mas que ainda não trouxe um retorno para a organização.
Atributos dos cartões
Normalmente um cartão em um quadro Kanban possui alguns atributos, além do nome ou número de identificação.
O atributo mais comum é o tipo do item, que é normalmente classificado como valor, melhoria ou falha. No desenvolvimento de software, podemos usar tipos como nova funcionalidade, melhoria de interface e defeito, por exemplo. Os tipos de item permitem analisarmos as métricas de forma segmentada, além de nos darem uma visão mais clara sobre a composição do fluxo.
Os tipos de item são frequentemente representados usando um código de cores. Veja esse vídeo de exemplo:
Colunas do Quadro
Em um quadro Kanban, as colunas são normalmente utilizadas para representar as fases que um item de valor percorre, até ser concluído. Quanto mais a direita, mais valor e tempo foi investido.
Ao longo da sua jornada com o método Kanban, talvez você se depare com uma discussão se um cartão “deve voltar ou não” no fluxo. Imagine um cartão de uma funcionalidade X que está no fluxo acima. Vamos supor que ele está em “Testes”, mas o testador descobre que há um erro na funcionalidade que deve ser corrigido pelo desenvolvedor. Uma linha de pensamento defende que o item deve voltar para o estado que melhor representa. Outra diz que não, porque essas etapas não simbolizam “com quem está”, mas em qual estágio de valor o item se encontra.
Pessoalmente, prefiro a segunda opção por uma questão prática. Voltar o cartão tende a criar uma complicação no cálculo dos limites de trabalho em progresso. Veja esse vídeo do Buzon para mais detalhes.
Raias do Quadro
Além das colunas, que são divisões horizontais, muitos quadros possuem “raias”, que são o equivalente vertical. As raias costumam ser usadas para destacar visualmente uma classe de serviço ou para alocar capacidade por tipo de item.
No exemplo acima, utilizamos uma raia especial para destacar a classe de serviço urgente.
Limites de trabalho em progresso
Na introdução falamos sobre a importância dos limites de trabalho em progresso. Em termos de como montar o seu quadro, os limites podem ser estabelecidos por coluna, por subcoluna ou por raia. O quadro abaixo contém todos essas possibilidades.
A coluna “Design” possui um limite total de 1. Ou seja, podemos ter:
- 1 item em “Fazendo” e 0 itens em “Pronto”
- 0 itens em “Fazendo” e 1 item em “Pronto”
A coluna “Desenvolvimento” possui um limite total de 3 e um limite de 2 itens para a subcoluna “Fazendo”. A subcoluna “Pronto” não possui especificação de limite. Os seguintes cenários são permitidos:
- 2 itens em “Fazendo” e 1 item em “Pronto”
- 1 item em “Fazendo” e 2 itens em “Pronto”
- 0 itens em “Fazendo” e 3 itens em “Pronto”
Nessa forma de representação, tanto os limites para a coluna quanto a subcoluna devem ser respeitados simultaneamente. Ou seja, não poderíamos ter 3 itens em “Fazendo” (o limite da subcoluna é 2) e nem 2 em “Fazendo” e 2 em “Pronto” (o limite total é 3).
Note também que existe uma alocação por capacidade (falaremos mais abaixo), com limites especificados para as raias “Bugs” e “Features”. Nesse caso os limites se aplicam a toda a linha. Ou seja, não poderemos ter mais do que 7 itens em toda a linha de bugs (independentemente da coluna) e 5 itens em features. A soma dos limites das linhas (5 + 7 = 12) deve ser igual à soma dos limites das colunas (3 + 1+ 3 + 2 + 1 + 2 = 12).
Políticas explícitas
Parte importante do processo de implementação de Kanban é tornar as regras do fluxo conhecidas por todos. Isso envolve explicitar muitas políticas que são normalmente implícitas nas organizações. Por explicitar, queremos dizer registrar (de forma escrita) e confirmar a compreensão com todos os envolvidos.
Esse processo dá a possibilidade da construção de um entendimento compartilhado sobre as restrições do sistema. Isso é muito importante, já que queremos envolver todos no processo de melhoria.
Não há um formato específico para escrita de políticas no Kanban, mas é possível trabalhar com os elementos papéis e restrições da O2 (mais informações na seção sobre autogestão).
Aqui vão alguns exemplos de políticas explícitas:
- Somente o Gerente de Produto pode promover um item de normal para urgente.
- Os limites das raias e das colunas devem ser respeitados simultaneamente.
- Se houverem itens urgentes, puxe-os antes dos normais.
Classes de Serviço
Imagine a seguinte situação: o seu sistema Kanban está operando em capacidade máxima (todas as colunas atingindo os limites de trabalho em progresso) e de repente aparece um novo item com alto custo de oportunidade. Pode ser um defeito crítico, que se não for corrigido a tempo pode causar um grande prejuízo à organização. Ou pode ser uma nova funcionalidade, que se lançada antes do Natal (data de entrega), pode trazer um aumento de 20% na re