Agile Fluxo de entrega: sempre entregue no prazo em 3 etapas

Se você perguntar à maioria dos gestores sobre a “segurança psicológica” ou a “visão” (mais sobre isso: Segurança psicológica ) das suas equipas de desenvolvimento de software ágil, eles concordam que estas coisas são importantes, mas… Se o cliente sinalizar urgência ou o prazo se aproximar, todas estas variáveis “mais suaves” são normalmente deixadas de lado. Os gestores estão principalmente preocupados com um fluxo de entrega ágil que funcione de forma previsível da sua equipa ágil.

Se você der uma olhada em nosso blog Echometer ( para nosso blog ) já navegou, sabe que o nosso conteúdo se concentra mais na melhoria das “soft skills” de equipas e organizações. Estas são frequentemente subestimadas pelos decisores. Mas não pelos Scrum Masters e Agile Coaches.

O que, por sua vez, os Scrum Masters e Agile Coaches, na minha opinião, subestimam é a concentração na melhoria do fluxo de entrega - basicamente o que os gestores querem. No artigo de hoje, descrevo uma técnica simples para aumentar significativamente a probabilidade de entregar repetidamente dentro do prazo e do orçamento.

Primeira etapa em relação ao seu fluxo de entrega Agile

Estou falando de monitorar o fluxo de entrega Agile de suas tarefas. Se você fizer apenas algumas coisas corretamente, poderá apresentar resultados muito mais previsíveis. Até mesmo seus gráficos de dispersão de tempo de ciclo ou sua simulação de Monte Carlo para calcular estimativas de projeto podem finalmente indicar previsões válidas em vez de estarem completamente erradas (leia mais: 9 Agile Métricas para tomadores de decisão ).

O primeiro sintoma a ser combatido é que há tarefas que levam apenas alguns dias de “Agendada” a “Concluída”, e há tarefas que levam mais de um mês. Para combater isso, você deve certificar-se de que uma tarefa sempre contenha a menor versão possível do recurso desejado. Sem recursos que não sejam necessários para a solicitação principal do cliente. Basicamente, uma MVT, Minimum Viable Task (tarefa mínima viável). Isso não significa que você fará com que todas as tarefas sejam pequenas. Mas deve ajudar você a chegar a um estágio em que as tarefas levem no máximo algumas semanas, em vez de meses.

Segunda etapa em relação ao seu fluxo de entrega Agile: WIP em vez de velocidade

Muitos Scrum Masters ou Kanban Coaches acreditam que, para uma medição válida da Velocity, etc., é importante o “right sizing” de Tasks ou Workitems, em que todos os Workitems têm aproximadamente o mesmo tamanho. Só então os Story Points (que são necessários para medir a Velocity) são úteis para medir a Velocity, porque parecem mais uma unidade de tempo comparável. 

Mas isso está errado: as tarefas nem mesmo precisam ter um tamanho semelhante. Você não deve presumir isso, pois é muito difícil controlar as estimativas do Story Point. A única coisa que você pode controlar é a quantidade de novas tarefas que você inicia.

Portanto, faça o seguinte para se tornar previsível: Monitorize a taxa de “tarefas recém-iniciadas” em comparação com a taxa de “tarefas concluídas”. Estas duas devem estar em equilíbrio. Por outras palavras: A taxa de “entrada” e a taxa de “saída” de Tasks devem estar o mais próximas possível, idealmente até corresponderem.

Um exemplo: o comportamento típico das equipes de desenvolvimento de software é que, assim que uma tarefa é bloqueada, um novo item de trabalho é iniciado. Isso faz com que muitas tarefas fiquem abertas, mas inacabadas, o que torna muito mais complicado desbloquear todas elas novamente. 

Se, em vez disso, garantir que para cada tarefa iniciada existe também uma tarefa concluída, será mais fácil desbloquear as poucas tarefas focadas no Daily. O vosso desempenho tornar-se-á mais calculável no geral - e a equipa ficará mais satisfeita porque o vosso supervisor e os vossos clientes estão mais satisfeitos.

Alguns “sintomas positivos” de um fluxo de entrega ágil saudável

Na prática, isso levaria aos seguintes comportamentos:

• • Não iniciamos novas tarefas quando ainda há muitas coisas em andamento. 

• • Nós nos concentramos em terminar o que começamos antes de começar coisas novas.

• • A idade das tarefas nunca ultrapassa algumas semanas.

• • Se não houver um bom motivo, sempre trabalhamos na tarefa mais antiga.

Os limites de WIP (work-in-progress) também ajudam nisso, embora muitas vezes não sejam suficientes. Quando a equipe aprender a se concentrar em concluir tarefas em vez de apenas iniciar novas, você estará melhor do que a maioria das equipes.

Se você usar o fluxo de entrega Agile corretamente

Para criar expectativas claras: Dessa forma, você ainda não pode controlar se uma tarefa leva dois ou três dias. Mas, pelo menos, você se certifica de que sua equipe não está trabalhando em tantas tarefas que as tarefas de 2 a 3 dias acabam levando um mês.

Quão melhor seria a sua equipe se você soubesse que basicamente todas as obrigações de entrega seriam cumpridas dentro de algumas semanas? Isso pressupõe, é claro, que você implemente todos os itens mencionados acima: Definir MVTs, um limite rígido de WIP e o compromisso de não reiniciar tarefas até que outra tarefa tenha sido concluída.

Etapa 3: Comece a melhorar o fluxo de entrega do Agile

Na teoria, sabe o que fazer. Qual é a melhor forma de começar na prática? Criando consciência e “disponibilidade para mudar” na equipa. No melhor dos casos, através da autorreflexão.

Você precisa ser transparente em relação a esses números e verificá-los regularmente para ver se a proporção entre tarefas iniciadas e concluídas está em equilíbrio. Você poderia fazer parte de sua retrospectiva para se aprofundar um pouco mais e refletir sobre por que os números não estavam equilibrados no último ciclo. 

Posso recomendar que você discuta os comportamentos que mencionei com nossa ferramenta de retrospectiva ágil Echometer em sua retrospectiva (leia mais: 7 Ferramentas retrospectivas em comparação ). Você pode até mesmo tornar isso parte de seus acordos de trabalho ou de Health Checks regulares para aumentar a conscientização fazendo as perguntas regularmente.

As seguintes questões são o nosso Modelo de Retrospectiva para a “entrega ágil” (mais sobre isso: 22 modelos divertidos para retrospectivas ágeis ). Começamos com algumas afirmações Health Check e perguntamos à equipe se ela tende a concordar ou discordar. Depois disso, há algumas perguntas abertas:

Agile Retrospectiva de entrega

Itens Health Check

Quando nossa maneira de trabalhar levou a um fluxo de trabalho abaixo do ideal? (por exemplo, diretrizes pouco claras, inadequadas ou não seguidas)

Como pode imaginar, o último ponto do Health Check (verificar a causa) já implica uma potencial medida, algo que pode experimentar durante um ou dois sprints ágeis para ver se vos pode ajudar: Limitar o número de Tasks com o estado “Work in Progress”.

Estabelecer a base: Estabeleça acordos para o trabalho em equipe

Sente que a sua equipa ainda não está preparada para este tipo de reflexão? Neste caso, deve primeiro refletir sobre o “bom trabalho” em geral e, em seguida, estabelecer algumas regras básicas, os chamados acordos de trabalho ou Working Agreements. O seguinte modelo de workshop pode ajudá-lo com isso. Pode realizá-lo como uma forma especial de retrospetiva no início de um projeto ou como um workshop adicional.

Primeiro, deve ter uma ideia de quão unida a sua equipa se sente implicitamente - veja o Item de Health Check para isso. Em seguida, deve verificar isto praticamente com algumas perguntas abertas. Cada membro da equipa deve terminar a frase (ver mais perguntas) com o maior número possível de respostas que lhe vierem à mente:

Retrospectiva dos compromissos da equipe

Itens Health Check

Lidar com conflitos: “Se eu perceber que está surgindo um conflito em nossa equipe, então…

Depois de recolher as respostas, deve, naturalmente, tentar encontrar padrões e concordar com acordos concretos sobre como pretende trabalhar em conjunto no futuro - pelo menos temporariamente como uma experiência.

Uma alternativa interessante e criativa

Se estas metodologias de retrospectiva lhe parecem demasiado “secas”, existe outro método de retrospectiva que se concentra em refletir sobre a qualidade do resultado da sua equipa ( Você pode encontrar o Fun 54 Retrospective Methods aqui ): Retrospectiva dos “Três Porquinhos”. É uma alternativa simples para você começar a refletir e melhorar seu desempenho, com base no conto de fadas dos três porquinhos que construíram casas com materiais diferentes.

Conclusão - Fluxo de Entrega Ágil

Não importa como você comece, o mais importante é começar em primeiro lugar. As equipes que ficam atentas ao fluxo de entrega do Agile são as melhores.

A propósito, muitas das ideias que encontra aqui também estão bem resumidas no podcast “Agile Bites”, que recomendo vivamente (Para o podcast: Agile Bites). 

Divirta-se desenvolvendo sua equipe!