APRENDER. PRATICAR. EVOLUIR.Identificar a liberdade de ação existente
Uma equipa não pode retirar uma aprovação externa, mas pode melhorar a clareza dos pedidos. O padrão opcional 15% Solutions, desenvolvido por Henri Lipmanowicz e Keith McCandless, convida a procurar ações dentro da autoridade e recursos existentes. O nome não manda reservar 15% do orçamento ou do Sprint. Neste caso, a ação local é testar uma descrição de pedido que reduz esclarecimentos. A dependência externa continua visível e tem tratamento próprio. Pequena iniciativa não é desculpa para ignorar a restrição principal nem autorização para alterar um controlo de outro responsável.
Observar o fluxo sem premiar acumulação
A fila começa com oito itens. Entram sete e terminam quatro durante a semana; sem outras entradas ou saídas, ficam onze. Repetir esse padrão aumenta trabalho acumulado. O cálculo é um balanço simples, não um modelo que prevê automaticamente prazos individuais. Discute por que a gestão recompensa início e não conclusão útil. Observa espera, trabalho bloqueado e efeitos na qualidade antes de escolher uma alteração. Não compares equipas por pontos nem imponhas um limite universal a partir destes números. A experiência deve responder ao problema observado e às condições reais de colaboração.
Antecipar feedback mantendo controlos
Uma verificação de segurança obrigatória ocorre depois de muitas alterações acumuladas. A equipa pode explorar feedback em lotes menores com o responsável do controlo. Regista o que continua obrigatório e o que pode mudar no processo. Mede tempo até detetar incompatibilidades, retrabalho, qualidade e esforço da função envolvida. Aumentar o número de verificações sem capacidade pode apenas deslocar a fila. O Scrum Master facilita colaboração e aprendizagem; não se torna aprovador técnico por organizar a conversa. A decisão final deve incluir o efeito sobre o produto integrado e sobre as equipas que passam a receber pedidos mais frequentes.
Medir o percurso do utilizador
Uma interface reduz o tempo de um passo de seis para quatro minutos, mas obriga o operador a executá-lo três vezes em vez de duas. Neste modelo sem outros passos, o total mantém-se em doze minutos. A melhoria local não reduziu o esforço do percurso. Acrescenta critérios de sucesso e qualidade: uma execução rápida com resultado inválido não cria o benefício esperado. Na Sprint Review, inclui evidência de operadores de turnos diferentes e discute adaptações com stakeholders relevantes. O Product Owner continua accountable pela gestão eficaz do Product Backlog, incluindo trabalho de fiabilidade e operação relacionado com o produto.
Planear com suporte e incerteza visíveis
O suporte conhecido consome capacidade no próximo Sprint. Os Developers devem considerar essa informação ao selecionar trabalho e construir o plano com o Product Owner. Não compenses os dias de suporte reduzindo qualidade ou prometendo trabalho invisível. Se um piloto incluiu só pedidos simples, regista essa limitação antes de propor adoção em pedidos críticos. Define os critérios para continuar, ajustar ou abandonar a experiência, incluindo efeitos indesejados. A ausência de uma conclusão universal não impede uma decisão limitada e reversível. Ajuda a organização a aprender com contexto em vez de transformar um resultado local numa regra definitiva.
Levar uma proposta concreta ao responsável externo
No exercício final, os pedidos mais claros reduzem retrabalho, mas a maior parte do tempo continua numa aprovação externa. Prepara uma conversa com população observada, tempos, objetivo do controlo e alternativas que o preservam. Propõe um ensaio limitado, com participantes, observação e revisão acordados. O responsável externo deve compreender a mudança e a sua autoridade; o grupo precisa de saber que decisões permanecem abertas. Não uses a palavra agilidade para dispensar controlo nem para recusar qualquer adaptação. O resultado procurado é uma experiência que torne o produto mais útil e o fluxo mais compreensível.
# Synthetic arithmetic; no lead-time or causal guarantee
queue_after = 8 + 7 - 4 # 11 items
journey_before = 2 * 6 # 12 minutes
journey_after = 3 * 4 # 12 minutesFila: 8 + 7 − 4 = 11 itens. Percurso: 2 × 6 = 3 × 4 = 12 minutos. Os modelos mostram acumulação e limites de uma melhoria local.
Armadilhas comuns
Confundir iniciativa com autoridade; medir só um passo; extrapolar pedidos simples para críticos; ocultar suporte; impor o piloto como processo universal.
Tópicos relacionados: Facilitar participação e decisões difíceis · Coaching, mentoring, ensino e liderança · Organização, incentivos e barreiras sistémicas
Melhora o sistema através de experiências delimitadas, com autoridade, população e resultado explícitos. A decisão deve considerar o produto completo.
Referência: 15% Solutions · PSM II; Scrum Guide November 2020; no public numbered exam revision