Menu fechado

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:

kanban_modulos

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.

11 Comentários

  1. Rafael Miranda

    Excelente texto, parabéns! Cada dia me identifico mais com a cultura Lean.

    Quando você pensa que Ágil não é apenas um conjunto de práticas mas sim uma soma de crenças e princípios, sua frase se aplica perfeitamente: “Para o Kanban, não importa quais práticas você irá aplicar para melhorar o seu processo (…)”.

    O fato de que no Lean o objetivo primordial é entregar valor, sendo talvez “mais prioritário” do que, por exemplo, pessoas, pode parecer muito forte ou “contra o Ágil”. Porém, uma coisa não exclui a outra. O objetivo é manter o foco.

    Temos que lembrar que no mundo real nem todos os compromissos podem ser negociados depois de firmados. O que não significa que não devamos buscar e criar mecanismos para isso. Novamente, uma coisa não exclui a outra.

    Gosto muito do time-box do Scrum, mas para mim, nos projetos em que tive mais dificuldade com Scrum, o Kaban seria muito mais natural, e eu não teria me sentido “traindo” o Ágil como me senti na época.

    Quando vejo em cursos de CSM e CSCPO os instrutores falando que Lean e Kanban são modinha, e que pessoas como você não sabem onde estão com a cabeça, vejo o quanto toda a comunidade precisa amadurecer.

    Grade abraço, e parabéns novamente!

  2. Rodrigo Yoshima

    Rafael, obrigado pelo seu feedback. Você não é o primeiro a me dizer que os CSTs estão me criticando quanto a Lean e Kanban. Infelizmente a ScrumAlliance está parada no tempo. Não tem qualquer evolução no Scrum. Seu comentário mostrou muita maturidade.

    Lean prega muito respeito as pessoas e não somente “People over processes”. Abraços!

  3. Tiago da Costa Sivla

    Parabéns Yoshima,

    Realmente o texto mostra o mais importante não só do Kanban, mas do movimento àgil, que foi esquecido por muitos ao seguir receitas de bolo.

    O importante é estar sempre melhorando, sempre aprimorando-se, não importa que nome vc dê para a forma de fazer isso. Mas sempre com métricas e método para comprovar seus resultados e não somente com a justivicativa de que está usando uma ‘metodologia ágil’.

    []s

  4. Rafael Noronha

    Yoshima,

    Em primeiro lugar, ainda sou leigo em Lean.
    Mas vamos ao meu ponto.

    Apoiado nas suas próprias palavras, o título do artigo não está pesado demais?

    Entendo que sua mensagem seja, Lean não é menos importante que práticas ágeis, e nem precisa vir depois.

    São disciplinas diferentes e complementares não são?

    Práticas ágeis são poderosas a nível técnico.
    A nível gerencial, talvez o Lean enfrente os problemas com uma linguagem mais direta.
    É como confrontar Java com C++.

  5. Rodolpho

    Mestre Yosha, artigo duro e coeso como (quase 🙂 sempre.

    Cara, “desenvolvimento Iterativo” é melhor que Waterfall? se feito direito, SIM! Sem dúvidas. Desenvolvimento Ágil é melhor que Iterativo? Se feito direito, SIM! Absolutamente.

    Porém, Como diz o S.Ambler: “RUP feito certo é excelente. Feito errado, está só errado” e como costuma dizer o próprio Ken Schuaber: “SCRUM não é para todo mundo”.

    Depois de mais de 10 anos de consultoria e quase 20 na indústria de desenvolvimento de software, eu tenho alguma base para afirmar que no máximo uns 30% das organizações de desenvolvimento de software tem um nível de maturidade bom o suficiente para tirar total proveito destas abordagens (acho que mais 80% destas são as pequenas que podem selecionar “a dedo suas equipes” e *TEM* de ser mais eficientes).

    E o que acontece com os outros 70%? E mais: como conduzir estes 70% de um “mindset” tradicional para o Ágil?

    O que as pessoas não entendem é que Kanban é uma a melhor e mais simples técnica que já vi para conduzir um ajudar um time de desenvolvimento de software a transcender seu Status Quo para um patamar superior: Ágil e além (aliás tá aí um excelente nome para meu próximo artigo)!

    Grande abraço e “keep pushing” !!!

  6. Rafael Camargo

    Olá Yoshima.

    Bom post.

    Gostaria de saber, o que você faria hoje, como consultor, com o seu conhecimento atual, nos cases que você falhou no passado.

    O

  7. Pingback:Débito Técnico » Blog Archive » Restrospectiva Agile Brazil 2011 Fortaleza

  8. Jean Clecio

    Excelente artigo. Ainda sou leigo em metodologias ágeis, Kaizen e Kanban, mais apenas “ainda” sou, em breve pretendo ampliar meus conhecimentos e experiências e ter acesso a artigos como esse seu é de grande importância e muito, muito valor. Parabéns por compartilhar o conhecimento, tenho absoluta certeza que hoje, você está melhor do que ontem. Abraços e sucesso sempre!

  9. Pingback:O Cumulative Flow Diagram | Débito Técnico

  10. Pingback:Scrum e/ou Kanban – Por onde começar? | Débito Técnico

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *