Agile Delivery Flow: Fornire sempre in tempo in 3 passaggi

Se si chiede alla maggior parte dei manager della “sicurezza psicologica” o della “visione” (per saperne di più: Sicurezza psicologica ) dei loro team di sviluppo software agile, concordano sul fatto che queste cose sono importanti, ma… Quando il cliente segnala urgenza o la scadenza si avvicina, tutte queste variabili “più soft” vengono tipicamente messe da parte. I manager si preoccupano soprattutto di un Agile Delivery Flow che funzioni in modo prevedibile per il loro team agile.

Se hai navigato nel nostro blog Echometer ( al nostro blog ), sai che i nostri contenuti si concentrano maggiormente sul miglioramento delle “soft skills” di team e organizzazioni. Queste sono spesso sottovalutate dai responsabili delle decisioni. Ma non dagli Scrum Master e dagli Agile Coach.

Ciò che secondo me Scrum Master e Agile Coach sottovalutano a loro volta è la concentrazione sul miglioramento del Delivery Flow, in sostanza ciò che vogliono i manager. Nel post di oggi descrivo una semplice tecnica per aumentare significativamente la probabilità di consegnare ripetutamente nei tempi e nel budget previsti.

1. Primo passo per quanto riguarda il vostro Agile Delivery Flow

Mi riferisco al monitoraggio dell’Agile Delivery Flow delle vostre attività o Task. Se fai bene solo un paio di cose, sarai in grado di fornire risultati molto più prevedibili. Anche i tuoi Cycle Time Scatter Plot o la tua simulazione Monte-Carlo per calcolare le stime dei progetti potrebbero finalmente indicare previsioni valide, invece di essere completamente errate (per saperne di più: 9 metriche Agile per i responsabili delle decisioni ).

Primo sintomo da combattere: ci sono Task che impiegano solo pochi giorni da “Pianificato” a “Completato”, e poi ci sono Task che richiedono più di un mese. Per contrastare questo, dovresti assicurarti che un Task contenga sempre la versione consegnabile più piccola possibile della funzionalità desiderata. Senza fronzoli inutili per il desiderio principale del cliente. In sostanza, un MVT, Minimum Viable Task. Ciò non significa che ogni Task sia piccolo. Ma dovrebbe aiutarti a raggiungere una fase in cui le attività richiedono al massimo un paio di settimane e non mesi.

2. Secondo passo per quanto riguarda il tuo Agile Delivery Flow: WIP invece di Velocity

Molti Scrum Master o Kanban Coach credono che per una misurazione valida della Velocity ecc. sia importante il “right sizing” dei Task o dei Workitem, in cui tutti i Workitem hanno all’incirca le stesse dimensioni. Solo allora gli Story Point (necessari per misurare la Velocity) sarebbero utili per misurare la Velocity, perché sembrano più un’unità di tempo comparabile. 

Ma questo è sbagliato: i Task non devono nemmeno avere dimensioni simili. Non dovresti darlo per scontato, perché è semplicemente troppo difficile controllare le stime degli Story Point. L’unica cosa che puoi controllare è quanti nuovi Task inizi.

Quindi, per diventare prevedibili, fate quanto segue: monitorate il tasso di “Task appena iniziati” rispetto al tasso di “Task completati”. Questi due dovrebbero essere in equilibrio. In altre parole, il tasso di “entrata” e il tasso di “uscita” dei Task dovrebbero essere il più vicino possibile, idealmente anche corrispondenti.

Un esempio: il comportamento tipico nei team di sviluppo software è che, non appena un Task è bloccato, si inizia un nuovo Workitem. Ciò porta ad avere molti Task aperti, ma incompleti, il che rende molto più complicato sbloccarli tutti di nuovo. 

Se invece ti assicuri che per ogni Task iniziato ci sia anche un Task completato, nel Daily sarà più facile sbloccare i pochi Task su cui ci si concentra. Le vostre prestazioni complessive diventeranno più prevedibili e il team sarà più soddisfatto perché il vostro superiore e i vostri clienti saranno più soddisfatti.

Alcuni “sintomi positivi” di un flusso di Agile Delivery sano e agile

In pratica, questo si tradurrebbe nei seguenti comportamenti:

• • Non iniziamo nuove attività quando ci sono ancora molte cose in corso. 

• • Ci concentriamo sul completare ciò che abbiamo iniziato prima di iniziare nuove cose.

• • l’età delle attività non supera mai le poche settimane.

• • Se non c’è un buon motivo per farlo, lavoriamo sempre sull’attività più vecchia.

Anche i limiti WIP (Work-in-Progress) sono utili in questo, anche se spesso non sono sufficienti. Una volta che il team ha imparato a concentrarsi sul completamento delle attività invece di iniziarne di nuove, sarete migliori della maggior parte dei team.

Quando si utilizza correttamente l’Agile Delivery Flow

Per creare aspettative chiare: इन questo modo non puoi ancora controllare se un’attività richiede due o tre giorni. Ma almeno ti assicuri che il tuo team non stia lavorando a così tante attività che le attività da 2-3 giorni finiscano per richiedere un mese.

Quanto starebbe già meglio il tuo team se sapessi che fondamentalmente tutti gli impegni di consegna vengono soddisfatti entro poche settimane? Naturalmente, questo presuppone che implementiate tutte le cose di cui sopra: la definizione di MVT, un rigoroso limite WIP e l’impegno a non iniziare nuove attività finché un’altra attività non è stata completata.

Fase 3: Iniziare a migliorare l’Agile Delivery Flow

In teoria, sai cosa fare. Qual è il modo migliore per iniziare praticamente? Creando consapevolezza e “disponibilità al cambiamento” nel team. Nel migliore dei casi attraverso l’auto-riflessione.

Devi creare trasparenza su questi numeri e controllarli regolarmente per vedere se il rapporto tra attività avviate e completate è in equilibrio. Potrebbe far parte della vostra retrospettiva, approfondire un po’ e riflettere sul motivo per cui i numeri non erano in equilibrio nell’ultimo ciclo. 

Posso consigliare di discutere i comportamenti che ho menzionato nella vostra retrospettiva con il nostro strumento di retrospettiva agile Echometer (maggiori informazioni su: 7 strumenti di retrospettiva a confronto ). Potreste persino farne parte dei vostri accordi di lavoro (o Working Agreements) o del vostro Health Check regolare per sensibilizzare l’opinione pubblica ponendo regolarmente le domande.

Le seguenti domande sono tratte dal nostro template di retrospettiva per l‘“agile Delivery” (maggiori informazioni su: 22 template divertenti per retrospettive agili ). Iniziamo con alcune dichiarazioni di Health Check e chiediamo al team se è più d’accordo o in disaccordo. Poi ci sono alcune domande aperte:

Retrospettiva Agile Delivery

Elementi di Health Check

Quando il nostro modo di lavorare ha portato a un flusso di lavoro non ottimale? (ad es. linee guida poco chiare, inadeguate o non seguite)

Come puoi immaginare, l’ultimo punto dell’Health Check (Verifica della causa) implica già una potenziale misura, qualcosa che puoi provare per uno o due sprint agili per vedere se potrebbe esservi d’aiuto: la limitazione del numero di attività con lo stato “Work in Progress”.

Porre le basi: definire gli accordi per il lavoro di squadra

Pensi che il tuo team non sia ancora pronto per questo tipo di riflessione? In questo caso, dovresti prima riflettere sul “buon lavoro” in generale e poi definire alcune regole di base, i cosiddetti accordi di lavoro (Working Agreements). Il seguente modello di workshop può esserti d’aiuto. Puoi eseguirlo come una forma speciale di retrospettiva all’inizio di un progetto o come workshop aggiuntivo.

Per prima cosa, dovresti farti un’idea di quanto il tuo team si senta implicitamente d’accordo: vedi la voce del Health Check. Quindi dovresti verificarlo praticamente con alcune domande aperte. Ogni membro del team deve terminare la frase (vedi altre domande) con quante più risposte gli/le vengono in mente:

Retrospettiva sugli impegni del team

Elementi di controllo dello stato di salute

Gestione dei conflitti: “Se noto che sta emergendo un conflitto nel nostro team, allora…”

Dopo aver raccolto le risposte, naturalmente dovresti cercare di trovare degli schemi e concordare accordi concreti su come vorreste collaborare in futuro, almeno temporaneamente come esperimento.

Un’alternativa interessante e creativa

Se questi metodi di retrospettiva ti sembrano troppo “aridi”, c’è un altro metodo di retrospettiva che si concentra sulla riflessione della qualità dell’output del tuo team ( Qui puoi trovare 54 metodi di retrospettiva divertenti ): la retrospettiva “I tre porcellini”. È una semplice alternativa per iniziare a riflettere e migliorare le tue prestazioni, basata sulla fiaba dei tre porcellini che costruirono case con materiali diversi.

Conclusione: flusso di delivery agile

Non importa come inizi: l’importante è iniziare. I team che tengono d’occhio il loro Agile Delivery Flow sono i team migliori.

A proposito, molte delle idee che trovi qui sono ben riassunte anche nel podcast “Agile Bites”, che consiglio vivamente (Al podcast: Agile Bites). 

Divertiti a sviluppare ulteriormente il tuo team!