Menu fechado

Kaikaku – Kaizen

Você é um gerente de uma grande empresa de software. Sua função é desenvolver projetos ou produtos e mantê-los funcionando 100%. Você “cuida” de mais ou menos 100 pessoas entre analistas, desenvolvedores e testers e seu desafio é deixar os usuários felizes com pouca encheção de saco. Recentemente você participou de um evento “de Agile” e algum consultor (ou outro gerente como você) relatou numa palestra as dificuldades e eventuais resistências que eles enfrentaram numa transição “pra Agile”. Até deu medo. Algumas palestras você deve ter ouvido falar coisas como acabar com as hierarquias, juntar as áreas de negócio com desenvolvimento e qualidade, demitir os gerentes… Você se sentiu confuso e atordoado com a veemência que o palestrante disse aquilo que é certo ou errado no Scrum, XP ou qualquer outra coisa. Você também teve dificuldade de entender como tudo aquilo caberia no seu ambiente, com certeza.

O objetivo deste artigo é falar um pouco sobre melhoria de processos e nasceu de um bate-papo muito bom com David Anderson no Twitter após a minha re-leitura recente do livro Lean Thinking de Womack e Jones.

No cenário acima, aonde você é o gerente a frente de um departamento de TI, muitas coisas estão em jogo quando você quer mudanças. Os orçamentos de TI atuais mesmo em empresas médias podem passar de milhões e cada vez mais a TI está no centro das decisões estratégicas dos negócios. Uma decisão de mudança errada pode acarretar em grandes prejuízos e quer queira quer não, as coisas da maneira que estão na TI atual “funcionam”, mas de forma traumática e com constante atrito entre todos os envolvidos.

Atualmente temos uma grande febre de empresas tentando adotar Scrum, e como o Scrum é um pacote fechado com papéis, cerimômias, artefatos, regras e até um curso de dois dias que te dá o status “master certified”, muitas empresas sonham em usar ele. O que me apavora é que para a maioria das empresas “usar Scrum” lhes parece incrivelmente fácil e assim serão “Agile”. Ledo engano. O Scrum requer profundas mudanças organizacionais, especialmente para empresas grandes. Auto-organizar um grupo multi-disciplinar de forma a entregar software funcionando em um curto espaço de tempo é totalmente diferente do que as empresas médias e grandes estão acostumadas a fazer. Geralmente o que temos nessas empresas são grandes projetos com feedback tardio, alto grau de comando-controle e grupos divididos por função entre negócio, desenvolvimento e testes. Implantar Scrum é uma excelente alternativa, porém, saiba que vai doer. Implantar Scrum significa a gestão abdicar de muitos instrumentos de controle, quebrar com a separação entre os grupos e mudar posições hierarquicas estabelecidas. Isso é Kaikaku.

Alguns autores e palestrantes atuais tem algum preconceito com palavras japonesas que vieram dos pensadores da Toyota, destacando Taiichi Ohno que batizou a grande maioria desses termos no TPS. Eu pelo contrário creio que devemos dar muito crédito à cultura Toyota. Kaikaku é uma palavra que define mudanças de processos classificadas como “melhoria radical”. Para exemplificar, como defendido por Womack e Jones na sua literatura:

“A abordagem Lean é criar verdadeiros times de produto dedicados com todo skill necessário para especificar o que é valor, definir o design, detalhar a engenharia, as compras, as ferramentas e o planejamento da produção em uma sala em um curto período de tempo usando técnicas para tomada de decisão…”

Logicamente, se sua empresa hoje não é organizada por times de produtos (como o Google, a Microsoft, a Globo.com entre outras), você terá que fazer grandes mudanças organizacionais para alcancar esse primeiro patamar de melhoria que te habilita a iniciar com o Scrum. São mudanças radicais – Kaikaku. Implantar o Scrum exige isso nesse cenário.

O Sprint do Scrum é um mecanismo interessante e bem pensado. Olhando sob as lentes Lean, o Sprint é uma janela de tempo (timebox) que um grupo unindo suas habilidades tem para gerar valor com um feedback forçado ao final (o Review). O que ocorre quando temos grupos especializados na corrente de valor (como exemplo: equipe de negócio, equipe de desenvolvimento, equipe de testes) é uma baixa inter-fertilização, geralmente causada pela procura dos culpados quando há falhas e falta de foco no objetivo. Quando você separa áreas por funções ou habilidades cada parte pensa no seu próprio umbigo e facilmente se esqueçem do objetivo maior da empresa ou do projeto.

Nesse ambiente cada área separada tem várias coisas a fazer, está fazendo várias coisas e entregou várias coisas recentemente. Há uma “passagem de bastão” entre todas as áreas, e assim, filas se formam. O negócio alimenta a fila do desenvolvimento que alimenta a fila do QA. Como nesse meio pode ter bloqueios, falhas e gargalos, hoje o QA está testando as demandas desenvolvidas na semana passada que foram levantados pelo negócio no mês passado, e tudo que entrar de novo em QA ou desenvolvimento terá que esperar. Para este artigo estou levando em consideração somente três áreas. Se sua empresa tem 4 ou 5 áreas funcionais o cenário das filas poderia ser este:

timesfilas

Na visão do Scrum filas e gargalos são resolvidos juntando as pessoas em um único grupo auto-organizado e usando Sprints para avaliar a saúde do sistema de tempos em tempos. Com isso o fluxo será melhorado profundamente, porém, o Scrum muda o sistema para gerar visualização dos problemas e isso exige um Kaikaku (melhoria/mudança radical). A questão não é se isso funciona ou não. A questão é se sua empresa quer e suporta isso ou não. Felizmente se ela não quiser fazer este Kaikaku há alternativas.

Kaizen é a palavra Lean para indicar mudanças de melhoria menores e contínuas. Ao contrário do Kaikaku, Kaizen não é tão traumático, é melhor aceito por todos (gerentes inclusive) e mais simples de se implementar. Tudo a nossa volta está suscetível a um evento Kaizen. Kaizen simplesmente significa mudança para melhor.

Filas são um grande problema para a gestão, e acho realmente incrível na minha experiência de mercado, que são poucos os gestores que sabem ou ligam para o mal que elas representam. Gestores muitas vezes querem controlar as filas e não eliminá-las. Filas retardam mecanismos de feedback, aumentam o lead time, geram atrasos, pioram a comunicação, criam expectativas irracionais, tornam um sistema de trabalho imprevisível, causam alienação nos grupos e mais dezenas de outras coisas ruins. Se você quer que o trabalho flua mais rápido, com mais qualidade e entregando mais valor, inicialmente, aponte todas as suas armas para as filas e não para as hierarquias ou para a separação das áreas. É licito acabar com as filas usando Scrum, porém, em diversos cenários, isso não convém. Algumas empresas não estão dispostas a pagar o Kaikaku inicial do Scrum. Se quer melhorar sem Kaikaku, use Kaizen.

Na abordagem Kanban, a cultura é Kaizen: inicialmente focamos esforços em compreender o ambiente de trabalho antes de mudá-lo. Se filas, bloqueios, gargalos ou alienação entre áreas estão nos prejudicando, primeiro, vamos visualizar isso, convencer o grupo dos problemas e usar Kaizen para a melhoria do ambiente com pequenas mudanças incrementais e constantes. Isso irá fortalecer a cultura da empresa, pois ela compreenderá suas falhas com provas palpáveis que serão a motivação para as mudanças.

O primeiro passo em direção ao Kanban é usar um quadro físico que mapeia como os lotes fluem pela empresa, tornando a bagunça explícita usando uma prática Lean chamada gestão visual (também conhecida como transparência, algo também presente no Scrum). As melhorias que tenho experimentado com esse simples primeiro passo do Kanban em algumas empresas são muito interessantes. A partir do momento que os grupos mesmo que separados começam a visualizar as filas, a quantidade enorme de trabalho em progresso (iniciado mas não terminado), os bloqueios, os gargalos, os desperdícios e as enormes falhas de comunicação comuns nos nossos ambientes de TI, a auto-organização emerge e as mudanças começam a acontecem, mesmo que sejam pequenas melhorias. O fato dos problemas estarem no quadro e o fluxo ser buscado por todos, a tomada de decisões sobre os problemas se tornam impessoais e concentradas. Todos buscam o fluxo e a entrega de valor, e com isso, muitas discussões sobre a culpa das falhas caem por terra. Kaizen: mudança para melhor de forma constante.

O que tem me atraído muito ao Kanban é exatamente essa variedade de soluções práticas que florecem das equipes quando nenhum método específico lhes é imposto. Dentro do Kanban equipes criam do nada soluções sob medida para seus ambientes usando Kaizen, coisas que não constam em livros e lhes atendem perfeitamente. Ora, se sempre estamos por aí dizendo que cada ambiente de desenvolvimento de software é único, porque se limitar a uma única maneira de fazer as coisas ou aos livros? A transição para um lugar melhor é mais interessante que o lugar melhor em si. Acho que isso é o que falta ao Agile. Já vi equipes criando práticas exóticas de teste, estabelecendo mecanismos divertidos de auto-organização, criando gameficação, promovendo reunião diária de 25 minutos que substituem o planning e solucionando questões de comunicação e priorização para times compartilhados (como infra ou teste) que me fazem questionar se times multi-disciplinares são realmente economicamente viáveis para qualquer ambiente. Não ter um método com regras é exatamente o que faz essas equipes se adaptarem a qualquer ambiente ou problema. As simples práticas do Kanban favorecem isso.

Uma grande discussão começou entre as comunidades Scrum e Kanban sobre as diferenças e a eficácia dos dois métodos sempre pensando na estrutura dos dois processos, coisas sem muita importância como a presença ou não de time-boxes. Como tenho escrito aqui no blog experiências próprias em campo com o uso das duas abordagens, digo que o uso de uma ou de outra é ditada pela vontade da empresa e da gestão dela em usar Kaikaku ou Kaizen e não tem qualquer relação com o ambiente dela. Porém, o fato que tenho observado é que em grandes empresas Kaikaku e rupturas organizacionais estão muitas vezes fora de cogitação. Nesses ambientes teremos um crescimento grande da abordagem Kanban. Se há uma maneira hoje de levar agilidade a bancos, seguradoras, grandes indústrias, telecoms e o governo, minha aposta é Kaizen e Kanban.

15 Comentários

  1. Otávio Macedo

    Excelente post, Rodrigo!

    Esse assunto de gerenciamento de filas e alienação entre áreas é o problema essencial a ser resolvido. Apesar disso, a maioria das discussões gira em torno de assuntos secundários, como o tempo das reuniões, quais ferramentas vão ser usadas etc.

    Um comentário que eu achei particularmente interessante:

    Geralmente o que temos nessas empresas são grandes projetos com feedback tardio, alto grau de comando-controle e grupos divididos por função entre negócio, desenvolvimento e testes.

    Conciso e direto. Mas, pela minha experiência, a situação é ainda mais complexa. É comum ter grupos divididos entre negócio, desenvolvimento de front-end, desenvolvimento de back-end, analistas de dados, DBAs, equipes de operações, testadores, design de interface, análise de qualidade, gerência de configuração e assim por diante. E isso, mesmo em ambientes ditos “ágeis”. A capacidade das grandes empresas de inventar áreas funcionais é praticamente ilimitada!

  2. João Carlos Clementoni Silva

    Acho que tem um erro no texto no trecho: “Filas são um grande problema para a gestão, e acho realmente incrível na minha experiência de mercado, que são poucos os gestores que sabem ou ligam para o mal elas representam”

    Muito legal o artigo.

  3. Streleski

    Bela fundamentação teórica sobre os impactos dos dois modelos. Iniciei o estudo do modelo Toyota através do livro Toyota Way e seus posts sempre colaboram para uma visão mais pratica.

    Existe previsão de turmas abertas sobre Lean e Kanban na Aspercom?

    abs

  4. Thiago Ghisi

    Grande Yoshima,

    Sensacional esse seu post, aliás, mais um post seu sensacional.

    De leitura OBRIGATÓRIA a todos que estão pensando em adotar qualquer metodologia/framework ‘Kaikaku’, como: Scrum, XP, e, principalmente CMMI (abordagem estagiada, pois a abordagem contínua do CMMI já é mais alinhada com a cultura Kaizen, pois “prega” que você deve começar mexendo aonde dói, prática por prática, processo por processo…) e MPS.BR.

    Com certeza, se eu tivesse lido esse seu(s) post(s) e o livro do David Anderson há 2 anos atrás eu teria dado bem menos “murro em ponta de faca”. 😛

    Parabéns, ficou muito bom o texto!

    Abs.

  5. Robson Ricardo

    Eu também, @Thiago Ghisi… se tivesse lido esse post a um tempo atrás, teria sido menos traumático a mudança dos processos aqui na empresa 😀

    O texto faz uma abordagem muito interessante sobre a forma de mudar, que nos faz pensar ainda mais nas razões para que se está fazendo isso e como será feito/iniciado.

  6. Andrea Pinto

    Oi Rodrigo,

    Excelente post! Quando abordo esse assunto em Kanban falo de mudança revolucionária x mudança evolucionária, tenho receio das pessoas ficarem com as “palavrinhas” na cabeça e não com a interpretação delas. Para mim também essa é A diferença entre Kanban e qualquer outra metodologia/framework Ágil, é a equipe/organização/projeto descobrir pouco a pouco suas falhas específicas com a visualização do fluxo de trabalho e claro, trabalhar maneiras de melhorar o fluxo sem receita de bolo, mas criando sua receita própria usando os seus ingredientes disponíveis.

  7. Paulo Lara

    Muito bom post!
    Acho que tem um erro no trecho: a auto-organização emerge e as mudanças começam a acontecem, mesmo que sejam pequenas melhorias.

    []’s

  8. Pingback:Minha apresentação na QConSP 2012 | Débito Técnico

  9. 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 *