Agile Fluxo de entrega: sempre entregue no prazo em 3 etapas
Se você perguntar à maioria dos gerentes sobre a “segurança psicológica” ou a “visão” (mais sobre isso: Segurança psicológica ) de suas equipes ágeis de desenvolvimento de software, eles concordam que essas coisas são importantes, mas… Quando o cliente sinaliza urgência ou o prazo se aproxima, todas essas variáveis “mais suaves” normalmente são deixadas de lado. Os gerentes estão preocupados principalmente com um fluxo de entrega ágil que funcione de forma previsível para sua equipe ágil.
Se você der uma olhada em nosso blog Echometer ( para nosso blog ) você deve saber que nosso conteúdo se concentra mais em melhorar as “soft skills” de equipes e organizações. Estas são frequentemente subestimadas pelos tomadores de decisão. Mas não pelos Scrum Masters e Agile Coaches.
O que, por sua vez, Scrum Masters e Agile Coaches, na minha opinião, subestimam é a concentração na melhoria do fluxo de entrega - basicamente o que os gerentes querem. Na publicação 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 de Velocity, etc., é importante o “right sizing” de Tasks ou Workitems, em que todos os Workitems têm aproximadamente o mesmo tamanho. Somente então os Story Points (que são necessários para medir a Velocity) são úteis para medir a Velocity, porque se parecem mais com 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.
Então, faça o seguinte para se tornar previsível: Monitore a taxa de “tarefas recém-iniciadas” em comparação com a taxa de “tarefas concluídas”. Estes dois devem estar em equilíbrio. Em outras palavras, as taxas de “entrada” e “saída” de tarefas devem estar o mais próximas possível, idealmente até mesmo correspondentes.
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, você garantir que haja uma tarefa concluída para cada tarefa iniciada, será mais fácil desbloquear as poucas tarefas focadas no Daily. Seu desempenho geral se tornará mais previsível - e a equipe ficará mais satisfeita porque seu supervisor e seus clientes estarã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, você sabe o que fazer. Qual é a melhor maneira de começar na prática? Criando conscientização e “disposição para mudar” na equipe. O ideal é por meio 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 perguntas são do 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
Fazemos as coisas muito rapidamente. Sem espera, sem atrasos.
Podemos estimar exatamente o que podemos entregar em um determinado ciclo.
Nossos resultados de sprint não exigem nenhum retrabalho após o sprint para serem entregues.
Limitamos nosso “trabalho em andamento” para que você possa se concentrar o tempo todo.
Perguntas abertas
Quando foi que nossa maneira de trabalhar realmente funcionou bem?
Qual é o maior potencial de melhoria para que os pacotes de trabalho passem por nossos processos mais rapidamente (eliminar tempos de espera, melhorar os processos)?
Quais foram os exemplos recentes de um incremento que não funcionou/entregável no final do sprint?
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 você pode imaginar, o último ponto do Health Check (verificar a causa) já implica uma medida potencial, algo que você pode experimentar por um ou dois sprints ágeis para ver se isso pode ajudá-lo: Limitar o número de tarefas com o status “Work in Progress”.
Estabelecer a base: Estabeleça acordos para o trabalho em equipe
Você sente que sua equipe ainda não está pronta para esse tipo de reflexão? Nesse caso, você 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. Você pode realizá-lo como uma forma especial de retrospectiva no início de um projeto ou como um workshop adicional.
Primeiro, você deve ter uma ideia de como sua equipe se sente implicitamente em concordância - veja o Item de Health Check para isso. Então você deve verificar isso praticamente com algumas perguntas abertas. Cada membro da equipe deve terminar a frase (ver mais perguntas) com o máximo de respostas possível que vierem à mente:
Retrospectiva dos compromissos da equipe
Itens Health Check
Temos um entendimento comum do que é 'bom trabalho' na minha equipe.
Perguntas abertas
Lidar com prioridades conflitantes: "Se eu perceber prioridades conflitantes, então...
Comunicação dos bloqueadores: “Se eu ficar preso em uma tarefa, compartilho isso com você…
Lidar com conflitos: “Se eu perceber que está surgindo um conflito em nossa equipe, então…
Depois de coletar as respostas, é claro que você deve tentar encontrar padrões e concordar com acordos concretos sobre como deseja trabalhar em conjunto no futuro - pelo menos temporariamente como um experimento.
Uma alternativa interessante e criativa
Se esses métodos de retrospectiva parecerem muito “secos” para você, há outro método de retrospectiva que se concentra em refletir sobre a qualidade da produção de sua equipe ( 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.
Retrospectiva Scrum Perguntas:
Casa de palha: o que construímos que está apenas se mantendo, mas que pode cair a qualquer momento? 🌱
Casa feita de gravetos: O que construímos que é relativamente estável, mas que ainda pode ser melhorado? 🪵
Casa de pedra: o que construímos que é sólido como uma rocha? 🪨
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 você encontra aqui também são bem resumidas no podcast “Agile Bites”, que eu recomendo muito (Para o podcast: Agile Bites).
Divirta-se desenvolvendo sua equipe!