Lean e Agile: Ancestrais e Primos

O Manifesto Ágil foi escrito em 2001. O sistema de produção da Toyota começou a evoluir na década de 1940. O pensamento Lean antecede o ágil em mais de meio século.

Isso importa porque as práticas Ágeis frequentemente só fazem sentido à luz dos princípios Lean. Por que favorecemos "software funcionando em vez de documentação abrangente"? Porque documentação antes de codificar é inventário—uma forma de desperdício. Por que queremos "responder a mudanças em vez de seguir um plano"? Porque planos de longo prazo são especulação, e especulação produz desperdício quando a realidade difere.

Muitas dificuldades ágeis vêm de equipes adotando práticas sem entender os princípios subjacentes. Elas fazem standups diários porque o Scrum diz para fazer, não porque entendem como isso reduz desperdício de coordenação. Elas fazem time-box de sprints porque esse é o framework, não porque entendem como lotes pequenos reduzem risco.

Quando você entende Lean, as práticas Ágeis se tornam óbvias. Quando não entende, elas parecem rituais arbitrários.

Scrum adotou vários conceitos Lean:

• Time-boxing como uma restrição de tamanho de lote
• Equipes multifuncionais para reduzir transferências
• Retrospectivas para melhoria contínua
• Auto-organização como respeito pelas pessoas
• Software funcionando a cada sprint (entrega JIT)

Extreme Programming (XP) é ainda mais explicitamente Lean:

• Programação em par reduz defeitos (construir qualidade)
• Integração contínua previne inventário (lotes pequenos)
• Desenvolvimento orientado a testes detecta bugs cedo (Jidoka)
• Design simples evita desperdício (YAGNI)
• Ritmo sustentável respeita as pessoas

Kanban é o método mais diretamente derivado do Lean. David Anderson adaptou explicitamente conceitos do TPS: sistemas pull, limites de WIP, visualização de fluxo, melhoria contínua. Se o Scrum emprestou a filosofia do Lean, o Kanban emprestou seus mecanismos.

Nenhum desses métodos exige que você entenda Lean para usá-los. Mas entender Lean ajuda você a:

• Saber quando quebrar as regras
• Adaptar práticas ao seu contexto
• Diagnosticar por que as coisas não estão funcionando
• Combinar práticas de forma coerente

Embora Lean forneça a base, Agile adicionou elementos importantes para o trabalho do conhecimento:

Abraçar a incerteza: O Lean de manufatura otimizou processos conhecidos. O desenvolvimento de software enfrenta incerteza fundamental—frequentemente não sabemos o que construir ou como construir até tentarmos. Agile explicitamente incorpora mecanismos para descoberta: iterações, feedback de usuários, pivôs.

Timeboxes: O TPS não precisava de sprints—a produção era contínua. Agile introduziu timeboxes como uma função de força para equipes de software não acostumadas ao fluxo contínuo. O timebox cria ritmo, limita o aumento de escopo e força entrega regular.

Cerimônias: Retrospectivas, standups, revisões—esses são mecanismos para os ciclos de feedback que o Lean requer, adaptados para equipes de trabalho do conhecimento. Eles não são exclusivos do Agile (a Toyota tinha práticas similares), mas o Agile os codificou para software.

O elemento humano: Embora o pilar "Respeito pelas Pessoas" do Lean seja profundo, Agile o tornou mais explícito para o trabalho do conhecimento. "Indivíduos e interações em vez de processos e ferramentas" do Manifesto e o "ritmo sustentável" do XP enfatizam que o trabalho do conhecimento requer motivação intrínseca, não apenas eficiência de processo.

Nem Lean nem Agile são completos sozinhos. Lean fornece princípios e teoria. Agile fornece práticas específicas para software. As melhores equipes extraem de ambos.