Porque é que o Kanban funciona — e como saber se a sua equipa está preparada

A maioria das equipas adota o Kanban porque alguém leu um artigo de blogue. A pergunta mais inteligente é saber se os problemas que o Kanban resolve são mesmo os problemas da sua equipa.

Há um momento que a maioria das equipas reconhece, geralmente quando passam a ter mais de oito ou nove pessoas. O trabalho vai sendo feito — enviam-se e-mails, entregam-se funcionalidades, gerem-se clientes —, mas ninguém tem uma noção clara do que os outros estão a fazer. Os projetos acumulam-se. Prometem-se coisas que depois ficam silenciosamente esquecidas. Gasta vinte minutos antes de cada reunião a descobrir em que ponto está realmente um trabalho. A resposta, quase sempre, é "algures".

É este o problema que o Kanban foi concebido para resolver. Não o problema de definir a estratégia, de contratar as pessoas certas ou de construir uma cultura — mas o problema operacional, específico e desgastante, de saber em que está a sua equipa a trabalhar e o que a está a travar.

É uma ferramenta surpreendentemente humilde para algo que atraiu tanta atenção. O Kanban não pretende corrigir a sua organização. Limita-se a tornar o trabalho visível. E acontece que a visibilidade, aplicada de forma consistente, muda um número notável de coisas a jusante.

De onde veio realmente o Kanban

A palavra é japonesa — significa "painel de sinalização" ou "quadro de avisos" — e o sistema foi desenvolvido pela Toyota no final da década de 1940 como forma de gerir o inventário nas suas fábricas. A ideia era simples: em vez de produzir peças segundo um calendário fixo, a fábrica só as produziria quando um posto a jusante sinalizasse que precisava delas. Um cartão físico — o kanban — percorria a linha em sentido inverso, como um pedido. Nada era feito de forma especulativa. Nada se acumulava desnecessariamente.

A perceção que a Toyota teve, e que as equipas de software viriam a adotar, é que a maior parte da ineficiência de um sistema não resulta de as pessoas trabalharem devagar demais, mas de se fazer o trabalho errado na altura errada. Demasiadas coisas começadas ao mesmo tempo. Estrangulamentos que ninguém nota até ser tarde demais. Trabalho que fica concluído num sítio enquanto o passo seguinte está sobrecarregado noutro.

Os programadores, sobretudo em empresas como a Microsoft no início dos anos 2000, começaram a adaptar estas ideias ao trabalho do conhecimento. Os cartões passaram a ser tarefas. Os postos da fábrica passaram a ser fases de um fluxo de trabalho. E o painel passou a ser um quadro — físico no início, depois digital — onde qualquer pessoa da equipa podia ver, num relance, o que estava em curso, o que estava à espera e o que estava concluído.

O que um quadro Kanban realmente mostra

Um quadro Kanban básico tem três colunas: Por fazer, Em curso e Concluído. É suficiente para muitas equipas pequenas e um bom ponto de partida. Mas o valor real surge quando começa a personalizar estas fases para corresponderem à forma como o seu trabalho realmente flui — e não à forma como gostaria que fluísse.

Uma equipa de conteúdo pode usar: Ideia, Briefing, Em rascunho, Em revisão, Agendado, Publicado. Uma equipa de software pode dividir "Em curso" em colunas separadas para desenvolvimento, revisão de código e QA. Uma equipa de consultoria pode acompanhar Descoberta, Proposta, Ativo, À espera do cliente e Fechado. As fases devem refletir passagens de testemunho reais e tempos de espera reais — os sítios onde o trabalho muda de mãos ou fica parado até acontecer outra coisa.

Repare no cartão da coluna do meio — o relatório de auditoria do armazém, com oito dias e marcado como bloqueado. Num sistema sem quadro, esta tarefa podia ficar parada mais duas semanas até alguém reparar que não avança. Alguém está à espera de um terceiro. Ou é preciso uma decisão de um gestor que não sabe que é ele o bloqueio. O quadro torna o bloqueio visível. É nisso que consiste a maior parte do trabalho.

A regra que faz tudo funcionar: limites de WIP

Se há um conceito que separa as equipas que usam o Kanban como deve ser das que têm apenas uma lista de tarefas mais bonita, é o limite de trabalho em curso — limites de WIP, para abreviar. A ideia é que cada coluna tem um número máximo de itens que podem lá estar ao mesmo tempo. Quando uma coluna está cheia, não se pode acrescentar mais trabalho até que algo saia.

Parece contraintuitivo. Certamente poder ter mais tarefas em curso significa que se faz mais? Não. O que realmente acontece quando as pessoas trabalham em demasiadas coisas em simultâneo é que tudo demora mais. A mudança de contexto é cara. O trabalho a meio cria custos de coordenação. E quando dez coisas estão "em curso", é muito difícil perceber quais estão realmente a avançar e quais estão apenas paradas, mas sem marcação.

Um limite de WIP de três na coluna Em curso significa que, quando o quarto item chega à secretária de alguém, alguém da equipa tem de tomar uma decisão: que tarefa existente é concluída primeiro? Obriga a priorizar. Obriga a conversar. E tende a produzir uma conclusão mais rápida de cada item, mesmo que o ritmo de arranque de novos itens abrande.

Kanban versus Scrum: a pergunta que as equipas fazem sempre

Se já passou algum tempo junto de equipas de software ou do pensamento moderno de operações, é provável que tenha encontrado o Scrum — o framework que organiza o trabalho em sprints fixos de duas semanas, com sessões de planeamento, retrospetivas e funções definidas como Scrum Master e Product Owner. Muitas equipas tratam o Scrum e o Kanban como metodologias concorrentes e sentem que têm de escolher. A distinção é, na verdade, mais simples do que isso.

Muitas equipas — especialmente as que não são puramente de engenharia de software — consideram o cerimonial do Scrum pesado e a sua estrutura de sprints fixos incómoda de aplicar ao trabalho operacional contínuo. As equipas de marketing, de sucesso do cliente, de operações e os fundadores que gerem tudo ao mesmo tempo raramente têm trabalho que caiba bem em ciclos de duas semanas. O modelo de fluxo contínuo do Kanban tende a adequar-se melhor a estes casos.

Dito isto, muitas equipas combinam ambos. Usam ciclos de planeamento ao estilo dos sprints para o desenvolvimento de produto e, ao mesmo tempo, um quadro Kanban para o trabalho operacional e de suporte, que chega independentemente do sprint em que se esteja. É um híbrido perfeitamente razoável.

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

Um quadro Kanban é mais útil quando consegue olhar para ele e, sem falar com ninguém, responder rapidamente a estas três perguntas: em que está a equipa a trabalhar neste momento? Onde está o trabalho a ficar parado? Há alguma coisa que devia estar a ser feita e ainda não foi iniciada?

Se não conseguir responder às três em trinta segundos de olhar para o quadro, é provável que ele não esteja a ser bem mantido. O modo de falha mais comum é um quadro onde as tarefas são criadas, mas nunca se movem — torna-se um cemitério de boas intenções em vez de um mapa vivo do trabalho real. Um quadro desatualizado é pior do que não ter quadro, porque cria uma falsa sensação de visibilidade.

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

O que o Kanban não faz

O Kanban não é uma ferramenta de estratégia. Não o ajuda a descobrir em que trabalhar — apenas a gerir aquilo em que já decidiu trabalhar. Se a sua organização tem um problema de priorização, um problema de mandato pouco claro, ou um problema de "começámos demasiados projetos antes de acabar os antigos" enraizado no comportamento da liderança e não no processo, um quadro Kanban vai revelar esses problemas, mas não os resolverá.

Também não substitui uma boa gestão. Um quadro não substitui as reuniões individuais, a delegação ponderada nem uma comunicação clara sobre a razão de determinado trabalho ser importante. As equipas por vezes adotam ferramentas de processo à espera de que o processo faça o trabalho relacional e organizacional que é, na verdade, o trabalho do gestor. Não vai fazer.

O que fará é reduzir a incerteza de fundo que trava a maioria das equipas. As perguntas "quem está a fazer o quê", "isto está pronto?" e "o que devo pegar a seguir?" geram enormes quantidades de comunicação de baixo valor em organizações sem um sistema partilhado e visível. O Kanban elimina a maior parte desse ruído. E, para as equipas 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 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 usou até à terceira semana.

Comece com a sua equipa tal como ela é, com o trabalho que realmente tem. Crie três colunas: Backlog, Em curso, Concluído. Gaste trinta minutos com a equipa a pôr cada item de trabalho atual num cartão. Combinem uma regra: quando se começa algo, vai para o quadro; quando avança, move-se o cartão. Não faça mais nada durante duas semanas.

Passadas duas semanas, olhem juntos para o quadro. Onde se acumulou trabalho? O que ficou no Backlog e todos diziam ser prioridade? O que avançou mais depressa do que o esperado? O que ficou preso, e porquê? Use o que observa para refinar as colunas e dar-lhes mais especificidade. Talvez "Em curso" precise de se dividir em "Em curso" e "À espera de terceiros". Talvez precise de uma coluna chamada "Em revisão" porque esse passo continua a perder-se. 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 devia ser.

O jogo de longo prazo: métricas de fluxo

Quando um sistema Kanban está em funcionamento, gera dados que a maioria das equipas nunca usa. O lead time — o tempo total desde que uma tarefa é criada até ser concluída — é o mais importante. Se o seu lead time médio para uma tarefa típica é de doze dias e quer que seja de cinco, passa a ter um número para trabalhar e um quadro que mostra para onde estão a ir esses sete dias a mais.

O cycle time mede apenas o período de trabalho ativo, excluindo o tempo em que uma tarefa fica no backlog. O throughput mede quantos itens a sua equipa conclui por semana. Nenhuma destas métricas exige software especial, desde que seja disciplinado a anotar quando os cartões são criados e quando são fechados. E, em conjunto, dão uma imagem muito mais honesta da capacidade da sua equipa do que qualquer processo de planeamento baseado em estimativas.

A maioria das equipas pequenas e médias nunca chega aqui. Usam o Kanban como ferramenta de visibilidade — o que é valioso por si só — e não vão mais longe. Está bem. Mas, se der por si a querer assumir compromissos com stakeholders sobre quando algo estará pronto, ou a querer perceber porque é que certo trabalho demora três vezes mais do que o previsto, as métricas estão lá quando precisar delas.