Il Tuo Metodo Ha Già le Retrospettive. Le Chiama Report delle Lezioni Apprese.

Il Waterfall Ha le Retrospettive?

Sì, con un nome diverso. PRINCE2 indica "imparare dall'esperienza" come uno dei suoi sette principi¹. Mantiene un Lessons Log, creato durante la fase di Starting Up in un'attività chiamata Capture Previous Lessons, e un Lessons Report è tipicamente incluso in ogni End Stage Report². Se utilizzi PRINCE2, tieni già una revisione strutturata alla fine di una fase e annoti ciò che hai imparato. Questa è una retrospettiva.

Probabilmente ti è stato detto il contrario. L'idea che i team tradizionali "non facciano retro" è una delle affermazioni più ripetute e meno esaminate nel mercato degli strumenti di delivery. Non sopravvive al confronto con i manuali. Ciò che manca ai team tradizionali non è la pratica. Sono gli strumenti.

Pensa a dove finisce effettivamente un Lessons Report. Qualcuno lo scrive al confine di una fase, di solito sotto pressione temporale, di solito dopo che i dettagli interessanti sono già svaniti. Viene allegato a un End Stage Report, archiviato in un drive condiviso e letto da praticamente nessuno all'inizio della fase successiva. L'apprendimento viene catturato e poi abbandonato.

A dire il vero, i team agili non sono evidentemente migliori in questo. Una board di retro piena di sticky note viene fotografata e abbandonata altrettanto spesso. Nessuno dei due gruppi ha risolto il problema di far sì che la lezione del mese scorso cambi il comportamento del mese prossimo. La differenza è che uno di questi gruppi ha passato quindici anni a costruire software per questo, e all'altro è stato detto che il software non è per loro.

Qualunque sia il tuo metodo, PRINCE2, un processo interno di stage-gate, o qualcosa che la tua organizzazione ha assemblato in due decenni, la forma è la stessa. Alla fine di una fase rivedi ciò che è successo e lo annoti. La domanda aperta non è mai se lo fai. È se succede qualcosa a ciò che hai scritto.

A Cosa Corrispondono le Cerimonie Agili nel Delivery Tradizionale?

Ogni cerimonia agile ha una controparte tradizionale, e la maggior parte delle controparti è arrivata prima. Le retrospettive corrispondono alle revisioni delle lezioni. Gli standup corrispondono ai report di stato. Le demo corrispondono alle revisioni degli stage gate. La stima corrisponde ai numeri già presenti nella tua work breakdown structure. Il vocabolario è diverso. Il lavoro è lo stesso, e lo stai già facendo.

La colonna di sinistra è un vocabolario che non hai scelto e di cui non hai bisogno. La colonna centrale è lavoro che già fai, secondo un calendario stabilito da qualcun altro, di solito in un template. Simyl Flow automatizza la colonna centrale. La colonna di sinistra è solo ciò che dicono i pulsanti.

Puoi usare il prodotto per un anno senza mai pronunciare la parola "sprint" ad alta voce.

Simyl Flow Richiede Sprint di Due Settimane?

No. Uno sprint in Simyl Flow è un intervallo di date con nome, con un inizio e una fine. Nessuna durata è imposta in alcun punto del prodotto. Una fase di sei settimane, un rilascio trimestrale o una milestone la cui data di fine è già slittata due volte si comportano tutti allo stesso modo, perché ogni metrica è calcolata dai timestamp sui tuoi ticket e commit piuttosto che dalla lunghezza del contenitore.

Questo conta più di quanto sembri. Se uno strumento presuppone due settimane, quel presupposto si infiltra in tutto ciò che segue: i grafici, i confronti, le soglie che decidono cosa conta come lento. Gli strumenti costruiti in quel modo genuinamente non si adattano a un'organizzazione basata su fasi, e la risposta ragionevole è quella che hai già avuto.

Qui il contenitore è un'etichetta su un intervallo di date. Chiamalo Fase 3. Chiamalo Release 4.2. Chiamalo Q3 Hardening. Il cycle time è ancora l'intervallo tra l'inizio e la fine di un ticket. Il bug rate è ancora un rapporto. Nessuno dei due diventa privo di significato perché la tua fase è durata undici settimane invece di due.

Cosa Puoi Misurare Senza Cambiare il Modo in Cui Lavora il Tuo Team?

Collega il tuo issue tracker e il tuo repository di codice, e sei metriche appaiono senza che nessuno partecipi a una nuova riunione: Velocity, Cycle Time, PR Merged, Commit, Bug Rate e Unplanned Work. Ognuna è derivata da record che il tuo team crea già nel corso del lavoro. Nessuna sessione di stima, nessuno standup e nessuna retrospettiva è richiesta per produrne alcuna.

Questo è il punto di ingresso onesto, ed è quello che raccomanderemmo anche se fossi entusiasta delle cerimonie. Nessuno deve imparare un nuovo vocabolario. Nessuno deve essere convinto di una filosofia in una riunione del lunedì. I dati sono già in Jira e GitHub, lì, a descrivere come si comporta effettivamente il tuo delivery.

Le cerimonie esistono nel prodotto. Puoi attivarle quando vuoi, o mai. Un team che collega due sistemi e non apre nient'altro ottiene comunque un trend del cycle time, che è più di quanto la maggior parte delle organizzazioni tradizionali abbia oggi.

Ciò che tende a sorprendere le persone è dove appare l'attesa. Non nello sviluppo. Nei passaggi tra le fasi, nel divario tra "codice completo" e "ambiente di test disponibile", nella settimana che un change order ha passato in attesa di una firma.

Cosa Non Ti Dice la Velocity?

La velocity ti dice quanto lavoro è stato chiuso in un periodo. Non può dirti se quel lavoro è rimasto chiuso, quanto tempo ha aspettato prima che qualcuno lo prendesse in carico, o cosa è costato portarlo a termine. Una fase può raggiungere esattamente il suo obiettivo di velocity e comunque rilasciare difetti che consumano la fase successiva. Il numero appare lo stesso in entrambi i casi.

Questo non è un argomento contro la velocity. È un numero genuinamente utile, e tracciarlo ti mette avanti rispetto alle molte organizzazioni che non tracciano nulla. Il problema non è che la velocity sia sbagliata. È che la velocity è solitamente sola.

Immagina due fasi con velocity identica. Nella prima, il lavoro è avanzato costantemente, la revisione ha richiesto un giorno e quasi nulla è tornato indietro. Nella seconda, tutto è rimasto in revisione per nove giorni, è stato rilasciato in un'ondata nell'ultima settimana, e un terzo è tornato come difetto entro un mese. La velocity registra queste due fasi come equivalenti. Cycle Time, Bug Rate e Unplanned Work no.

Unplanned Work è solitamente quello che colpisce più duramente in un'organizzazione basata su fasi. È il numero che finalmente spiega perché il piano è slittato quando nessuno nel team ha fatto nulla di sbagliato. Hai pianificato per il lavoro di cui eri a conoscenza. È arrivato qualcos'altro. La maggior parte dei processi di pianificazione non ha modo di mostrarlo, quindi lo slittamento viene attribuito alle stime, o alle persone, e la stessa cosa accade nella fase successiva.

Puoi vedere come le sei dimensioni si integrano nella panoramica sull'efficacia.

Non Stiamo Conducendo una Truffa a Lungo Termine

Non c'è una fase due in cui ti chiediamo di adottare Scrum.

La misurazione funziona perché le tue fasi hanno date e i tuoi ticket hanno timestamp. Non funziona a causa del framework stampato sul muro. Se connetti i tuoi sistemi, non esegui mai una retrospettiva in questo prodotto e non stimi mai un singolo elemento al suo interno, ti dice comunque se la consegna sta diventando più veloce o più lenta e dove avviene l'attesa.

Preferiremmo esserti utili mentre lavori già piuttosto che aspettare che tu diventi prima qualcun altro.

Non un funnel di conversione. Uno strumento di misurazione.

Domande Frequenti

Dobbiamo adottare agile per usare Simyl Flow?

No. Il prodotto legge le date dal tuo issue tracker e i timestamp dal tuo repository. Nessuno dei due dipende da un framework. I team che eseguono fasi, stage gate o un processo interno personalizzato ottengono le stesse metriche dei team che eseguono iterazioni di due settimane, perché i record sottostanti sono gli stessi in entrambi i casi.

Simyl Flow richiede sprint di due settimane?

No. Uno sprint è un intervallo di date nominato con un inizio e una fine, e nessuna durata è imposta. Una fase, una milestone, un rilascio o un trimestre funzionano tutti. Le metriche sono calcolate dai timestamp sui ticket e sui commit, quindi la lunghezza del contenitore non cambia come vengono calcolate.

Eseguiamo PRINCE2. Dove si inserisce?

Il tuo End Stage Report è il posto naturale. PRINCE2 mette già una revisione delle lezioni a quel confine, quindi le funzionalità di retrospettiva hanno un posto ovvio dove vivere se mai le vorrai. Non hai bisogno di usarle. Connetti i tuoi strumenti e le metriche di consegna funzionano indipendentemente da quale processo le avvolge.

Non eseguiamo retrospettive. È comunque utile?

Sì. Cycle Time, Bug Rate, Unplanned Work, PR Merged e Commit sono tutti derivati dai tuoi ticket esistenti e dalla cronologia del codice. Non richiedono alcuna riunione e nessuna facilitazione. Le retrospettive aggiungono un posto per agire su ciò che mostrano i numeri, ma i numeri arrivano indipendentemente dal fatto che tu ne tenga una o meno.

Qual è la configurazione minima?

Un issue tracker o un repository di codice. Connettilo, scegli un intervallo di date che corrisponde a come pianifichi già, e le metriche si popolano dalla cronologia. Nulla cambia nel modo in cui il tuo team lavora quella settimana, che è il punto.

Fonti