Agile Roadmap Planning fatta meglio, con Jira Software e Portfolio for JIRA

Il caso Rosetta StoneĀ®
Per raggiungere gli obiettivi aziendali, il lavoro quotidiano di un team di software deve essere in linea con la strategia di un’organizzazione. Eric Hilfer, VP di Software Engineering presso Rosetta StoneĀ®, sostiene cheĀ “uno dei miti dell’agile ĆØ che ti occupi di ciò che ti ritrovi sul piatto e non fai un piano, cosa che in realtĆ non ĆØ assolutamente vera”.
Lo sviluppo agile di software segue un preciso piano di rilascio, ma ĆØ difficile coordinarlo a livello multi-team quando si hanno molte dipendenze tra i diversi team.
Rosetta StoneĀ®, un’azienda che si occupa di tecnologie per l’apprendimento delle lingue, ha trovato una soluzione a questa sfida riunendo l’intero reparto di sviluppo circa una volta al trimestre per mappare dalle 10 alle 12 settimane di lavoroĀ E la settimana scorsa, ho avuto la fortuna di assistere alla loro 5a pianificazione di incremento di programma (soprannominato “PI5”). Continua a leggere per sapere come ĆØ andata.
Ma prima, cosa ĆØ un incremento di programma?Ā Un incremento di programma (PI) ĆØ un piano trimestrale che aggrega più team e il loro lavoro per un periodo di 10-12 settimane. La pianificazione dell’incremento di programma ĆØ l’evento frontale volto alla pianificazione del prossimo incremento. Questo meeting segue un’agenda standardizzata, che parte dalla presentazione del contesto e della visione di business, e prosegue con sessioni di pianificazione di gruppo, in cui i team creano i piani per l’imminente incremento del programma. Sotto la supervisione di unĀ release train engineer, tra i partecipanti figurano tutti coloro che lavorano sul treno di rilascio agile – un gruppo di team agili che pianifica, collabora ed esegue insieme. Il risultato finale ĆØ un impegno per il raggiungimento di un insieme di obiettivi condivisi di incremento del programma.
Day 1: La definizione del contesto per la roadmap
Il primo giorno ĆØ iniziato con presentazioni volte a condividere gli obiettivi organizzativi e le milestone con l’intero gruppo (80 persone ripartite su15 team in 6 uffici), per garantire che tutti fossero allineati. Queste presentazioni includevano lo stato attuale dell’azienda, la visione generale del programma, i temi e gli obiettivi strategici e i10 risultati principali da raggiungere nel corso del trimestre successivo.
Eric ha affermato che “la principale sfida nel lavorare con più team ĆØ assicurarsi che ogni team stia svolgendo la giusta attivitĆ , al momento giusto, e che abbia ben chiaro in che modo le diverse attivitĆ si coniughino tra di loro”, cosƬ il primo giorno viene usato per impostare tale contesto. Il primo giorno ĆØ stato ricco di presentazioni per aiutare tutti i team a capire pienamente a che cosa il loro lavoro mirava, e ciò ĆØ un elemento cruciale in qualsiasi tipo di meeting di pianificazione agile.
<< L’allineamento tra obiettivi di sviluppo e strategia aziendale ĆØ estremamente importante. >>
– Eric Hilfer, VP of Software Engineering presso Rosetta Stone
Come decidere i 10 principali traguardi per il prossimo trimestre:Ā Rosetta StoneĀ® utilizza una ‘epic kanban board’ con tutte le epic che possono essere eseguite durante quel piano di rilascio agile. Questa kanban board utilizza il seguente flusso di lavoro: Funnel> Revisione> Analisi> Backlog> Implementazione> Completamento. Circa 1 mese prima della Pianificazione PI, gli owner del prodotto spostano tutti i loro epic che potrebbero essere completati nel prossimo PI da “Revisione” a “Analisi” e le i team ne stimano l’effort. Successivamente, Chris (responsabile della gestione del prodotto) e Peter (CPO) utilizzano queste informazioni per creare una serie di obiettivi che portano al comitato direttivo esecutivo come proposta di una serie di attivitĆ da svolgere e risultati attesi. Dopo la discussione, le prioritĆ potrebbero cambiare e gli epic potrebbero esssere cambiati di stato, ma viene stabilita una serie di “milestone” da presentare alla riunione di pianificazione PI.
Day 2:Ā I team fanno i loro piani
Il giorno successivo, tutti sono scesi in campoĀ per affrontare l’agenda del secondo giorno: elaborare, assegnare prioritĆ , sequenziare e stimare 5 sprint, e quindi identificare, discutere e documentare dipendenze e rischi. Eric ha detto che “questi incontri trimestrali sono un momento fantastico in cui i team si riuniscono e interagiscono direttamente”. I team identificano le loro dipendenze e le mappano. Un buon inizio per qualsiasi team (metodo adottato anche dai team di Rosetta StoneĀ® all’inizio di questa seconda giornata) ĆØ quello di stimare la velocity per il trimestre successivo: qualcuno sarĆ in vacanza? Ci saranno nuove assunzioni nel team a modificarneĀ la velocitĆ ?
UtilizzaĀ Portfolio for Jira per calcolare la futura velocity: i team possono estrarre questa informazione direttamente da Portfolio per JIRA –Ā che elabora il dato a partire dalle agile board su cui i team lavorano – e poi prendere in considerazione eventi quali assenze o nuove assunzioni nel team.
CosƬ, i team hanno creato bozze di progetto, sprint per sprint e hanno poi sequenziato gli item del backlog sulle sprint fino a occuparne pienamente la capacitĆ . Questo ĆØ stato fatto su di una grande board di pianificazione (composta da scatole di cartone, nastro adesivo e MOLTIĀ post-it) che Eric ha descritto come “l’artefatto centrale che mostra ogni team rappresentato su una propria riga”. Su questa board, i team aggiungono fisicamente post-it con funzionalitĆ ed elementi grafici e mappano le dipendenze usando una stringa rossa.
La program board: Una board di programma evidenzia le delivery date per le nuove feature, le dipendenze tra team e le milestone più rilevanti.Ā C’ĆØ una riga per ogni squadra e una colonna per ogni sprint, e i team eseguono dispongono gli elementi del backlog negli sprint e poi individuano insieme le dipendenze.
In questa fase, i team hanno anche iniziato a redigere i propri obiettivi iniziali di incremento del programma (ciò che ciascun team si prefissa di raggiungere nel corso del prossimo trimestre); dall’aggregazione di tutti gli obiettivi di team, si individuano gli obiettivi PI dell’azienda, che saranno poi approvati dagli stakeholder.
Rosetta Stone® incoraggia i team ad includere obiettivi sfidanti che potrebbero non essere completati nel prossimo PI. Dopo che i team hanno individuato sul tabellone delle bozze di piani e obiettivi ciascun team separatamente presenta queste proposte agli stakeholder. Questi, poiché riesaminani le proposte di ogni team, hanno una visione olistica che gli permette di capire se sussistono criticità di scope, vincoli in termini di risorse e dipendenze tra team non tenute in considerazione.
Day 3:Ā Presentare i piani e stimarne la confidenza
Il giorno conclusivo serve a mettere insieme tutti i pezzi. I team si consultano ancora una volta per fare degli aggiustamenti sulla base dei feedback che hanno ricevuto il giorno prima, aggiornano il tabellone del programma e completano la loro presentazione. Un membro per ciascun team (un genere il Product Owner) presenta i punti salienti del piano di team a tutti i presenti. Ciò include gli obiettivi finali del programma di incremento, gli obiettivi a lungo termine, la sequenza di story per ogni sprint, i potenziali rischi e le dipendenze.
Durante questa presentazione, il resto del gruppo, al di fuori del team, ĆØ incoraggiato a fornire feedback e porre domande. Dopo che tutti i team hanno fatto la propria presentazione, si svolge un “voto di fiducia” in cuii gruppi votano la loro confidenza nelle capacitĆ di raggiungere gli obiettivi del programma usando il metodo del “fist of five”.
Votazione col metodo Fist of five:Ā questo metodo di votazione viene utilizzato dai team di sviluppo software agili come metodo rapido per interrogare i membri del team e aiutare a raggiungere il consenso. Innanzitutto, il facilitatore del team pone la domanda, ad es. Siamo tuttiĀ fiduciosi relativamente al piano che abbiamo presentato? E poi conta: < 1,2,3, votate! > Ogni membro del team vota nello stesso momento tenendo dalle 0 alle 5 dita alzate a seconda del livello di confidenza (dove 0 ĆØ “Non ne sono sicuro” e 5 ĆØ” Assolutamente, faremo faville! “).Ā Ā Se un membro del team tiene meno di tre dita, gli viene data l’opportunitĆ di esprimere le proprie preoccupazioni e la squadra può rispondere.Ā In Rosetta StoneĀ®, si guarda ai risultati di media. Se ci sono molti 1 e 2, si prende in considerazione la riprogrammazione e la revisione degli piani e obiettivi, ma non ĆØ richiesto che ogni membro voti dal 3 in su.
Day 4 e successivi: Jira Software e Portfolio for Jira
La settimana successiva, Todd, capo del PMO in Rosetta Stone®, conduce una breve retrospettiva per individuare ciò che è andato bene, cosa no e cosa potrà essere fatto meglio la prossima volta. In questo stadio, i team hanno già provveduto ad inserire sulle sprint di Jira Software, i piani individuati durante il meeting di PI, quindi Todd ed Eric possono creare una pianificazione di portafoglio utilizzando Portfolio for Jira.
Portfolio for Jira utilizza le board su cui lavorano i team in Jira Software come fonte di dati per redigere un piano multi-team, in modo da ottenere una visualizzazione di portafolio senza alcuno sforzo aggiuntivo, dal momento che ogni team fa giĆ le proprie pianificazioni. “Prima di avere Portfolio per Jira molte di quelle informazioni sulla board, anche se esistenti e disponibili, era difficile tenerle aggiornate o modificarle per riflettere meglio la realtĆ ”, ha detto Eric
Portfolio for Jira Live Plans: Rosetta StoneĀ® ĆØ una azienda pioniere diĀ Portfolio e nell’utilizzo dellaĀ funzione Live Plans, che carica i dati in maniera dinamica da Jira Software per una pianificazione in real-time. Con questa nuova esperienza di integrazione perfetta, ĆØ possibile creare istantaneamente un piano a partire dai dati esistenti in JIRA Software, e questo sarĆ sempre costantemente aggiornato.Ā Ā Seguendo la procedura guidata di impostazione rapida, Rosetta StoneĀ® può avere un piano di portfolio pronto all’utilizzo in meno di un minuto: basta connettersi alle board e ai progetti di Jira Software, selezionare le release di interesse, aggiungere i team e confermare lo scope. Ed ecco! Una pianificazione di portfolio viva!
Poco prima di andare Todd ha affermato che “far sƬ che più team progrediscano nella stessa direzione alla stessa velocitĆ ĆØ un problema incredibilmente difficile. L’agilitĆ scalata ci aiuta a risolvere questo problema in quanto ci dĆ visibilitĆ assoluta su tutti i team e ci aiuta ad andare avanti allo stesso ritmo. Utilizzando Jira Software, Portfolio per Jira e lo Scaled Agile Framework (SAFe) all’interno di Rosetta StoneĀ®, riusciamo a vedere cosa stanno facendo tutti i team in un preciso momento. Questo ĆØ estremamente importante quando si hanno numerose dipendenze tra team.”
Rosetta StoneĀ® chiama questa pianificazione “PI”, mentre in Atlassian la chiamiamo “quartely planning”; lo scopo rimane lo stesso: allineare tutti a livello micro e macro. Ciò ĆØ fondamentale per qualsiasi team o organizzazione di qualsiasi dimensione, e pone le basi per un approccio diĀ sviluppo software in agile che possa scalare.
Buona pianificazione!Ā
Try Portfolio for Jira free
diĀ Aimie Smith,Ā Product Marketing Team Lead @ Atlassian
traduzione di Davide Schillaci