Caro Daniel,
Obrigado por sua postagem! Sua pergunta é bem interessante e reflete uma dúvida bem comum para usuários de um sistema "puxado" de trabalho Kanban.
Em relação as suas dúvidas, de fato uma tarefa bloqueada entra sim na contabilidade do limite WIP de uma Etapa do sistema de trabalho Kanban.
Por outro lado, respondendo a sua consideração seguinte, faz todo o sentido sim tratarmos bloqueios com a maior brevidade possível e só puxarmos uma nova tarefa, depois que o bloqueio da anterior tiver sido removido.
Um detalhe importante é que para tratar um bloqueio com a maior brevidade possível pode ocorrer de mobilizarmos mais pessoas da equipe para ajudar, e enquanto isso estas pessoas que estão ajudando a removar o bloqueio não puxam mais trabalhos. E também temos que ter o hábito de zerar nosso quadro kanban a cada ciclo curto "sprint" e trabalhar os bloqueios se possível como itens que poderiam ser refinados para trabalho no ciclo seguinte "sprint". De tal forma, a não usarmos uma coluna de bloqueios como um estacionamento de ineficiências do nosso sistema.
Além disso, uma consequência deste aumento de complexidade "bloqueio" para entregar uma tarefa nos traz, é que podemos gerar outros gargalos em outras Etapas anteriores e posteriores ao ponto/SubEtapa, onde o bloqueio se iniciou e com isso desbalancearmos nossa vazão de entregas e capacidade de puxada inicial de trabalhos como um todo.
Agora continuando a resposta, normalmente temos que tomar um cuidado especial quando puxamos tarefas que tem dependência externa. Por exemplo, considerando esta questão da reunião de um terceiro, seria uma boa prática para "não ficarmos ociosos" esperando uma ação externa fora do nosso sistema de trabalho que não controlamos, quando refinamos logo no início a tarefa que envolve dependências externas termos o seu critério de "done" considerarmos apenas o que podemos fazer, ou seja, neste caso, até o momento de darmos os inputs de informações e alinharmos objetivo e resultado esperado da reunião com o terceiro.
Assim, ela até o momento pré-reunião será considerada concluída sem travar a possibilidade de puxarmos uma outra tarefa até a referida reunião ocorrer.
E aqui a grande dica seria alimentarmos o backlog com tarefas associadas aos resultados esperados desta reunião do terceiro, para só priorizarmos a continuidade das mesmas, sem gerar ociosidade em nosso sistema, quando tivermos os resultados entregues pelos terceiros.
Com isto, isolamos esta dependência do nosso fluxo de trabalho, embora possamos em alguns momentos colocar uma tarefa com um leadtime bem rápido para fazermos um "follow-up" com o terceiro e podermos ficar atualizados quando ao andamento da mesma, e depois podermos fazer o refinamento das tarefas associadas a entrega do terceiro que estarão em nosso backlog.
Por fim, sobre o limite do WIP podemos flexibilizar este limite sim, para tratarmos as diversas situações de aumento da variabilidade e necessidade de adaptabilidade para executarmos tarefas, mas temos que tomar cuidado para isto não virar uma regra, senão perdermos as nossas referências de avaliação da eficiência do nosso sistema de trabalho como um todo, o que seria crítico para quando precisarmos avaliar melhorias ncessidades de melhorias no mesmo.
Bons estudos!
