Seu Método Já Tem Retrospectivas. Ele as Chama de Relatórios de Lições Aprendidas.

O Waterfall Tem Retrospectivas?

Sim, com um nome diferente. O PRINCE2 nomeia "aprender com a experiência" como um de seus sete princípios¹. Ele mantém um Registro de Lições, criado durante a fase de Início em uma atividade chamada Capturar Lições Anteriores, e um Relatório de Lições é tipicamente incluído em cada Relatório de Fim de Estágio². Se você executa PRINCE2, você já realiza uma revisão estruturada no final de um estágio e registra o que aprendeu. Isso é uma retrospectiva.

Você provavelmente já ouviu o contrário. A ideia de que equipes tradicionais "não fazem retros" é uma das afirmações mais repetidas e menos examinadas no mercado de ferramentas de entrega. Ela não sobrevive ao contato com os manuais. O que as equipes tradicionais estão perdendo não é a prática. São as ferramentas.

Pense em onde um Relatório de Lições realmente vai. Alguém o escreve em um limite de estágio, geralmente sob pressão de tempo, geralmente depois que os detalhes interessantes já desapareceram. Ele é anexado a um Relatório de Fim de Estágio, arquivado em uma unidade compartilhada e lido por aproximadamente ninguém no início do próximo estágio. O aprendizado é capturado e então abandonado.

Para ser justo, equipes ágeis não são obviamente melhores nisso. Um quadro de retro cheio de notas adesivas é fotografado e abandonado com a mesma frequência. Nenhum dos grupos resolveu o problema de fazer a lição do mês passado mudar o comportamento do próximo mês. A diferença é que um desses grupos passou quinze anos construindo software para isso, e o outro foi informado de que o software não é para eles.

Seja qual for seu método, PRINCE2, um processo interno de portões de estágio, ou algo que sua organização montou ao longo de duas décadas, a forma é a mesma. No final de uma fase você revisa o que aconteceu e registra. A questão em aberto nunca é se você faz isso. É se algo acontece com o que você escreveu.

A Que as Cerimônias Ágeis Correspondem na Entrega Tradicional?

Toda cerimônia ágil tem uma contraparte tradicional, e a maioria das contrapartes veio primeiro. Retrospectivas correspondem a revisões de lições. Standups correspondem a relatórios de status. Demos correspondem a revisões de portões de estágio. Estimativa corresponde aos números já presentes em sua estrutura analítica de trabalho. O vocabulário é diferente. O trabalho é o mesmo, e você já está fazendo isso.

A coluna da esquerda é um vocabulário que você não escolheu e não precisa. A coluna do meio é trabalho que você já faz, em um cronograma que outra pessoa definiu, geralmente em um modelo. O Simyl Flow automatiza a coluna do meio. A coluna da esquerda é apenas o que os botões dizem.

Você pode usar o produto por um ano sem nunca dizer a palavra "sprint" em voz alta.

O Simyl Flow Exige Sprints de Duas Semanas?

Não. Um sprint no Simyl Flow é um intervalo de datas nomeado com início e fim. Nenhuma duração é imposta em qualquer lugar do produto. Uma fase de seis semanas, um lançamento trimestral ou um marco cuja data final já atrasou duas vezes se comportam da mesma maneira, porque cada métrica é calculada a partir de carimbos de data/hora em seus tickets e commits, em vez da duração do contêiner.

Isso importa mais do que parece. Se uma ferramenta assume duas semanas, essa suposição vaza para tudo que vem depois: os gráficos, as comparações, os limites que decidem o que conta como lento. Ferramentas construídas dessa forma genuinamente não se encaixam em uma organização baseada em fases, e a resposta razoável é a que você já tinha.

Aqui o contêiner é um rótulo em um intervalo de datas. Chame de Fase 3. Chame de Lançamento 4.2. Chame de Estabilização Q3. O tempo de ciclo ainda é o intervalo entre o início e o término de um ticket. A taxa de bugs ainda é uma proporção. Nenhum se torna sem sentido porque sua fase durou onze semanas em vez de duas.

O Que Você Pode Medir Sem Mudar Como Sua Equipe Trabalha?

Conecte seu rastreador de issues e seu repositório de código, e seis métricas aparecem sem que ninguém participe de uma nova reunião: Velocidade, Tempo de Ciclo, PRs Mesclados, Commits, Taxa de Bugs e Trabalho Não Planejado. Cada uma é derivada de registros que sua equipe já cria no curso da execução do trabalho. Nenhuma sessão de estimativa, nenhum standup e nenhuma retrospectiva é necessária para produzir qualquer uma delas.

Este é o ponto de entrada honesto, e é o que recomendaríamos mesmo se você fosse entusiasmado com cerimônias. Ninguém precisa aprender novo vocabulário. Ninguém precisa ser convencido de uma filosofia em uma reunião de segunda-feira. Os dados já estão no Jira e no GitHub, ali, descrevendo como sua entrega realmente se comporta.

As cerimônias existem no produto. Você pode ativá-las quando quiser, ou nunca. Uma equipe que conecta dois sistemas e não abre mais nada ainda obtém uma tendência de tempo de ciclo, o que é mais do que a maioria das organizações tradicionais tem hoje.

O que tende a surpreender as pessoas é onde a espera aparece. Não no desenvolvimento. Nas transferências entre fases, na lacuna entre "código completo" e "ambiente de teste disponível", na semana que uma ordem de mudança passou esperando por uma assinatura.

O Que a Velocidade Não Te Diz?

A velocidade te diz quanto trabalho foi concluído em um período. Ela não pode te dizer se esse trabalho permaneceu concluído, quanto tempo qualquer parte dele esperou antes de alguém pegá-lo, ou o que custou para sair pela porta. Uma fase pode atingir sua meta de velocidade exatamente e ainda assim entregar defeitos que consomem a fase seguinte. O número parece o mesmo de qualquer forma.

Isso não é um argumento contra a velocidade. É um número genuinamente útil, e rastreá-lo te coloca à frente das muitas organizações que não rastreiam nada. O problema não é que a velocidade está errada. É que a velocidade geralmente está sozinha.

Imagine duas fases com velocidade idêntica. Na primeira, o trabalho avançou de forma constante, a revisão levou um dia, e quase nada voltou. Na segunda, tudo ficou em revisão por nove dias, foi entregue em uma explosão na última semana, e um terço voltou como defeitos em um mês. A velocidade registra essas duas fases como equivalentes. Tempo de Ciclo, Taxa de Bugs e Trabalho Não Planejado não.

O Trabalho Não Planejado é geralmente o que impacta mais forte em uma operação baseada em fases. É o número que finalmente explica por que o plano atrasou quando ninguém na equipe fez nada errado. Você planejou para o trabalho que conhecia. Algo mais chegou. A maioria dos processos de planejamento não tem como mostrar isso, então o atraso é atribuído às estimativas, ou às pessoas, e a mesma coisa acontece na próxima fase.

Você pode ver como as seis dimensões se encaixam na visão geral de eficácia.

Não Estamos Aplicando um Golpe de Longo Prazo

Não há uma fase dois onde pedimos que você adote Scrum.

A medição funciona porque suas fases têm datas e seus tickets têm timestamps. Ela não funciona por causa do framework impresso na parede. Se você conectar seus sistemas, nunca executar uma retrospectiva neste produto, e nunca estimar um único item nele, ele ainda te diz se a entrega está ficando mais rápida ou mais lenta e onde a espera acontece.

Preferimos ser úteis para você como você já trabalha do que esperar que você se torne outra pessoa primeiro.

Não é um funil de conversão. É uma ferramenta de medição.

Perguntas Frequentes

Precisamos adotar ágil para usar o Simyl Flow?

Não. O produto lê datas do seu rastreador de issues e timestamps do seu repositório. Nenhum dos dois depende de um framework. Equipes executando fases, portões de estágio, ou um processo interno sob medida obtêm as mesmas métricas que equipes executando iterações de duas semanas, porque os registros subjacentes são os mesmos em ambos os casos.

O Simyl Flow requer sprints de duas semanas?

Não. Um sprint é um intervalo de datas nomeado com um início e um fim, e nenhuma duração é imposta. Uma fase, um marco, um lançamento, ou um trimestre funcionam. As métricas são calculadas a partir de timestamps em tickets e commits, então a duração do contêiner não muda como elas são calculadas.

Executamos PRINCE2. Onde ele se encaixa?

Seu Relatório de Fim de Estágio é o lugar natural. O PRINCE2 já coloca uma revisão de lições nesse limite, então os recursos de retrospectiva têm um lugar óbvio para existir se você quiser usá-los. Você não precisa usá-los. Conecte suas ferramentas e as métricas de entrega funcionam independentemente de qual processo as envolve.

Não executamos retrospectivas. Ainda é útil?

Sim. Tempo de Ciclo, Taxa de Bugs, Trabalho Não Planejado, PRs Mesclados e Commits são todos derivados dos seus tickets existentes e histórico de código. Eles não requerem reunião nem facilitação. As retrospectivas adicionam um lugar para agir sobre o que os números mostram, mas os números chegam independentemente de você realizar uma ou não.

Qual é a configuração mínima?

Um rastreador de issues ou um repositório de código. Conecte-o, escolha um intervalo de datas que corresponda a como você já planeja, e as métricas são preenchidas a partir do histórico. Nada muda sobre como sua equipe trabalha naquela semana, que é o ponto.

Fontes