O Kanban possui um guia de práticas muito interessante, que facilita a gestão do fluxo de uma equipe ou empresa. O nome dele é Kanban Maturity Model (Modelo de Maturidade do Kanban) ou KMM para os íntimos. Ele é um modelo em que dada a forma como o time ou empresa trata seu fluxo e o resultado que obtém do trabalho feito nele, podemos dizer que ele possui determinado nível de maturidade na adoção de Kanban. Em cada nível, é comum que um conjunto de práticas apareçam para auxiliar a gestão. Essas práticas não são obrigatórias, são apenas comumente observáveis.
A maldição dos modelos de maturidade
Até aqui tudo bem, o problema é como as pessoas costumam utilizar modelos de maturidade. Normalmente, elas olham para as práticas, documentos e eventos e fazem uma espécie de checklist. Eu tenho que ter tudo e fazer tudo para ser considerado “maduro”. Então, vale tudo para atingir a tal maturidade — afinal, ninguém quer ser taxado de imaturo.
O problema não é novo
Isso não começa com o KMM. Outros modelos sofreram com o mesmo problema. O CMM (Capability Maturity Model – Modelo de Maturidade de Capacidade) e mais tarde o CMMI (CMM Integration – Integração do CMM) e seu colega brasileiro MPS.Br (Melhoria de Processo de Software Brasileiro) passaram por isso.
A diferença é que no auge desses havia um motivo prático. Empresas só contratavam fábricas de software se elas tivessem um nível X de maturidade em um desses modelos. Aqui no Brasil isso acontecia muito em licitações de empresas públicas. Atualmente, não sei se isso ainda é uma exigência.
Acredito que esse ainda não seja o problema do KMM. Todavia, por que vemos empresas adotando práticas que não agregam em nada e são desnecessárias para ela?
Maturidade pela maturidade
Um pecado que muitos cometem hoje é muito bem descrito pelo episódio do Chaves em que as crianças do seriado querem a “Estrela do Bom Menino”.
Elas mudam de comportamento, forjam falcatruas e se digladiam para ganhar a tal estrela. Logo, o objetivo não é se tornar um bom menino / boa menina e sim ganhar a estrela.
Já contei em algum artigo a história em que eu fui designado para dar a manutenção de um software e me entregaram a documentação dele em um DVD. Em um mundo sem IA, alguém realmente acreditou que eu leria 4,7 GB de documentos.
Certa vez, a empresa queria ir para o nível E do MPS.Br e por isso tudo dentro do software deveria ser documentado, inclusive os métodos get e set das classes Java.
/**
*Obtém o nome da pessoa
*@return Nome da pessoa
*/
public String getNome()
/**
*Informa o nome da pessoa
*@param nome Nome da pessoa
*/
public void setNome(String nome)
Só que nada está tão ruim que não possa piorar. Para fazer isso, como a empresa utilizava outras linguagens de programação além do Java como C#, Python, Cobol e PL/SQL em diferentes bancos de dados, toda a documentação deveria ser escrita em um documento Word e havia um software da IBM que ligava a documentação em Word com o código-fonte e os casos de uso.
Na época, eu perguntei por que fazer tudo aquilo e qual a vantagem que tínhamos. A resposta foi: “é o que o mercado quer”. Toda vez que na resposta tiver um sujeito indeterminado, desconfie.
Não é uma solução
Então, vamos jogar tudo para o alto, acabar com a burocracia e tomar o poder!!! Calma, calabreso. Se tem placa, tem história. As coisas existem por algum motivo. Afinal, quando os autores os criaram nenhum deles estava pensando: “hum, como vou atrapalhar a vida das pessoas” enquanto dava uma risada diabólica. Eles perceberam que havia problemas de qualidade e falta de resultado e pensaram em como as empresas poderiam aperfeiçoar seus métodos de trabalho. Infelizmente, alguns transformaram os modelos em uma cartela de bingo que deve ser preenchida o mais rápido possível.
Uma solução
A adoção das práticas do KMM (ou outros modelos) deve seguir um propósito firme: eu quero melhorar os resultados da minha organização e para isso eu vou aperfeiçoar o nosso fluxo de trabalho para que ele seja mais eficiente, eficaz e com os riscos mais controlados possível. Para isso, posso utilizar práticas, técnicas, papéis e métodos sugeridos pelo KMM quando forem necessárias para o contexto que estou.
Entender o Modelo antes de correr para implantá-lo
Muitas vezes temos um entendimento apenas superficial sobre o modelo e suas práticas e queremos sair aplicando tudo porque parece bom. Adotamos práticas para resolver problemas pontuais como se fossem o objetivo principal do time. Isso não é bom. Em um mundo complexo e por vezes caótico, entender os problemas e conhecer possíveis soluções e aplicá-las no contexto e momento certos é fundamental.
Por exemplo: Você sabe para que serve o Limite de WIP e quando aplicá-lo? Não é simplesmente um número que fica em cima de uma coluna de um quadro. É uma forma de reduzir a quantidade de trabalho em paralelo e aumentar a eficiência do time. Se ele estiver lá só para decoração e as pessoas o ignorarem. Ele tornou-se apenas um quadro decorativo e não presta para nada.
Conclusão
Assim como as crianças do Chaves buscavam a Estrela do Bom Menino, muitas empresas buscam estrelas douradas de maturidade apenas para ter. Esse não é e nunca foi o objetivo. A estrela de bom menino só faz sentido se for acompanhada do comportamento correspondente. A maturidade só faz sentido se a empresa de fato alcança os resultados necessários.
Afinal, modelos de maturidade não são prisões. Cabe a nós escolher: preencher checklists sem alma ou usá-los como trampolim para criar organizações mais eficientes, eficazes e adaptáveis. No fim, o verdadeiro nível de maturidade não está na incrível prática que seu time adotou, mas na transformação palpável que entregamos aos nossos clientes.
Curtiu, da uma olhada no nosso treinamento de:
Team Kanban Practitioner (TKP)
