Há uma técnica adaptada do Lean Toyota que se chama “Stop The Line”, destacando algo que já passou por todo o processo de desenvolvimento e precisa priorização de ajustes (bug, impedimento, mudança) para ser entregue e não ficar com status de “quase pronto, mas com problemas”.
Diz a lenda que na Toyota havia botões vermelhos escritos “Stop The Line”, o custo ao apertá-lo era o de parar a linha de produção com um alto custo por minuto, mas mesmo assim evitando que defeitos persistissem e gerassem um ônus ainda maior adiante.
Em projetos de software, é um selo para chamar a atenção de que algo já consumiu os recursos, mas que exige algo mais para ser considerado pronto. Se ele era mais valoroso que os demais para iniciar, provavelmente é algo de valor que precisa atenção adicional para não ficar parado.
Uma técnica com foco em entrega antecipada de valor, que assim como o WIP (work in progress), responsável por limitar o número de atividades em cada status do fluxo de trabalho, nos induz a privilegiar primeiro acabar algo iniciado ao invés de ficar empilhando semi-acabados.
Gosto muito da frase do Juan Bernabó no final do Agile Brazil de 2016 – “Esperamos que as retrospectivas façam o seu trabalho!”. Tomo a liberdade de colocar a frase logo acima de um fictício botão de “Stop The Line”, com uma matriz que sempre uso para indicar o ciclo de vida de um sprint … quase tudo tem um momento ideal:
Stop The Line é um modelo mental
Se a descrição acima faz sentido, expanda além das funcionalidades, tarefas e defeitos, use este modelo mental para tudo, uma vez planejado o Sprint Backlog, quanto maior o foco e dedicação, melhor, pois haverão imprevistos, então deixe para depois o que não faz diferença ser agora.
Uma sprint possui uma estrutura pensada para foco em valor e resultado, adaptação sempre que necessário, com apresentação e aprendizados ao final, gerando um moto-contínuo equilibrado entre liberdade e responsabilidade, cerne da auto-organização.
Tem muito a ver com Pareto, não tem receita de bolo, mas o melhor é ver o todo e priorizar aquilo que gera mais valor e aparentemente fará diferença, o restante deixe para as retrospectivas fazerem o seu trabalho (mesmo em retrôs eu não imponho a pauta, ela é do time).
Tanto o WIP quanto o STL são padrões mentais relativo a sistemas puxados que vão se construindo em um time ágil, não por poder garantir só acertos, mas principalmente saber lidar com experimentação e erros, afinal, a cada novo insight ou percepção é preciso refletir:
- Manter o time focado durante 8 dias na sprint tem seu valor.
- É necessário “stop the line” para discutir isso agora?
- Se sobre critérios DoR, não dá para aguardar a Grooming?
- Se sobre critérios DoD, não dá para aguardar a Review/Retrô?
- Alguns impasses urgentes vão surgir, esse merece ser um deles?
Os primeiros Sprints de um Projeto
Há uma ampla gama de aprendizados, alguns ajustes em tempo real são vitais para estabelecer um patamar de confiança entre equipe, PO e stakeholders, baseado em entregas de valor e qualidade, outras questões podem esperar a retrospectiva.
Sem esquecer de Tuckman, da curva de aprendizado, de alguns sprints com riscos adicionais pertinentes a certo grau de tensão e desconhecimento do projeto, dos colegas, da tecnologia, modelo de dados, que a cada sprint vão-se mitigando e criando raízes fortes.
Ainda na minha opinião, que não vale nada, por isso é de graça, querer acelerar e garantir todos os aprendizados o mais rápido possível nos empurra para comando-controle ou tensão desnecessária, eu acredito em tempo ao tempo, equipes fortalecem-se e encontram seu ritmo.
As vezes não consigo deixar de lembrar o episódio do “Dino Da Silva Sauro” da família Dinossauro, quando assina uma TV a cabo com 150 canais … ele faz um cálculo e concluiu que a cada hora deveria assistir 24 segundos em cada canal para aproveitar ao máximo o investimento. Via de regra, menos é mais!
Jorge Horácio "Kotick" Audy 