Mudanças de prioridade destroem mais times do que falta de metodologia

Quando foi a última vez que você viu um time de produto funcionando sem correria, sem mudança de prioridade no meio do sprint e sem aquela sensação de que todo mundo está sempre apagando incêndio? Se você não consegue lembrar, o problema não está no seu PM, no seu processo ágil ou na falta de uma ferramenta mais organizada.

A questão é que a gente passou anos tentando resolver na ponta um problema que nasce lá em cima. Enquanto ficamos discutindo se scrum é melhor que kanban, se o PM deveria escrever histórias de usuário ou se o tech lead precisa ser mais "ágil", a alta liderança continua tomando decisões que desmoronam qualquer tentativa de organização que os times conseguem construir. E aí todo mundo fica se perguntando por que as entregas não fluem, por que sempre tem retrabalho e por que parece que nunca conseguimos medir direito o sucesso do que foi entregue.

A raiz do problema está três níveis acima do seu backlog

Vou ser direto: mudanças de prioridade que se tornam crônicas no nível da alta liderança criam um custo que vai muito além do retrabalho. Quando áreas e times já foram mobilizados para um determinado propósito e precisam mudar de direção, o preço é altíssimo.

Empresas que lidam com software crítico não podem se dar ao luxo desse tipo de improviso. Na SpaceX, o software é projetado defensivamente, de forma que mesmo dentro de um componente, eles tentam isolar os efeitos de erros. "Sempre verificamos códigos de erro e valores de retorno. Também temos a capacidade de operadores ou tripulação sobrescreverem diferentes aspectos do algoritmo", explica Steven Gerding, líder de desenvolvimento de software da Dragon.

A diferença é que a SpaceX consegue velocidade porque suas mudanças de prioridade são baseadas em dados de telemetria e missões reais, não em "novas oportunidades" que alguém viu numa apresentação. Na SpaceX, mudanças de software são executadas em ambiente simulado antes de serem movidas para testbeds hardware-in-the-loop.

"Em cada estágio, seja simulado ou um teste hardware-in-the-loop ou um teste vehicle-in-the-loop, você está coletando telemetria e revisando os dados para poder prosseguir para o próximo estágio."

Eles não mudam prioridade por impulso. Mudam baseado em evidências concretas e com um sistema preparado para absorver essas mudanças sem quebrar o fluxo.

Ninguém quer calcular o custo dessas mudanças de prioridade

Vamos falar de números reais. Pesquisas mostram que organizações implementando feedback contínuo tinham 2.5 vezes mais probabilidade de ver melhoria na performance geral quando comparadas àquelas que fazem apenas avaliações anuais. Mas isso só funciona quando há estabilidade suficiente para que os times consigam implementar melhorias.