Ep. 13 - Kanban

Tem uma história, a minha história com agilidade se misturou com Kanban de tal maneira que eu quase não lembro como era antes. Fiz um curso com o David Anderson em 2009, quando ele foi ao Brasil, com o manuscrito do Blue Book. A necessidade do uso foi por causa da dor: a gente começou com Scrum, começa a sentir algumas dores, e pensa como resolver. A quantidade de referências que a gente tinha na época não era a mesma que temos hoje. O Kanban apareceu para preencher os gaps que a gente estava tendo. E foi o tempo todo, desde então, feedback loop e mudança evolucionária para todo tipo de problema que a gente tinha, a ponto de eu não saber mais como não pensar em Kanban.

Quais problemas estamos tentando resolver com o método Kanban? O que está mais perto do meu coração, em termos de importância, continua sendo o aspecto de gestão de mudança. Porque a gente está cheio de método, cheio de framework, mas o desafio é quais mudanças a gente tem que fazer e como essas mudanças ficam ao longo do tempo. O que eu acho legal do Kanban é que ele se aproxima muito da maneira como as coisas funcionam para a gente como seres humanos: exercício físico, tocar instrumento, aprender língua. Não tem milagre, é só fazendo um pouquinho todo dia, durante muito tempo. Não adianta nenhuma promessa de solução rápida. Em termos de qual problema resolve, eu acho que um dos principais é fazer a mudança e aumentar as chances da mudança continuar ao longo do tempo. Secundário vem toda a parte de orientação de serviços, garantir que a organização está fazendo a coisa certa da melhor maneira.

As pessoas procuram muito bala de prata, que problema resolve, como se trazendo um método, esse método fosse resolver instantaneamente, quase miojo, três minutinhos e pronto. Quando na verdade a gestão de fluxo também é um meio do caminho para algo maior, que é a mudança do mundo e a melhoria. Como seres humanos, a gente quer soluções rápidas. Que problemas o Kanban não resolve? Essa é difícil de responder. Quando eu olho o Kanban, a gente tem um conjunto de princípios envolvendo gestão de mudança, e as práticas que ajudam na gestão de mudança, e você visualizar o que está acontecendo. Na minha carreira, não encontrei até hoje um momento em que eu não pudesse usar pelo menos uma das coisas dali. Não sendo um método bala de prata que você aplica para resolver, é difícil definir o que não resolve.

Numa perspectiva mais fundamentalista, no detalhe do método, talvez ambientes que não estejam procurando algum tipo de estabilidade de fluxo não tirem tanto proveito de Kanban, ambientes mais caóticos. Mas é engraçado, porque pelo menos alguma prática de gestão visual, mesmo em ambientes caóticos, tira proveito, e gestão visual faz parte do Kanban. Teve uma galera que queria promover a ideia de que Kanban não servia para sistema complexo, só para complicado, e a gente sabe que é muito longe disso, porque o negócio é baseado em analisar a realidade, fazer empirismo. É muito difícil um sistema ficar por muito tempo no caótico, em geral as coisas tendem a voltar. Em sistemas humanos, a gente não tolera viver muito tempo em caos, gera ansiedade. No caos, o que a gente precisa é liderança, às vezes até liderança autocrática mesmo, para poder resolver a parada. Isso é um dos valores do método.

Talvez a raiz desse problema, da gente não enxergar muito qual problema o Kanban não resolve, é porque a gente já vê Kanban de uma forma mais ampla, não como só um método, um conjunto de práticas e princípios que você chega e aplica. Geralmente eu começo minhas aulas já falando disso, porque quando eu pergunto, você conhece Kanban?, a pessoa tende a responder que sim, e quando peço para contar o que ela pratica, ela fala do quadro, dos post-its. Essa confusão entre quadro e método, o que o método tem além do quadro, me fez demorar muito tempo até chegar ao método Kanban de verdade. Essa zona cinzenta entre 'é só prática de gestão visual' e 'o método é aplicável a quase tudo na minha vida' talvez seja muito maior do que a gente imagina.

Em momento de treinamento, a gente tem dois dias para desfazer essa zona cinzenta, e dificilmente as pessoas saem do treinamento sem entender o que está no miolo. Mas tem o outro desafio: quando você está nas trincheiras, resolvendo problemas sem ter esse tempo de treinamento, aí, na minha experiência, o método é menos importante. É a questão do problema. Eu estou com um problema, vamos atacar a coisa, bem teoria das restrições mesmo: qual é a coisa que está doendo mais aqui agora? Eu tenho minha caixinha de ferramentas e vou jogando o que é mais adequado. As pessoas começam a achar que você é super esperta, mas não, é um conjunto de padrões que a gente fica repetindo, e depois de muito tempo você sabe que as coisas se repetem.

Um dos desafios dos últimos anos de agilidade, comparado com o início, é que no início havia resistência à mudança porque era uma coisa nova, as pessoas não conheciam. Hoje em dia, o desafio é que todo mundo conhece, todo mundo acha que sabe, e o inimigo agora é desfazer concepções erradas, às vezes até mais difícil. Hoje em dia o label já entra na frente: isso é Scrum, isso é Kanban, e você tem todo um trabalho de dar a volta, em vez de navegar na zona cinzenta de forma orgânica, resolvendo problemas, os problemas guiando a forma natural. Não me importa se vai ser com o quadro, se tem múltiplas colunas, se tem WIP limit ou não, qual é o problema que você tem hoje?

Eu acho que essa análise de contexto conecta com pensamento sistêmico, que se baseia muito no contexto. Talvez a resposta para como navegar nessa zona cinzenta seja entender o contexto, responder as perguntas que têm que ser respondidas. Pode ser que essas perguntas usem, como proveito, o que a pessoa já conhece de Lean, por exemplo, ou pode ser que toda essa teoria não seja útil, porque as pessoas estão só procurando resolver o estresse que estão passando naquele momento. Resolver esse estresse talvez seja o melhor caminho para não criar resistência.

Se a gente for pensar em resistência, uma das maiores hoje é por causa dessas concepções erradas sobre método, e desses fundamentalismos, 'esse time aqui tem que ser Scrum ou tem que ser Kanban'. Quando você está num contexto desses, o que você faz com essa pergunta? Aqui na Austrália eu enfrentei uma situação dessas: transformações de playbook, vamos adotar o Spotify Model, e no playbook está: os times são Scrum. Você chega como consultor, é assim que vai executar, e é esperado que você faça aquilo. Eu tentei sair daquilo com um time de DevOps, cheguei de cara dizendo que aquilo não ia funcionar, failed completely, porque as pessoas estavam esperando rodar o playbook. A resistência vinha deles mesmos.

Uma frase que eu gosto: você pode usar Kanban para adotar Scrum, e você pode Kanbanizar o seu Scrum. O que eu fiz, em vez de tacar uma sprint, foi visualizar os cartões deles, mas passando a mensagem de que o nosso objetivo era chegar na sprint, para rodar como todos os outros times estavam rodando. Eu tentei me desviar muito cedo do que o playbook estava propondo, e eles rejeitaram, não entenderam por que eu estava fazendo aquilo. Fiquei um tempo de licença e, quando voltei, eles mesmos estavam tentando rodar aquilo, e me chamaram dizendo que agora tinham entendido o que eu estava querendo. O fator tempo é uma coisa que a gente aprende, não adianta trazer a solução pronta, eles têm que vivenciar.

Se você tem carta branca, você vai usar o seu jeito de fazer as coisas. Mas às vezes existe uma agenda, e se você bate de frente com ela, o consultor tende a ser expelido do sistema, e você não tem nem a oportunidade de fazer as mudanças que poderia fazer. Tem que entender se as pessoas estão emocionalmente apegadas ao conceito de Scrum, se você bate nesse conceito, pode não durar muito tempo. Talvez você esteja comprando a briga errada desde o começo.

Estou numa organização que não é mais startup, já tem quase 700 funcionários, um produto SaaS, e é uma empresa naturalmente ágil, onde ninguém mais fala 'ágil' porque as coisas simplesmente acontecem. Uso uma analogia: agilidade para eles é igual água para peixe, o peixe não fala sobre água, ele só nada. O grande erro, por muitos anos, foi achar que o Scrum era bala de prata. Quando comparado a projetos tradicionais, foi uma libertação. Mas a gente começou a perceber as limitações, especialmente em organizações grandes que vieram atrasadas no movimento, com todas aquelas dependências. Em empresas estilo startup, com cultura mais moderna, de liberdade e confiança, continua funcionando bem.

Quando comecei a estudar o método Kanban mais a fundo, entender gestão de fluxo, ele basicamente explicou por que o meu Scrum estava começando a melhorar sem parar, e eu não precisei optar entre uma coisa ou outra. Dois exemplos: eu trabalhava com ciclos de duas semanas, e a gente tentou encurtar para uma. Só esse movimento já trouxe uma redução do lead time, o tempo de entrega. Eu não sabia anotar quando a gente se comprometia com um item e quando esse item foi feito; o que eu sabia era que, se demorasse muito para entregar, deixaria o cliente mais insatisfeito. Hoje, com Kanban, eu tenho muito mais ferramental, consigo fazer um histograma de lead time, entender a distribuição da curva. Mas naturalmente eu já ia fazendo isso, mesmo sem conhecer o método. Quando decidimos fazer tudo em uma semana, percebi que, se entrasse com itens muito grandes, não ia conseguir. A gente começou a diminuir os itens, fazer algo pequeno que por si só já entrega valor, muito na pegada que o Scrum prega. Hoje entendo, baseado em teoria das filas, em gestão de fluxo, que itens menores tendem a fluir melhor no sistema.

Tem coisas específicas que, mesmo praticando Scrum por muitos anos, só consegui identificar depois de estudar Kanban mais profundamente, por exemplo, tipos de demanda e diferença entre serviços. No meu Scrum, era tudo atividade, tudo tarefa, tudo história, tudo no mesmo balde. Às vezes o time só oferece um tipo de serviço, meu time atual, por exemplo, são basicamente user stories, com algum defeito ou suporte on-call, então é simples de entender. Mas quando você pega times de outros domínios, marketing, um escritório de advocacia, são domínios muito ricos para os tipos de serviço que prestam, e às vezes eles têm alguma noção, mas não a clareza que viria de construir um design do sistema deles. Eles tratam tudo num grande bolo, e os resultados são aleatórios.

Teve um caso de advogados que perceberam que não podiam colocar no mesmo cesto uma liminar que tinha que ser cumprida em 48 horas e uma ação trabalhista movida por um ex-funcionário, 'por que eu estava tratando as duas coisas como sendo exatamente a mesma coisa?'. O jeito como resolviam antes era trabalhando 12 horas por dia, só absorvendo e dando vazão à demanda que chegava, distribuída por um gerente, sem entender que um processo teria um comportamento diferente do outro, não quanto ao conteúdo, mas quanto à previsão de tempo. O STATIK, System Thinking Approach to Introduce Kanban, traz bastante a visão de quem é o seu consumidor final, o que você está tentando entregar para ele, e isso já dá um cheirinho do que ele espera receber, e você vê que são tipos de coisa diferentes.

Mas às vezes, dentro do método, a galera foca em método pelo método, por que você quer rodar STATIK? Ah, porque eu quero aplicar o método Kanban. E por que você quer aplicar o método Kanban? Que problema você está tentando resolver? Quando codificam o método e a ferramenta, qualquer coisa vai ter mau uso, não tem jeito. Se você entende por que está rodando aquilo, o que está tentando alcançar, beleza. Mas se você não se dá o trabalho e sai usando sem entender, vai gastar munição nas suas iniciativas de mudança: eu mesma, com advogados, fui tão preciosista no estético, tentando fazer tudo tão perfeito, que o fluxo ficou complexo demais e eles perderam a paciência. Tem que ser um tamanho adequado. Não se apegue ao método.

Teve um caso em que os advogados gostaram muito do processo, quando a gente descobriu os tipos de demanda e o fluxo, saiu um quadro bonitão na parede. Meses depois, voltei para saber como estava, e a gerente começou pedindo desculpas: a gente não está mais usando o quadro que colocamos na parede. Mas ela foi contando como estavam lidando com a sobrecarga: organizaram a caixa de e-mail com tags diferentes para cada tipo de processo, cores diferentes, reuniões periódicas para tratar dos mais prioritários. Eu falei, que lindo, eu mal me importo com o quadro ou com o post-it. A essência do que a gente estava tentando resolver, a previsibilidade de um tipo de demanda ser diferente da de outro, estava resolvida, só que por outras práticas. Em alguns casos, não é a visualização, é ajudá-los a ter um sistema melhor de trabalho. Isso foi um caso típico. Os primeiros casos de Kanban, na verdade, não tinham quadro; era gerenciar o sistema.

Sobre top management: quando eles não estão comprometidos, muitas vezes se sentem fora da onda, 'está todo mundo entrando nessa, eu tenho que entrar também', sem saber muito bem o que estão fazendo. A correlação geral é que, em grandes empresas, a dor da perda está longe do bolso deles: podem cometer erros, rodar playbook, gastar muito dinheiro com consultoria, e isso não os afeta diretamente. Quando a gente fala de sucesso em adoção, em evolução, em resultado, o fator que mais se correlaciona, na minha experiência, não é método, é liderança. Com um líder com os valores corretos, do lado de um consultor com ideias legais, a magia acontece. Líder ruim, meu amigo, muda, porque não tem jeito, não tem milagre. O conjunto de valores dele é outro, às vezes é política, às vezes crescimento individual, não tem remédio contra isso. Identifica esse tipo de liderança e cai fora, não perca tempo, porque não vai conseguir evoluir.

O Kanban traz a filosofia de 'comece de onde você está', e é interessante, porque você consegue percorrer, em geral, um caminho muito mais suave. A gente tem uma expressão para isso, em português: ele vai comendo pelas beiradas, e você vai avançando de uma maneira que talvez outro método quebraria logo no começo. Mas a realidade é que, à medida que você vai alcançando os níveis mais altos, se a motivação lá não estiver correta, se for insegurança, autopreservação, não adianta, não tem Kanban, não tem nada. Se não for desde o CEO, não vai funcionar. Uma analogia que casa muito bem com 'comendo pelas beiradas' é bater a cabeça no teto: você está restrito ao nível de consciência da sua liderança, é uma frase do Frederic Laloux, de Reinventando as Organizações: o nível de consciência da organização está limitado ao nível de consciência do líder. Comendo pelas beiradas, você também consegue perceber se está batendo a cabeça no teto, se o teto está muito baixo. Talvez não valha a pena insistir. Você consegue continuar comendo pelas beiradas, mas às vezes não vai chegar no que você quer da melhoria, porque o nível superior vai cascatear os valores dele.

Um exemplo comum é a otimização local, vou otimizar a minha área, porque a empresa não tem uma cultura de otimização sistêmica. É muito difícil quebrar essa rocha. Mas quando a mágica acontece, quando a pessoa no nível mais alto consegue entender, é bem legal, tem muitas histórias assim, e provavelmente é a realização do consultor, ou do próprio líder, de ter tido a oportunidade de fazer essa mudança.