As Seis Práticas Essenciais

Tudo começa com visibilidade. Se você não consegue ver, não consegue gerenciar.

Um quadro Kanban torna o trabalho visível—o que está em andamento, o que está esperando, o que está bloqueado. Mas a visualização vai além de um quadro:

• Visualizar itens de trabalho: Cartões representando trabalho real
• Visualizar fluxo de trabalho: Colunas mostrando os estágios pelos quais o trabalho passa
• Visualizar políticas: Regras explícitas sobre como o trabalho se move
• Visualizar bloqueios: Indicadores visuais quando o trabalho está travado
• Visualizar capacidade: Quanto trabalho cada estágio pode lidar

Vamos cobrir isso profundamente no Módulo 2.

Esta é a prática mais contraintuitiva e a mais poderosa. Ao fazer menos de uma vez, você termina mais no geral.

Limites WIP são restrições sobre quantos itens podem estar em um determinado estágio (ou em todo o sistema) de uma vez. Quando um limite é atingido, você não pode começar um novo trabalho—você deve ajudar a terminar algo primeiro.

Isso cria fluxo, reduz a troca de contexto e expõe gargalos. O Módulo 3 cobre isso em profundidade.

Com o trabalho visualizado e o WIP limitado, você agora pode gerenciar como o trabalho flui pelo sistema.

Gerenciar o fluxo significa:

• Medir lead time e cycle time
• Identificar e resolver gargalos
• Suavizar tamanhos de lote
• Reduzir tempos de espera

O objetivo é entrega previsível e sustentável—não sprints heroicos. O Módulo 4 cobre métricas de fluxo.

Regras implícitas criam confusão e conflito. Políticas explícitas criam clareza.

Cada coluna no seu quadro deve ter políticas claras:

• O que significa "pronto" para este estágio?
• Quem pode puxar trabalho para este estágio?
• O que acontece quando alguém está bloqueado?
• Como os conflitos são priorizados?

As políticas não precisam ser complexas. "Revisão de código requer duas aprovações" é uma política. "Itens bloqueados recebem uma bandeira vermelha e discussão no standup" é uma política.

Kanban define sete cadências—reuniões regulares para diferentes propósitos de feedback. Ao contrário dos eventos prescritos do Scrum, estas são recomendações que você adota com base na necessidade.

As cadências principais incluem:

• Standups diários (foco no fluxo, não relatórios de status)
• Reuniões de reabastecimento (priorizando novo trabalho)
• Planejamento de entrega (quando e o que liberar)
• Revisões de entrega de serviço (como estamos indo no geral?)

O Módulo 5 cobre isso em detalhes.

Isso remete à mudança evolutiva. A melhoria não é um evento único—é contínua e experimental.

Use o método científico:

1. Observe o sistema (métricas de fluxo, bloqueios)
2. Forme uma hipótese ("Reduzir o limite WIP na revisão de código vai acelerar a entrega")
3. Experimente (tente por duas semanas)
4. Meça os resultados
5. Adapte (mantenha, modifique ou reverta a mudança)

Experimentos que falham não são falhas—são aprendizado. A única falha é não experimentar.