Seu fluxo possui muitos bloqueios? Seu time / squad começa a fazer algo e logo em seguida o item já está bloqueado? Vamos ver como o Agrupamento de Bloqueadores (Blocker Clustering) pode te ajudar.
Bloqueios
Inicialmente, vamos definir o que é um bloqueio. Podemos entendê-lo como a impossibilidade de executar alguma tarefa devido à indisponibilidade de pessoa ou recurso essencial para o andamento do item. O famoso está faltando algo ou alguém aqui.
Em um fluxo ideal não deveria haver bloqueios. A entrada dos itens no fluxo deve ser planejadas para evitar a descoberta tardia de necessidade essencial, mas a vida não é um morango. Problemas acontecem e temos que tratá-los.
Achando a causa do bloqueio
Aqui há um trabalho de análise que é muito importante. Por que os bloqueios acontecem? Nem sempre a causa está na superfície do problema. É sempre bom chegar à causa raiz.
Vou dar um exemplo. Imagine que determinado item não pode ser entregue porque faltou a assinatura de um contrato com o provedor do serviço de computação na nuvem (cloud computing). Em uma primeira análise poderíamos pensar que assinar esse contrato resolveria logo o problema. Entretanto, ao olhar para o passado vemos que isso aconteceu várias vezes.
A causa do problema não é a assinatura daquele contrato específico, mas sim a lentidão na aconselhar de contratos em geral. Daqui podemos fazer questionamentos. Será que estamos pedindo essas assinaturas muito em cima do momento de lançamento? Ou os responsáveis pelas assinaturas estão sobrecarregados? Ou o processo de assinatura está excessivamente longo? É importante achar a causa real do problema, pois isso nos ajudará mais tarde. Dá uma olhada no artigo Resolvendo a origem do problema com a Retrospectiva da Causa Raiz para uma dinâmica de como chegar à causa raiz do problema.
Agrupamentos de bloqueadores comuns
Abaixo coloco uma lista do que comumente pode agrupar bloqueios de itens no fluxo de trabalho. Importante dizer que essa não é uma lista exaustiva. Podem existir outros que não estão aqui listados.
Aqui estão alguns exemplos de agrupamentos de bloqueios (Blocker Clustering) comuns em Kanban:
1. Dependências Externas
Acontece quando a execução do item de trabalho depende de uma pessoa externa ao time / squad que é responsável pelo item. É uma das maiores causas de perda de performance (aumento do lead time). Imagine que um determinado item tenha uma prioridade altíssima para o seu time. Tipo vida ou morte. Só que para o time de quem vocês dependem ele é o item número 327/2024. Mais um no meio de pelo menos 327 outros só no ano corrente. Vai ficar lá esperando alguém ter disponibilidade. Tratamos esse assunto no artigo Briga – Resolvendo as dependências externas ao time.
2. Ambiguidade ou falta de informação
Todos entenderam? Todos já sabem o que fazer? Siiim! Entretanto, quando começa, começamos a fazer perguntas e mais perguntas sobre o item. Como diz o meme: “é raro, mas acontece muito.”
Podem ser hipóteses (requisitos) mal definidas ou ambíguas ou falta de detalhamento. Uma causa comum, mas bastante ignorada é a especificação prematura do item. Você especifica em janeiro, todo mundo entende, mas o item só inicia em julho. Ninguém mais lembra.
3. Mudanças de prioridade
A semana ou dia começa e o time já planejou tudo o que fará. Entretanto, como diz Mike Tyson: “Todo mundo tem um plano até tomar o primeiro soco na cara”. Infelizmente não conseguimos prever o futuro e as coisas podem mudar. A chegada de um expedite, uma mudança na estratégia ou um comprometimento prematuro de um item com baixa prioridade. As mudanças podem acontecer e o item ficar bloqueado porque não há pessoas no time disponíveis para atendê-lo.
4. Falta de autorização
Há empresas que têm controle. Há empresas que têm o controle do controle do controle. Conseguir algo é quase impossível e a cada passo é necessária alguma autorização de acesso, falta de autoridade para assinar algo, políticas restritivas, burocracia excessiva etc.
Uma vez estive em uma empresa que possuía tantas camadas de autorização que em 21 dias eles só conseguiram fazer a alteração de um banner na página principal. O time ficou extasiado com o fato porque nunca haviam conseguido fazer nada tão rápido. Você pensou, eu pensei, 21 dias para alterar um banner não deveria ser comemorado e sim avaliado. Por que cargas d’água estamos demorando tanto para fazer coisas triviais? Problemas técnicos? Necessidade tecnológica? Falta de conhecimento? Não. Falta de autorização. Simples assim.
5. Aprovações ou Revisões Pendentes
Esse costuma ser um filho da dependência externa e da falta de autorização. O seu time / squad já fez tudo, porém para disponibilizar é necessária a aprovação de um gestor, cliente ou uma pessoa de aprovação. Não falta mais nada, só o OK dessa pessoa que está fazendo outras coisas. Será que precisa mesmo? O que pode ser feito para resolver essa aprovação.
Também acontecem através da falta de alinhamento entre os stakeholders. Acontece quando seu time tem que estar junto com outras pessoas, porém não alinharam corretamente e alguém não está presente.
6. Problemas Técnicos
A coisa começou, porém, deu um erro em alguma ferramenta, um computador quebrou, um servidor “subiu no telhado”, uma esteira parou. Problemas técnicos acontecem e quando acontecem eles param o andamento de um item.
7. Falta de Qualidade
Imagina que o seu time está construindo um item. Ele já passou pelas etapas de Análise, Construção, Testes e Qualidade e Homologação do Cliente. Na etapa de entrega alguém descobriu um problema e ele está impedindo a entrega do item. Marque ele como bloqueado, pois não pode ser entregue e mova todas as pessoas necessárias para remover esse bloqueio.
8. Incompatibilidade Estratégica.
O seu time desenvolveu um item relacionado à campanha de marketing que a empresa fará no Natal. Todavia, hoje é dia 1º de outubro. Não há nada técnico que impeça esse lançamento, porém não é estratégico lançar uma campanha de marketing para o Natal em outubro. Com base nisso, o Product Owner opta por não fazer o lançamento agora. O item não pode ser entregue. Esse é um caso, mas há outros em que o item não pode continuar porque a entrega dele no momento não é estrategicamente interessante.
9. Pessoas insuficientes
Planejamos que o nosso time com 10 pessoas faria 8 itens esta semana. Porém esquecemos de ver que 5 delas sairiam de férias nesta semana. Agora não temos como continuar com os 8 itens. Vamos ter que escolher em qual trabalhar e manter os itens que não trabalharemos como bloqueados. O mesmo pode ocorrer quando há saída de pessoas do time. Dica: Sempre entre no bolão da Mega-Sena. Vai que a galera ganha e o time inteiro pede demissão e só sobra você.
Aqui vale uma coisa importante. Ter poucas pessoas não pode ser a causa de nos comprometermos com mais itens do que temos capacidade. Isso é falta de profissionalismo e prometer mais do que o seu time consegue cumprir. Limite o WIP e respeite a capacidade.
10. Recursos insuficientes
Outro motivo que pode bloquear um item é o fato de não termos uma necessidade técnica ou financeira. Para podermos dar continuidade nesse item precisamos de R$100.000,00, porém só temos R$1,00 disponível. Logo esse item não poderá continuar. Outro exemplo já foi dado na seção anterior quando falamos da necessidade de um serviço de computação na nuvem.
11. Mudanças Ambientais
A mudança de um fator ambiental pode bloquear a entrega de um item. Esse fator pode vir de uma ação da natureza, ato de um governo ou mudança de comportamento dos clientes. Você não tem controle sobre ele, seu gerente não tem controle sobre ele e nem o presidente da empresa tem controle sobre ele, mas ele impacta o seu produto ou serviço. Um exemplo é a baixa da cotação do barril de petróleo e a inviabilização da exploração do pré-sal. Outro exemplo é a alta do dólar e a incapacidade de aumentar a quantidade de voos de uma empresa aérea.
Analisando os bloqueadores com o Gráfico de Pareto
Uma vez que você já tenha agrupamentos de bloqueadores e comece a contabilizá-los, você pode utilizar gráficos para te ajudar. Infelizmente a maioria das ferramentas não é boa com esse tipo de análise. A Businessmap controla bem os bloqueios, mas no geral poucas mantêm esse rastreamento e, portanto, necessitam de trabalho adicional para você mapeá-los. Um Scrum Master pode manter essa informação atualizada.
Uma forma interessante de ver essa informação é através do Gráfico de Pareto. Pareto ou a Regra dos 80/20 afirma que 80% dos problemas são causados por 20% das causas.
O time possui os seguintes bloqueadores e a quantidade de bloqueios que foram agrupados nela são:
| Bloqueadores | Quantidade de Itens Bloqueados (Frequência) |
| Dependências Externas | 35 |
| Falta de Informação (Comprometimento Prematuro) | 21 |
| Mudança de Prioridade | 18 |
| Aprovação Pendente | 7 |
| Problemas Técnicos | 5 |
| Falta de Qualidade | 3 |
| Falta de Autorização | 2 |
| Incompatibilidade Estratégica | 1 |
| Recursos Insuficientes | 1 |
| Pessoas Insuficientes | 1 |
Quando ordenamos os itens, pela frequência, podemos também fazer uma conta acumulada do percentual dos itens. Ficamos assim:
| Bloqueadores | Quantidade de Itens Bloqueados (Frequência) | Percentual Acumulado (%) |
| Dependências Externas | 35 | 37,2 |
| Falta de Informação (Comprometimento Prematuro) | 21 | 59,6 |
| Mudança de Prioridade | 18 | 78,7 |
| Aprovação Pendente | 7 | 86,2 |
| Problemas Técnicos | 5 | 91,5 |
| Falta de Qualidade | 3 | 94,7 |
| Falta de Autorização | 2 | 96,8 |
| Incompatibilidade Estratégica | 1 | 97,9 |
| Recursos Insuficientes | 1 | 98,9 |
| Pessoas Insuficientes | 1 | 100,0 |
O Gráfico de Pareto então pode ser traçado
Os bloqueadores estão no Eixo X, ordenados pela frequência. O Eixo Y do lado esquerdo é a frequência do item. O Eixo Y do lado direito é o percentual acumulado. Aplicando a regra de Pareto, temos que ver onde estão 80% dos problemas. No caso, são os bloqueadores Dependências Externas (35 itens bloqueados), Falta de Informação (21 itens bloqueados e Mudança de Prioridade (18 itens bloqueados). Resolver esses três bloqueadores resolverá 80% dos problemas.
Eu sei, dá 80/30, mas dá para pegar o espírito da coisa.
Analisando o agrupamento de bloqueadores ao longo do tempo.
O Gráfico de Pareto é interessante, mas ele não te dá uma visão de como os bloqueadores atuaram no tempo. No artigo Blip! Surgiu um gargalo! Como o Workflow Heatmap te ajuda a não tomar decisões precipitadas, apresentei o Workflow Heatmap (Mapa de Calor do Fluxo de Trabalho). Você pode fazer o Mapa de Calor de Bloqueadores (Blockers Heatmap).
Aqui no Eixo Y temos o agrupamento de bloqueadores e no Eixo X os meses do ano. Quanto mais verde, menor a quantidade de bloqueios (frequência) e quanto mais vermelho, maior a frequência.
Conclusão
Espero que esse artigo seja útil. Agrupar os bloqueadores é muito importante para você fazer uma Retrospectiva eficaz. A discussão sobre eles ajuda muito no aumento da performance e bem-estar do time.
Nos vemos em breve.
Rivedes.
