SAFe Innovation & Planning vs. Sprint Planning
Stiamo passando a SAFe nella mia azienda e ho difficoltà a comprendere le differenze. Sono certificato in Scrum (CSM / CSPO), ma non so molto di SAFe e non vedo molta differenza tra la parte di pianificazione di SAFe Innovation & Planning e Scrum Sprint Planning. Qual è la differenza? Ho provato a cercare su Google ma sembra che siano gli stessi, tuttavia nel nostro team stiamo facendo sia I&P con il punteggio delle storie degli utenti e quant'altro, ma abbiamo anche la pianificazione di Sprint in cui (ri) segniamo anche gli Stati Uniti. Ho la sensazione che stiamo facendo qualcosa di sbagliato.
Risposte
In Scrum, lo Sprint Planning avviene all'inizio di ogni Sprint. Nella maggior parte delle implementazioni di Scaled Scrum, lo Sprint Planning è sincronizzato tra i team e spesso ha una componente condivisa in cui i team allineano i loro piani per il prossimo Sprint. In SAFe, questa attività è rappresentata dalla pianificazione delle iterazioni a livello di team.
L'iterazione di innovazione e pianificazione di SAFe non ha un evento corrispondente in Scrum. L'iterazione di innovazione e pianificazione si verifica una volta per incremento di programma. In Scrum, ogni Sprint (iterazione) ha lo scopo di produrre un prodotto potenzialmente rilasciabile. Tuttavia, l'Innovazione e l'iterazione della pianificazione è un periodo tampone per il miglioramento di strumenti e infrastrutture, formazione continua e formazione incrociata o sviluppo di competenze, attività di verifica e convalida formale, test di accettazione dell'utente, altre attività relative al rilascio e pianificazione dell'incremento del programma. Ha un diverso tipo di lavoro rispetto ad altre iterazioni.
Prima di passare a un framework agile in scala (SAFe, LeSS o qualsiasi altro), tutti nel processo devono essere chiari al 110% sul motivo del movimento.
La chiave per ridimensionare il processo è, come altri hanno già detto, fare lo stesso processo che farebbe un team normale, ma questa volta a un altro livello. Ho lavorato con Programmi con oltre 300 ingegneri, quindi in questo caso un framework scalato è un must. Come un team di 7 ingegneri farebbe una pianificazione, perfezionerebbe e concorderebbe con il PO ciò che può essere consegnato per le prossime 2 settimane, lo "stesso" accade quando hai 700 ingegneri ... ma lo "stesso" in questo caso è .. beh, non esattamente la stessa cosa.
Tornando alla domanda originale: "Non vedo molta differenza tra la parte di pianificazione di SAFe Innovation & Planning e lo Scrum Sprint Planning."
C'è una serie di artefatti che sono il risultato di una pianificazione PI che non sono comuni in uno Scrum Sprint Planning. Il tuo chilometraggio può variare, ma alcuni aspetti chiave che ho osservato essere fondamentali per una corretta pianificazione PI sono:
Affari Stakeholder attiva partecipazione
Rispetto a un normale Scrum Sprint Planning, il business è rappresentato dal PO. Nel caso della pianificazione PI, è altamente raccomandato che gli sponsor del progetto e del programma partecipino attivamente, ponendo domande e, verso la fine della pianificazione PI, assegnare un valore di business a queste caratteristiche.
Visualizzazione delle dipendenze tra i team
La visualizzazione delle dipendenze tra i team, come altri già menzionati, è quasi inesistente nei team che utilizzano Scrum puro. Sui framework scalati, è (purtroppo) comune avere dipendenze tra team. Dovrebbero essere evidenziati, i rischi identificati e le mitigazioni concordate tra le parti prima dell'effettivo Sprint Planning. Se la squadra A dipende da qualcosa della squadra B e la squadra B non può impegnarsi per aiutare la squadra A, allora forse la squadra A potrebbe aver bisogno di rivedere le proprie priorità o cercare alternative.
C'è molta spinta per avere tali sessioni con tutti negli stessi luoghi fisici, anche se in Covid19 non è così. È così che appare una normale bacheca delle dipendenze fisiche (questa bacheca è disponibile per tutti in ogni momento ei team vanno a raccogliere gli elementi dal backlog e ad assegnarli di conseguenza, evidenziando dipendenze e rischi):
Voto di fiducia
Inoltre, verso la fine della pianificazione del PI, a ogni ingegnere viene chiesto quanto sono sicuri del lavoro impegnato (e non impegnato) per il prossimo PI. Se la fiducia è bassa, le parti interessate e gli sponsor potrebbero avere l'opportunità sul posto di chiarire domande, dipendenze e spazio aperto per identificare problemi che, in un modello normale, gli sponsor richiederebbero settimane o mesi per realizzare.
Ecco come appare un'agenda di pianificazione PI:
Maggiori dettagli sulla pianificazione PI in SAFe sono disponibili in https://www.scaledagileframework.com/pi-planning/
L'Innovazione e la pianificazione in SAFe è effettivamente un'attività composta da due parti: la prima è un classico esercizio di ispezione e adattamento, molto simile alla Retrospettiva di Scrum. La seconda parte è l'esercizio di pianificazione, quando il successivo Incremento del programma (PI) viene eseguito da tutti i team .
La differenza con uno Sprint Planning è che in Scrum si riferisce a un singolo team e una singola iterazione. SAFe invece sta affrontando come scalare Agile con più team .
In SAFe tutti i team si uniscono alla pianificazione PI e si estende su più iterazioni, tipicamente tre o quattro: ai team viene presentata la visione per l'Incremento (qual è l'obiettivo aziendale) ei requisiti vengono suddivisi tra i team in base alla loro area, quindi ogni squadra suddivide e pianifica le proprie iterazioni e dettaglia i requisiti assegnati nelle proprie User Story.
Il break out di questo team può essere una classica pianificazione Scrum Sprint (SAFe è agnostico sulla metodologia del Team) ma moltiplicato per tutte le iterazioni . Non è necessario disporre di uno Sprint Planning separato dopo la pianificazione PI.
E dopo che ogni team ha preparato i propri piani per tutte le iterazioni successive, vengono esaminati con tutti gli altri team per trovare e risolvere / pianificare le dipendenze; infine ogni squadra sta mettendo a punto i piani / backlog degli sprint basati su questa revisione.
Stiamo parlando di tante squadre. Se un progetto è suddiviso in meno di cinque team, non ha molto senso utilizzare SAFe. Il coordinamento potrebbe essere ottenuto utilizzando, ad esempio, Scrum of Scrums