Obrigado por trazer seu ponto de vista! Eu concordo com a base do que você disse:

o board não tem fim e gargalos existem porque somos pessoas, não máquinas.

O ponto do post não é vender a ideia de que “vai sobrar tempo” ou que alguém vai ficar “de braços cruzados”. A correria vai existir mesmo. O que eu defendo é outra coisa:

• Sobrecarga crônica / dependência de uma pessoa não deveria ser “normal” — é um risco operacional (e humano) que cobra juros: aumenta fila, piora previsibilidade, torna qualquer ausência uma emergência.
• Reduzir dependência não “zera demanda”. Ela só muda o jogo de heroísmo para capacidade do sistema: mais gente consegue tocar, revisar, destravar e dar continuidade.

Na prática, isso não acontece “por milagre” nem com um sprint de boa vontade. A forma que eu vi funcionar (inclusive em times que eu liderei) é tratar como processo contínuo e incremental, por exemplo:

• Reservar capacidade explícita (mesmo que pequena) para “enabling work” (pairing, documentação mínima, automações, repasse de contexto).
• Usar itens de baixa prioridade + alta dependência como “campo de treino” (ensina sem colocar produção em risco).
• Quando surgir um item de alta prioridade + alta dependência, a pergunta vira: “o que eu faço agora para amanhã isso não depender só de mim?” (nem que seja uma sessão curta de transferência de contexto).

E sobre maturidade: eu citei isso porque pesquisas tipo as métricas do Google/DORA olham exatamente para fluxo e estabilidade (lead time, frequência de deploy, taxa de falha, tempo de recuperação etc.), e dependência costuma ser um freio invisível nessas dimensões.

Se no dia a dia parece “fora da realidade”, eu tendo a interpretar como um sinal de que o time está num modo muito reativo (o que é bem comum). A proposta do post é justamente um caminho pra sair disso, trazendo mais sustentabilidade e previsibilidade ao longo do tempo.