No artigo sobre bloqueios, falei brevemente sobre o Blocker Clustering (agrupamento de bloqueios), mas gostaria de expandir o tema, pois é importante. Afinal, no dia a dia, eles acontecem; quanto mais longevo for o time ou quanto mais tempo levar o projeto, acaba sendo comum que haja bloqueios. Analisar um a um é custoso e podemos ficar meses, quiçá anos, apagando pequenos incêndios. O agrupamento de bloqueadores não é apenas uma forma de reunir problemas iguais. No Kanban, trata-se de uma cadência (reunião para aprimorar o fluxo de trabalho) dos times e organizações que atingiram o Nível de Maturidade 2. Neste artigo eu passo minha experiência sobre como conduzir essa técnica. Espero que te ajude.
Por que agrupar os bloqueios
O Blocker Clustering não é apenas uma técnica para “juntar problemas parecidos”. Ele existe para melhorar o fluxo de trabalho de ponta a ponta, reduzir desperdícios e aumentar a previsibilidade. No Kanban, os bloqueios são sinais de que o sistema está perdendo esforço, dinheiro e tempo e, por isso, tratá-los um a um não muda o todo. Quando agrupamos, enxergamos padrões que atravessam o upstream (decisão, descoberta e seleção do trabalho) e o downstream (entrega, desenvolvimento e operação). Essa visão sistêmica permite que o time ataque causas raiz que, muitas vezes, não estão em uma área isolada, mas sim na maneira como o fluxo inteiro está configurado.
Agrupamento de Bloqueios e o Kanban Maturity Model
Organizações que já operam no Nível de Maturidade 2 usam o Blocker Clustering (Agrupamento de Bloqueios) como uma cadência formal, justamente porque entendem que a previsibilidade nasce do domínio do fluxo. Ao resolver sistematicamente grupos recorrentes de bloqueios, o time reduz a variabilidade, aumenta a capacidade utilizável e cria um ambiente em que o Customer Lead Time se torna totalmente gerenciável. Essa técnica é, portanto, um passo essencial para o movimento de transição do Nível de Maturidade 2 (ML2) para o ML3, em que as decisões são tomadas com base em dados reais do sistema, e não em percepções individuais ou em achismos.
Não faça análises prematuras
Daqui em diante, eu gostaria de dar algumas dicas sobre o Agrupamento de Bloqueios. A primeira dela está relacionada à análise.
Não tente criar agrupamentos se você tiver poucos dados, pois isso será uma análise muito prematura do que está atrapalhando seu time. Uma vez trabalhei em um time que sofria com muitas dependências externas e, consequentemente, com muitos, muitos bloqueios. Quando mudei de time, estava decidido que as dependências externas não me atrapalhariam mais. Fiz todo o mapeamento delas e, confesso, forcei o time a declarar que qualquer bloqueio seria tratado como prioridade absoluta.
Só que havia um pequenino detalhe: esse time tinha apenas uma dependência externa e esta quase não o incomodava. Quando chegou o primeiro bloqueio, que foi a aplicação de algumas instruções de banco de dados (script) com uma instrução para apagar uma tabela (drop table…), fiz um escarcéu. Uma análise super detalhada do problema, do impacto que causaria no prazo, da insatisfação do time e do cliente, etc. Fui com tudo para cima do DBA, que olhou para o fruto do meu trabalho fervoroso e falou: “Beleza”. Rodou as instruções e, em 2 segundos, resolveu toda a minha gloriosa análise sobre o bloqueio. Quantas vezes esse problema voltou a acontecer? Zero!
Não existe um número exato, mas, como um número mágico, aguarde ter mais de 10 bloqueios antes de começar análises para resolver problemas sistêmicos. Isso evita que você invista em um dos principais causadores de desperdício em projetos: a otimização prematura da solução.
Anote antes de resolver
Nossa tendência natural é: dado que há um bloqueio, vamos correr para resolver na base do “custe o que custar”. Não faça isso; registre, caso contrário, você não terá um histórico e não tratará os problemas sistematicamente, apenas “apagará incêndios” pontuais. Informações fundamentais:
- Causa
- Consequência
- Responsável pela eliminação do bloqueio
- Quando começou
- Quando terminou
Por exemplo:
Bloqueio #001
Causa: os desenvolvedores não têm acesso para executar comandos de exclusão de tabelas no banco de dados.
Consequência: Não conseguimos entregar o incremento no software no prazo combinado com o cliente.
Responsável: Avelino F. Gomes Filho (Scrum Master)
Início: 09/05/2025
Fim: 17/05/2025
Se o seu software de gestão de fluxo (Jira, Taiga, ALM) não suportar esse tipo de análise, utilize uma planilha. Além disso, outra dica é integrar esse momento de registro à reunião diária para garantir que nada seja perdido.
Defina os temas com o time
Uma vez que você já tiver alguns bloqueios registrados, chame o time para uma reunião específica para definir os temas de bloqueio. Isso dará um senso de participação e engajará os demais membros no registro dessas informações. Nessa reunião, traga prontas as informações relevantes, além do registro do bloqueio:
- Frequência do bloqueio: quantas vezes ele ocorreu.
- Duração: fim – início do bloqueio
- Impacto no tempo total do item: se o item tem um customer lead time de 10 dias e ficou bloqueado por 4 dias, o impacto foi de 40%.
Essas informações facilitam o debate. Se quiser, você pode ter um quadro assim para facilitar a discussão:
O objetivo
O objetivo dessa reunião é sair dela com grupos de bloqueio. Se necessário, abstraia um pouco para que o grupo abranja vários itens. Por exemplo, imagine que fizemos a reunião e o time concluiu que há dois problemas: o servidor de produção está indisponível e o certificado digital dele está com problema. Entretanto, cada tema possui um bloqueio apenas. Então, podemos ajustar o agrupamento abstraindo da situação: problemas de infraestrutura de produção. Agora, esse grupo possui 2 itens.
Um quadro assim, no encerramento, é uma boa saída dessa reunião:
Caso queira esse quadro, ele está disponível no nosso Mural.
Políticas Explícitas
Uma vez que vocês já têm os grupos, criem poucas políticas para facilitar a classificação. Por exemplo:
- Caso alguém não tenha permissão para executar alguma ação, classifique o bloqueio no grupo “Falta de acesso”.
- Se o bloqueio estiver relacionado a alguma anormalidade no servidor de produção, classifique no grupo ‘problemas de infraestrutura de produção’.
- Caso algum membro seja cooptado para fazer algo fora do time e isso o impeça de trabalhar no nosso produto, classifique-o como: Jogador sequestrado 😁.
Faça reuniões de acompanhamento
Blocker Clustering não serve apenas para criar grupos. Ela é uma reunião para resolver esses bloqueios. Tenha uma frequência adequada quanto à quantidade e à chegada de novos bloqueios. Pode ser semanal, quinzenal ou até mesmo mensal. Algumas dicas adicionais são:
Não fique classificando durante as reuniões
Não use as reuniões de blocker clustering nem as retrospectivas para agrupamento. Ninguém tem paciência para ficar fazendo isso o tempo todo. As políticas explícitas servem justamente para simplificar esse processo. Se possível, um assistente de IA poderia servir como classificador. Informe as políticas de classificação e o histórico e deixe o assistente trabalhar agrupando os novos bloqueios.
Envolva os desbloqueadores
Se possível (infelizmente quase sempre não é), envolva as dependências externas que estão causando o bloqueio. Isso facilita muito a remoção deles. Se não conseguir, escolha alguém que faça essas negociações com as pessoas que têm poder para remover os bloqueios.
Apresente as métricas
Frequência, duração total, impacto no lead time e no sistema. É um momento rápido, só para nivelar os dados e “colocar todos na mesma página”.
Confirme ou ajuste dos grupos existentes
Não é para classificar. É apenas para verificar se algum grupo perdeu relevância ou se surgiu um novo tema. Aproveite para escolher os grupos prioritários.
Parta para a solução
O Blocker clustering e a retrospectiva não devem ser apenas para agrupar os bloqueios. Se nada for feito, elas se tornam inócuas.
- Identifique os piores grupos de bloqueio; dê uma olhada no artigo: Tratando Bloqueio no Quadro Kanban. Lá eu escrevi sobre como visualizar e medir os bloqueios.
- Defina responsáveis, pois quando todos são responsáveis, ninguém será responsável.
- Acompanhe a solução dos bloqueios periodicamente
- Verifique se a solução está nas causas raiz (sistema) ou apenas em um bloqueio pontual. Sempre que possível, deixe claro que o objetivo é resolver a causa raiz.
- Quando resolver, não se esqueça de registrar a solução.
Conclusão
No fim das contas, o Blocker Clustering é muito mais do que uma técnica: é um compromisso com a construção de sistemas de trabalho mais saudáveis, previsíveis e justos. Bloqueios não são acidentes; são mensagens que o sistema tenta enviar para avisar de que há um problema. Quando paramos para ouvi-las, agrupá-las e tratá-las, o fluxo acelera, o trabalho fica mais leve e o time ganha capacidade real para cumprir o que promete. Resolver um bloqueio pontual salva o dia; resolver um cluster resolve o sistema. Se você quer evoluir seu time de combate a incêndios (bombeiros) para a melhoria contínua baseada em dados, o Blocker Clustering é uma das práticas mais poderosas para iniciar esse processo. E o melhor: qualquer time pode fazer.
