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! 
di Aimie Smith, Product Marketing Team Lead @ Atlassian
traduzione di Davide Schillaci