Ep. 19 - STATIK - Como começar com Kanban

O episódio recebe Bernardo José e Romeu Matos, dois agilistas que discutem o STATIK (System Thinking Approach to Introduce Kanban) há anos, boa parte desse tempo em Portugal, para falar sobre como começar a usar o método Kanban na prática.

A pergunta de abertura é: que problema o STATIK tenta resolver? A resposta inicial é que ele dá um caminho concreto para começar a usar Kanban como método, proposto por David Anderson, mas seu alcance é maior do que isso: ele ajuda a levar pensamento sistêmico e discussão sobre fluxo para mais pessoas, criando um vocabulário comum sobre cadeia de valor e o que está sendo entregue. É comum, depois de qualquer treinamento ou episódio sobre um tema novo, surgir a pergunta 'beleza, mas por onde eu começo?', o STATIK existe para responder isso.

Os oito passos do STATIK são então percorridos, de memória, pelos dois convidados:

Passo 1, Identificar o propósito: entender qual é a visão do sistema e o que significa sucesso, sempre a partir do propósito do consumidor que usa aquele serviço, não de um propósito abstrato. Existe até um 'passo zero' implícito, que é confirmar que aquilo realmente é um serviço.

Passo 2, Identificar as insatisfações: tanto internas (gargalos, problemas já conhecidos por quem trabalha no sistema) quanto externas (dos stakeholders e consumidores). É citada a ideia de um amigo em Portugal, que usa a cozinha como analogia para o STATIK: as insatisfações de quem está cozinhando, a equipe interna, são tão importantes quanto as de quem está do lado de fora, porque influenciam diretamente o serviço entregue. Também é citada a frase de Peter Senge, de que 'se você empurra um sistema, o sistema te empurra de volta'. As insatisfações são o gancho que permite que as próprias pessoas do sistema puxem a melhoria, em vez de ela ser imposta de fora.

Passo 3, Analisar a demanda: olhar para quantos pedidos ou requisições chegam ao sistema hoje e entender a natureza deles, de onde vêm, o que têm em comum, o que os diferencia. Boas perguntas informais para esse passo são simplesmente 'que tipo de trabalho é esse?' e 'de onde ele veio?', e, se um item não estiver alinhado com o propósito identificado no passo 1, descartá-lo é uma opção legítima.

Passo 4, Analisar a capacidade: entender quanto o sistema realmente consegue entregar, olhando métricas de fluxo como lead time e throughput. Perguntas simples ajudam aqui: quantas demandas você tem agora na mão? Quantas você terminou na última semana? Um exemplo contado é o de um time que estimava entregar cerca de 30 itens por semana, mas o passo anterior já havia revelado que chegavam ao menos 50, ou seja, 20 itens por semana ficavam represados. A comparação usada é com uma padaria: se o trabalho fosse fisicamente visível como farinha e pão, a pergunta sobre capacidade seria simplesmente 'qual o tamanho do forno?'. Como o trabalho do conhecimento é invisível, é preciso perguntar diretamente às pessoas para enxergar isso.

Passo 5, Entender o workflow: olhar como o trabalho realmente flui pelo sistema, descrito aqui como um rio, e como o conhecimento é criado e aprendido ao longo do tempo, evitando se prender a um mapeamento formal e desatualizado (como um diagrama BPMN antigo) e indo a campo para ver o que realmente acontece no dia a dia, prestando atenção especial às filas.

Passo 6, Identificar classes de serviço: os convidados optam por pular esse passo em detalhe, sugerindo que ele merece um episódio próprio.

Passo 7, Modelar o sistema Kanban: definir políticas, métricas e limites de trabalho em progresso (WIP limits), entrando em detalhes como o que significa a política de uma coluna de qualidade ou de deploy, e quais métricas e limites de fato serão usados.

Passo 8, Rollout: colocar o sistema Kanban em prática, sem esquecer que ele depende de loops de feedback contínuos. O STATIK não é um processo linear que se cumpre uma vez e termina, mas algo revisitado com frequência. É citada a ideia de 'reverse STATIK', do Mike Burrows, em que se parte do Kanban que já existe e se percorre os passos ao contrário, já que a ordem fixa dos oito passos pode soar como um método em cascata, o que não é a intenção.

A partir daqui a conversa muda de tom: ter esses passos de cor não significa que a vida real funcione de forma tão linear, o dia a dia raramente segue os oito passos em sequência perfeita. Bernardo conta que seu primeiro contato com o STATIK veio de uma palestra de Rafael Jaguar no Brasil, e se aprofundou ao se mudar para Portugal, onde um grupo de agile coaches já discutia como introduzir Kanban num ambiente dominado por Scrum. Isso levou o grupo a perceber que os passos do STATIK tinham valor mesmo em times que usavam Scrum, e a brincar com a ideia de renomear o método de STATIK para 'STATIF', trocando o K de Kanban por um F de flow (fluxo), já que a essência era mais sobre pensamento sistêmico do que sobre um método específico.

Romeu conta que seu primeiro contato foi bem mais informal: um colega comentou que tinha acabado de 'rodar um STATIK' durante um café com o designer do time. Mais tarde, ao trabalhar com Bernardo, ele passou a participar de sessões formais de STATIK que podiam durar de quatro a oito horas, às vezes divididas em vários dias.

Uma reflexão importante levantada é que, com o tempo, o grupo percebeu que rodar sessões e workshops isolados não era o mais eficaz, o que realmente funciona é ter cadência e ritmo contínuos, dando tempo para as pessoas assimilarem os conceitos, em vez de tratar o número de sessões de STATIK rodadas como um critério de sucesso em si. Também é discutido o risco de tratar o método como uma receita de bolo a ser seguida à risca: a recomendação é focar nas dores reais das pessoas e resolver problemas concretos, sem necessariamente nomear o método usado, e até incorporar perguntas do STATIK no dia a dia (por exemplo, durante a daily) em vez de reservar sessões dedicadas.

Sobre a efetividade real do método: o STATIK não resolve problemas em um ou dois dias, pelo contrário, ele serve para mostrar que existem problemas, funcionando como impulsionador de discussões maiores sobre propósito, capacidade e métricas de fluxo, mais do que como uma solução pronta.

A conversa então passa para erros e aprendizados práticos de quem já aplicou o método. Um erro citado é pensar o STATIK apenas no nível de time, sem considerar o fluxo entre times, um ponto conectado ao livro 'Repensando Agilidade', de Klaus Wuestefeld, e ao episódio anterior sobre Flight Levels. Outro erro é não ter todas as pessoas relevantes na sala durante as sessões, por exemplo, rodar o processo sem a presença de alguém de produto, o que esvazia a discussão sobre insatisfações externas. Um terceiro relato é o de aplicar o STATIK com apenas uma pessoa de um serviço que envolvia vinte, produzindo rapidamente um sistema que, por não ter sido construído com a participação de quem de fato usaria, nunca chegou a ser adotado.

O relato final de erro é sobre a 'busca pelo sistema perfeito': um sistema Kanban desenhado nos mínimos detalhes com pessoas que não conheciam nada do método, mas que na prática nunca funcionou como planejado. Meses depois, ao buscar feedback, foi revelado que o quadro combinado havia sido abandonado, mas as pessoas, longe de terem regredido, tinham evoluído sozinhas um sistema próprio usando marcadores e categorias dentro da própria caixa de e-mail, categorizando o tipo e a urgência de cada demanda. A conclusão tirada disso é que o sistema perfeito não nasce de um plano desenhado antecipadamente, ele emerge da prática real, da cadência e da melhoria contínua, e tentar encontrá-lo de uma vez, numa ou duas sessões, é uma ilusão.

Para fechar, cada participante deixa uma mensagem. Romeu destaca que o modelo mental de quem está conduzindo uma transformação não pode ficar isolado, ele precisa ser compartilhado, discutido e reconstruído junto com outras pessoas, criando referências e mapas mentais mais atuais em conjunto. Bernardo reforça a importância de não seguir o método 'ao pé da letra': os passos ajudam a pensar sobre o sistema, mas cada contexto exige uma leitura própria, e nada deve ser tratado como regra fixa. O apresentador encerra com a sugestão de que, entre o que está no livro ou no plano mental e o que realmente acontece no dia a dia, a prioridade deve sempre ser a realidade.