SAFe: Program Increment (PI) Planning – Approccio AGILE

La Busines Agility è l’obiettivo dello Schema SAFe nell’attuale contesto  in continuo cambiamento, oltre alle difficoltà che ci sta creando il COVID-19. Il PI Planning è una delle parti essenziali dello schema SAFe, perciò riprendiamo i concetti base, per diffonderne la conoscenza.

SAFe-Scaled Agile

Cosa è SAFe

SAFe è un interessante schema per ottimizzare i flussi di lavoro di un ambiente “AGILE”. Lo scopo è: “Raggiungere l’agilità del Business significa che l’intera organizzazione – NON solo l’area sviluppo –  è  impegnata nel rilascio continuo e proattivo di soluzioni di business innovative, possibilmente prima della concorrenza.”

SAFe

Siamo di fronte ad un schema complesso, ma molto ricco e completo, infatti, cliccando su qualsiasi casella dello schema, si ottengono spiegazioni e dettagli su tutti i sui componenti. Un’affermazione mi ha colpito: “PI planning is essential to SAFe: If you are not doing it, you are not doing SAFe“.

Ecco perché, prima di parlare dell’intero schema, ci soffermiamo sul PI Planning. Ingrandendo l’area interessata al “Program Increment Planning” osserviamo la seguente, osserviamo i seguenti elementi da comprendere a fondo per poter organizzare con successo un progetto AGILE/LEAN di grandi dimensioni.

SAFe-PI-Planning

Già il Manifesto Agile  suggerisce un principio base: “Il metodo più efficace ed efficiente di veicolare informazioni in un gruppo di sviluppo è la conversazione “FACCIA a FACCIA”, infatti SAFe adotta proprio questo approccio per realizzare il  PI Planning – un evento di due giorni per impostare le iterazioni successive insieme a tutti i team del progetto/programma.

Si tratta di una riunione, moderata da un RTE (Release Train  Engineer), alla quale partecipano tutti i membri dell’ART (Agile Release Train), compreso i team remoti in video conferenza. La riunione faccia a faccia consente di allineare tutti i team su Mission e Vision, dando i seguenti benefici:

  • Comunicazione “FACCIA a FACCIA” tra tutti i membri del team e stakeholder
  • Sviluppo del network sociale dal quale dipende tutto l’ART.
  • Allineamento Obiettivi del team di sviluppo con gli obiettivi di PI Planning.
  • Identificazione delle dipendenze e impostazione delle collaborazioni
  • Opportunità per utilizzare architetture LEAN.
  • Incrocio della domanda con eliminazione degli eccessi di WIP (work in Progress).
  • Presa dei decisioni veloce.

L’evento  produce:

  • Un “Committed PI objectives” – un insieme di obiettivi SMART creati a ogni team con valori di business assegnati dai Business Owner.
  • Un “Program board” – il programmo di rilascio delle milestone e le relative dipendenze tra i vari team.

Preparazione del PI Planning

L’evento va preparato, coordinato, comunicato e moderato da un RTE. Vi partecipano: Business Owner, Product Manager, Agile Team, System and Solution Architect/Engineering, il Team di Sistema e altri stakeholder, tutti pre-avvisati per potersi preparare.

La partecipazione dei Business Owner garantisce la disponibilità del budget di spesa.

Gli elementi da preparare, come in molte altre riunioni, si possono riassumere in:

  • Prontezza organizzativa – Allineamento strategico dei team con l’impostazione del TRAIN:
    • Pianificare ambito e contesto
    • Allineamento al Business, in base alle priorità indicate dai  Business Owner
    • Team Agile – acquisizione di Sviluppatori, Scrum Master e Product Owner per costituire i team del progetto.
  • Prontezza dei contenuti  – preparazione gestione e sviluppo
    • Executive briefing
    • Product vision briefing(s)
    • Architecture vision briefing
  • Prontezza dell’Ambiente – Spazi e logistica per l’evento
    • Facility – aree sufficienti per ospitare tutti (sala riunione)
    • Facilities/tech support – sale attrezzate (PC, rete, ecc.)
  • Canali di comunicazione –  Impianti di video conferenza

Prima bozza del PI Planning

In prima battuta, i team stimano le loro capacità per ogni Iterazione ed identificano gli elementi di backlog necessari per realizzare i vari dispositivi. Ogni team crea la bozza del proprio piano, visibile a tutti, iterazione per iterazione.

Ad esempio, durante questo processo, i team identificano rischi e dipendenze e definiscono la bozza iniziale dei loro obiettivi di Incrementi da pianificare.

Tali obiettivi comprendono anche obiettivi non commissionati, obiettivi del piano  (es. storie definite e incluse per questi obiettivi), ma non richiesti perché   troppo sconosciuti o di alto rischio. Gli obiettivi non commissionati non sono cose extra da fare se c’è tempo, ma elementi che aumentano l’affidabilità del piano dando al management  un primo avviso su ciò che i team potrebbero non essere in grado di produrre.

Durante la pianificazione, i team identificano rischi e impedimenti che potrebbero ostacolare il raggiungimento degli obiettivi. Questi vengono valutati e risolti in un più ampio  contesto manageriale. Uno per uno, i rischi vengono discussi e affrontati con onestà e trasparenza, e poi assegnati in una delle seguenti categorie:

  • Risolto – i team concordano che il rischio non è più un problema.
  • Posseduto – Qualcuno si fa carico del rischio, poiché non può essere risolto durante la pianificazione.
  • Accettato – Alcuni rischi sono semplicemente fatti o potenziali problemi che bisogna comprendere ed accettare.
  • Mitigato – I team identificano un piano per ridurre la portata del rischio.

Fist of Five (Confidence vote)

Una volta esaminato il programma  dei rischi, si VOTA sulla confidenza nel raggiungere gli obiettivi fissati nel PI (Program Increment).

Ogni team VOTA con il  ‘fist of five’:

  • Se la media è 3 o più dita, il management si impegna
  • Se la media è meno di 3 dita, bisogna rivedere il piano

Chi ha votato meno di 3 dita ha l’opportunità di esprimere il suo dubbio.

  • I dubbi possono diventare rischi oppure richiedere solo dei miglioramenti alla pianificazione o prenderne atto.

Quando tutti i team hanno votato, si ripete il processo per l’intero ART, in modo da votare insieme il piano generale.

Fist of five

Planning Retrospective

Un altro esempio di approccio AGILE, a tutti gli effetti,  è l’esame di ciò che è andato bene e ciò che non è andato bene, oltre a cosa si potrà fare meglio in seguito.

PI Planning - Retrospective

La riunione di Pianificazione Retrospettiva discute i prossimi passi, formulando le istruzioni da fornire ai team, tipo:

  • Liberare le sale utilizzate per pianificare.
  • Catturare storie e obiettivi del PI in un tool.
  • Rivedere il calendario eventi.
  • Determinare sedi e  tempi delle  Pianificazioni delle altre Iterazioni.
  • Pianificare riunioni di stand-up

Ultimata la pianificazione , RTE e Stakeholder sintetizzano gli obiettivi individuali dei team in un  “Program PI  Objectives” per comunicarlo all’esterno e per poterlo controllare successivamente.

SAFe-Program-PI-Objectives

Grandi progetti potrebbero comprendere più ART e più Fornitori. In tal caso, la soluzione è utilizzare un evento  Pre-PI Planning, che imposta il contesto dei vari ART ed un evento Post-PI Planning che segua la pianificazione dei vari ART da utilizzare per integrare i risultati delle pianificazioni che contribuiscono alla soluzione.

Promo

Stiamo preparando un Fonamentali dello Schema SAFe,

complementare al Coaching sulle Certificazioni DevOps

già disponibile.

Ci proponiamo come apripista in tutti gli ambienti complessi che intendono intraprendere il percorso DevOps verso l’automazione dei rilasci continui e con SAFe, verso l’Agilità del Business.

Contattateci per una consulenza gratuite o una sessione di formazione a distanza

PMP-Prep Online (Light) e Simulazioni Esame PMP

Per qualsiasi chiarimento Vito Madaio di PMTSI è sempre a vostra disposizione. Modulo di contatto.