Dizer sim ao Lean torna o resto irrelevante

Escolher o título deste artigo não foi uma tarefa fácil. Ele poderia ser algo como “Mitos do Kanban” ou “Por que primeiro Scrum e depois Kanban?”. O objetivo principal deste artigo é falar sobre Kaizen, e é direcionado para a comunidade Agile e Scrum em geral. Antes de começar quero que você avalie atentamente o quadro Kanban abaixo:

Este quadro foi sugerido a um cliente meu. Ele mostra o fluxo de módulos (que podem ter até 1000 horas de esforço) em um formato bem waterfall. O quadro possui limites altos de 5 módulos por etapa de projeto e desenvolvimento. Vocês devem estar tentando encaixar isso no seu mindset ágil. Não tentem fazer isso. Essa é uma implementação Kanban que não é Ágil. Nós podemos ter implementações Kanban não ágeis. Vocês devem estar se perguntando: “- Mas Rodrigo, como você sugeriu um Kanban cascata para o seu cliente?”. Eu respondo: antes de ter este quadro desse jeito o cliente trabalhava de uma maneira pior – o lote de trabalho era o projeto todo, não tinha qualquer visualização e sequer havia qualquer limite. Os primeiros eventos Kaizen que rolaram foram criar visualização, quebrar em lotes menores e limitar WIP. Não serão os únicos eventos Kaizen, mas foram os primeiros e o cliente aprendeu muito com isso.

O Cerne da filosofia Lean é muito simples: empresas existem para gerar valor para seus clientes. Uma grande motivação de escrever este post veio do livro “Gemba Walks” de James P. Womack. Este livro não é para a área de TI, então, se você não se interessou por Lean Manufacturing não o compre, pois ele é aplicação de Lean para indústrias. Eu particularmente gostei do livro pois me fez relembrar conceitos da época da minha gradução. Sou administrador de empresas por formação. Você trabalha no Gemba. Gemba é uma palavra japonesa que no contexto Lean significa o “local onde que as coisas acontecem”. É o local aonde há um grupo de pessoas ou equipes interessadas em gerar valor para alguém. Nós também chamamos isso de “Value Stream” ou corrente de valor. As práticas que você usa para “gerar valor” não interessam para o Lean. O importante é primeiramente gerar valor. Respeitar as pessoas, evitar desperdícios e melhorar continuamente são também muito importantes, mas o principal é atender o propósito da sua Value Stream, perpetuando a existência da organização.

Você deve usar alguns produtos de software, certo? Quero que você veja todos os produtos de software que você usa e procure na caixa do produto algo como “Feito com Scrum”, “TDD enabled” ou “We use Agile methods”. Encontrou? Questione a si mesmo porque isso não é um argumento de venda desses produtos. Simples: os clientes não dão a mínima se o produto foi feito da maneira X ou da maneira Y. Isso não lhes agrega valor. O que eles querem é ter seus problemas resolvidos de uma maneira simples e barata.

Lean é relevante porque Gembas são demasiadamente disfuncionais. Equipes tem dificuldades enormes em gerar valor. Os traumas de todas as suas falhas passadas geram a preocupação da preocupação da preocupação em não se gerar valor, e assim, muitas empresas estão entregues ao caos e sofrendo de toda forma de desperdício (muda, mura, muri). Algumas delas buscam soluções como RUP, PMBOK, Agile ou Scrum. Isso traz um questionamento: entender o método, aplicar o método e entender o porque do método são três coisas completamente diferentes.

Uma das maiores vantagens em ser consultor é a mobilidade que temos em uma organização. Bons consultores de processos podem discutir tecnicamente com desenvolvedores melhores estratégias de testes ou de build na manhã e à tarde conversar com o board de diretores sobre a estratégia do portfólio de produtos. No ínicio de 2009 desempenhava meu papel como Agile/Scrum Coach e aconteceu um episódio marcante: em uma das equipes de uma grande empresa um senhor de mais de 50 anos atuava como PO. Durante uma reunião diária ele ia dirigir uma pergunta para a equipe, mas antes ele me questionou se ele poderia fazer isso. Esse ato me chamou a atenção. Aquele PO estava preocupado se “no Scrum” ele estava com um comportamento adequado. Por alguma razão desconfiei que nisso tinha algo errado. MUITO ERRADO. O questionamento dele seria algo como “Isso é Scrum?”

Tenho visto a comunidade ágil não compreendendo o enfoque Lean do Kanban. Alguns da comunidade Scrum, especialmente os vendedores de certificação, não estão querendo se esforçar para compreender o Kanban. Muitos deles diminuem o Kanban ou espalham FUD. Kanban não se compara com Scrum, XP ou qualquer outro método. Kanban é um modelo de transição baseado em cultura Kaizen. Tirar este aspecto do Kanban é como tirar a Inspeção e Adaptação do Scrum. Kanban não tem receita de bolo. “Kanban não julga se você é Agile ou não” – essa é uma frase do Alisson Vale que ecoa na minha cabeça quase todos os dias. O maior objetivo do Kanban é melhorar um processo existente, por pior que ele seja. Na comunidade Scrum é comum o mito “começe com timeboxes e depois que estiver maduro, passe ao fluxo contínuo com Kanban”. Não! Kanban não é só isso. Como demonstrei no exemplo de Kanban acima mudamos um sistema estritamente waterfall para algo melhor e que pode melhorar continuamente até se tornar Agile e talvez até superar o Agile. Isso é a cultura Kaizen que o Kanban quer trazer a tona. Kaizen: hoje foi melhor do que ontem e amanhã será melhor do que hoje.

Kanban possui algumas propriedades. Atualmente o mercado tem se fixado muito em visualização do processo e fluxo contínuo. Poucas equipes estão indo além disso e chegando a impor limites (limitar WIP) e a gerir do fluxo (através de métricas). Kanban também sugere políticas explicitas e o uso de modelos para avaliar melhorias. “Modelos para avaliar melhorias” pode ser traduzido também como “use métodos científicos”. A falta de compreensão desta última propriedade é a causa raiz de toda má interpretação do Kanban. Ciência é conhecer. Kanban promove conhecimento. Se você analisar todo esse conjunto de propriedades juntas verá que o objetivo do Kanban é aumentar o entendimento da equipe e dos gestores sobre a natureza do trabalho que eles estão realizando. Com essas propriedades juntas uma equipe pode não somente “saber”, mas sim aplicar e observar que trabalhar com lotes menores entrega mais valor. Eles podem também não só saber mas aplicar e observar que quebrar os silos entre equipes pode melhorar a comunicação e entregar mais valor. Eles podem chegar a conclusão que colaborar com os usuários em ciclos mais rápidos gera mais valor. Kanban pode mostrar para eles a maneira mais eficiente deles trabalharem dadas as características únicas de seu ambiente, seu mercado e seu produto. Isso é entregar valor na abordagem Lean. Entendimento e experimentos geram melhoria. Melhoria gera mais valor. Isso é Kanban.

O que descreví no parágrafo anterior é muitas vezes diferente da abordagem Agile. Nós passamos os últimos 10 anos tentando explicar o que é o Agile e hoje muita gente “sabe” o que Agile é, mas não aplica e nem não sabe os porquês. Um médico na TV pode falar “pratique exercícios regularmente”. Todo mundo sabe que praticar exercícios é importante, mesmo assim poucos praticam! Isso é o que acontece com o Agile. No Kanban um médico fala “chequei que sua pressão arterial é altíssima, assim como o seu colesterol – assim, dado seu estilo de vida, 30 minutos de caminhada poderia melhorar suas condições, vamos observar os resultados…”. Pergunta: Qual dessas abordagens é mais convincente para sua equipe e seu gerente? Chega a ser hilário alguns praticantes de Scrum dizendo que “aqui é Scrum mas com testes automatizados” como se isso lhes dessem um selinho Agile. Pergunte para eles o porque do Scrum e dos testes e poucos deles darão uma resposta convincente além de citar seus autores preferidos.

As frases que poderiam resumir esse artigo são duas citações:

“Nunca ví uma empresa ter sucesso seguindo as melhores práticas”
Dave Snowden durante o LSSC11

“O segredo da Toyota é sua auto-suficiência. A Toyota tem seus próprios treinamentos, cria suas próprias práticas e suas ferramentas. Todas as vezes que vocês copiam a Toyota vocês se parecem menos com a Toyota.” W. Edward Deming para um grupo de empresários americanos

Usar Kanban é criar um ambiente (e visualizações) onde o entendimento seja aumentado e isso patrocine uma cultura Kaizen. Kanban não é somente fluxo contínuo ou um quadro na parede. Para o Kanban, não importa quais práticas você irá aplicar para melhorar o seu processo, mas para o Kanban é importante que você use argumentos científicos que expliquem o porquê dessas decisões. Kanban é um corpo de conhecimento aplicável a diversas áreas. Atualmente no meu trabalho de consultor tenho aplicado Kanban para equipes de desenvolvimento, equipes de manutenção, equipes Scrum, gestão de portfólio e muitos outros ambientes. Espero em breve contar mais histórias aqui sobre a versatilidade do Kanban.