Por que o Kanban funciona — e como saber se a sua equipe está pronta para ele

A maioria das equipes adota o Kanban porque alguém leu um post de blog. A pergunta mais inteligente é se os problemas que o Kanban resolve são mesmo os problemas da sua equipe.

Existe um momento que a maioria das equipes reconhece, geralmente quando passam de oito ou nove pessoas. O trabalho está sendo feito — e-mails são enviados, funcionalidades são lançadas, clientes são atendidos — mas ninguém tem uma noção clara do que todo mundo está fazendo. Os projetos se acumulam. Coisas são prometidas e depois esquecidas em silêncio. Você gasta vinte minutos antes de cada reunião tentando descobrir em que pé está determinado trabalho. A resposta, normalmente, é "em algum lugar".

É esse o problema que o Kanban foi criado para resolver. Não o de definir estratégia, contratar as pessoas certas ou construir uma cultura — mas o problema operacional, específico e desgastante, de saber no que a sua equipe está trabalhando e o que está atrapalhando.

É uma ferramenta surpreendentemente modesta para algo que atraiu tanta atenção. O Kanban não promete consertar a sua organização. Ele apenas torna o trabalho visível. E a visibilidade, aplicada com consistência, acaba mudando uma quantidade notável de coisas adiante.

De onde o Kanban realmente veio

A palavra é japonesa — significa "quadro de avisos" ou "outdoor" — e o sistema foi desenvolvido pela Toyota no fim da década de 1940 para gerenciar o estoque em suas fábricas. A ideia era simples: em vez de produzir peças em um cronograma fixo, a fábrica as produziria apenas quando a etapa seguinte da linha sinalizasse que precisava delas. Um cartão físico — o kanban — voltaria pela linha como um pedido. Nada era produzido por precaução. Nada se acumulava sem necessidade.

O insight que a Toyota teve, e que as equipes de software mais tarde tomaram emprestado, é que a maior parte da ineficiência de um sistema não vem de pessoas trabalhando devagar demais, mas de trabalho errado sendo feito na hora errada. Coisas demais iniciadas ao mesmo tempo. Gargalos que ninguém percebe até ser tarde demais. Trabalho que fica pronto em um lugar enquanto a etapa seguinte está sobrecarregada em outro.

Desenvolvedores de software, principalmente em empresas como a Microsoft no início dos anos 2000, começaram a adaptar essas ideias ao trabalho do conhecimento. Os cartões viraram tarefas. As estações da fábrica viraram etapas de um fluxo de trabalho. E o quadro de avisos virou um quadro — físico no início, depois digital — em que qualquer pessoa da equipe podia ver, num relance, o que estava em andamento, o que estava aguardando e o que estava concluído.

O que um quadro Kanban realmente mostra

Um quadro Kanban básico tem três colunas: A Fazer, Em Andamento e Concluído. Isso basta para muitas equipes pequenas e é um bom ponto de partida. Mas o valor real surge quando você começa a personalizar essas etapas para refletir como o seu trabalho realmente flui — e não como você gostaria que fluísse.

Uma equipe de conteúdo pode usar: Ideia, Briefing, Em Redação, Em Revisão, Agendado, Publicado. Uma equipe de software pode dividir "Em Andamento" em colunas separadas para desenvolvimento, revisão de código e QA. Uma equipe de consultoria pode acompanhar Descoberta, Proposta, Em Execução, Aguardando o Cliente e Encerrado. As etapas devem refletir transferências reais e tempos de espera reais — os pontos em que o trabalho muda de mãos ou fica parado até que outra coisa aconteça.

Observe o cartão na coluna do meio — o relatório de auditoria do armazém, parado há oito dias e marcado como bloqueado. Em um sistema sem quadro, essa tarefa poderia ficar parada por mais duas semanas até alguém perceber que ela não está andando. Alguém está esperando por um terceiro. Ou é preciso uma decisão de um gestor que não sabe que é o gargalo. O quadro torna o bloqueio visível. Isso já é a maior parte do trabalho.

A regra que o faz funcionar: limites de WIP

Se existe um conceito que separa as equipes que usam o Kanban de verdade das que só têm uma lista de tarefas mais bonita, é o limite de trabalho em andamento — WIP (work in progress), na sigla em inglês. A ideia é que cada coluna tenha um número máximo de itens permitidos ao mesmo tempo. Quando a coluna está cheia, não dá para adicionar mais trabalho até que algo saia.

Isso parece contraintuitivo. Com certeza poder colocar mais tarefas em andamento significa que mais coisas estão sendo feitas? Não. O que realmente acontece quando as pessoas trabalham em coisas demais ao mesmo tempo é que tudo demora mais. A troca de contexto é cara. Trabalho pela metade gera sobrecarga de coordenação. E quando dez coisas estão "em andamento", fica muito difícil saber quais estão de fato avançando e quais estão apenas paradas, sem sinalização.

Um limite de WIP de três na coluna Em Andamento significa que, quando o quarto item chega à mesa de alguém, a equipe precisa decidir: qual tarefa existente será concluída primeiro? Isso força a priorização. Força a conversa. E tende a levar à conclusão mais rápida de cada item, mesmo que o ritmo de início de novos itens diminua.

Kanban versus Scrum: a pergunta que as equipes sempre fazem

Se você já conviveu com equipes de software ou com o pensamento moderno de operações, provavelmente já conheceu o Scrum — o framework que organiza o trabalho em sprints fixos de duas semanas, com reuniões de planejamento, retrospectivas e papéis definidos, como Scrum Master e Product Owner. Muitas equipes tratam Scrum e Kanban como metodologias concorrentes e sentem que precisam escolher. A distinção é, na verdade, mais simples do que isso.

Muitas equipes — especialmente as que não são de engenharia de software pura — acham as cerimônias do Scrum pesadas e a estrutura de sprints fixos difícil de aplicar ao trabalho operacional contínuo. Equipes de marketing, de customer success, de operações e fundadores que cuidam de tudo ao mesmo tempo raramente têm um trabalho que se encaixe direitinho em ciclos de duas semanas. O modelo de fluxo contínuo do Kanban tende a combinar melhor com elas.

Dito isso, muitas equipes combinam os dois. Usam ciclos de planejamento no estilo sprint para o desenvolvimento do produto e mantêm um quadro Kanban para o trabalho operacional e de suporte, que chega independentemente do sprint em que você esteja. É um híbrido perfeitamente razoável.

As três perguntas que o seu quadro deve responder em trinta segundos

Um quadro Kanban é mais útil quando você consegue olhar para ele e, sem falar com ninguém, responder rapidamente a estas três perguntas: No que a equipe está trabalhando agora? Onde o trabalho está travando? Existe algo que deveria ser feito e ainda não foi iniciado?

Se você não consegue responder às três perguntas em trinta segundos olhando para o quadro, provavelmente ele não está sendo mantido da forma correta. O modo de falha mais comum é um quadro em que as tarefas são criadas, mas nunca se movem — ele vira um cemitério de boas intenções, em vez de um mapa vivo do trabalho real. Um quadro desatualizado é pior que nenhum quadro, porque cria uma falsa sensação de visibilidade.

A disciplina necessária para manter um quadro é real. As tarefas precisam se mover quando o trabalho se move. Itens bloqueados precisam ser sinalizados assim que travam, não duas semanas depois. Os cartões precisam ter responsáveis claros, e os responsáveis precisam atualizar seus cartões. Nada disso exige muito tempo — uma prática de Kanban bem conduzida pode levar de cinco a dez minutos por pessoa por dia —, mas exige consistência. As equipes que mais se beneficiam do Kanban são as que tratam o quadro como a fonte da verdade, e não como um exercício complementar de registro.

O que o Kanban não faz

O Kanban não é uma ferramenta de estratégia. Ele não vai ajudar você a descobrir em que trabalhar — apenas a gerenciar aquilo em que você já decidiu trabalhar. Se a sua organização tem um problema de priorização, ou de mandato pouco claro, ou o problema de "começamos projetos demais antes de terminar os antigos", enraizado no comportamento da liderança e não no processo, um quadro Kanban vai revelar esses problemas, mas não vai resolvê-los.

Ele também não substitui uma boa gestão. Um quadro não substitui reuniões individuais (one-on-ones), uma delegação criteriosa ou uma comunicação clara sobre por que determinado trabalho importa. Às vezes as equipes adotam ferramentas de processo esperando que o processo faça o trabalho relacional e organizacional que, na verdade, é do gestor. Não vai fazer.

O que ele faz é reduzir a incerteza difusa que atrasa a maioria das equipes. Perguntas como "quem está trabalhando em quê", "isso já está pronto" e "o que devo pegar em seguida" geram uma quantidade enorme de comunicação de baixo valor em organizações que não têm um sistema compartilhado e visível. O Kanban elimina a maior parte desse ruído. E, para as equipes em que esse ruído é o problema dominante, a diferença é significativa.

Como começar — sem um workshop de três dias

As melhores implementações de Kanban que já vi começaram pequenas e foram evoluindo. As piores envolveram um consultor, um retiro de dois dias e um quadro lindamente desenhado que ninguém mais usava na terceira semana.

Comece com a sua equipe como ela realmente é e com o trabalho que vocês realmente têm. Crie três colunas: Backlog, Em Andamento, Concluído. Passe trinta minutos com a equipe colocando cada item de trabalho atual em um cartão. Combinem uma regra: quando você começa algo, isso vai para o quadro. Quando algo avança, você move o cartão. Não faça mais nada por duas semanas.

Depois de duas semanas, olhem o quadro juntos. Onde as coisas se acumularam? O que ficou no Backlog, embora todos dissessem que era prioridade? O que andou mais rápido do que o esperado? O que travou, e por quê? Use o que você observou para refinar as colunas e dar mais especificidade. Talvez "Em Andamento" precise ser dividida em "Em Andamento" e "Aguardando Terceiros". Talvez você precise de uma coluna chamada "Em Revisão" porque essa etapa vive se perdendo. Deixe o quadro evoluir em resposta ao que o seu trabalho real revela, e não ao que um livro de metodologia diz que ele deveria ser.

A visão de longo prazo: métricas de fluxo

Depois que um sistema Kanban está em funcionamento, ele gera dados que a maioria das equipes nunca usa. O lead time — o tempo total desde a criação de uma tarefa até a sua conclusão — é o mais importante. Se o lead time médio de uma tarefa típica é de doze dias e você quer que seja de cinco, agora você tem um número a perseguir e um quadro que vai mostrar para onde vão esses sete dias extras.

O cycle time mede apenas o período de trabalho ativo, sem contar o tempo em que a tarefa fica parada no backlog. O throughput mede quantos itens a equipe conclui por semana. Nenhuma dessas métricas exige software especial, desde que você seja disciplinado em registrar quando os cartões são criados e quando são encerrados. E, juntas, elas dão uma imagem muito mais honesta da capacidade da equipe do que qualquer processo de planejamento baseado em estimativas.

A maioria das equipes pequenas e médias nunca chega a esse ponto. Elas usam o Kanban como ferramenta de visibilidade — o que já tem valor por si só — e não vão além. Tudo bem. Mas, se você se perceber querendo assumir compromissos com stakeholders sobre quando algo vai ficar pronto, ou querendo entender por que certo trabalho leva três vezes mais do que o esperado, as métricas estão lá quando você precisar.