Specificità del lavoro di una squadra Agile in SAFe rispetto a Scrum nella pratica

Dopo la pubblicazione tra gli amici del primo articolo sul Burn Down Chart, nei commenti la prima domanda che è stata posta: "Sarebbe interessante saperne di più sulla vostra esperienza con SAFe". Perciò, in questo articolo cercherò di illustrare le specificità del lavoro in SAFe rispetto a Scrum nella nostra pratica. Non pretendo certo di essere depositario della verità e sarò felice di ricevere qualsiasi correzione e precisazione da parte dei colleghi.

Innanzitutto elencherò per punti le cose più importanti che, a mio parere, distinguono il lavoro in SAFe da SCRUM.

• Increment in Scrum e Program Increment in SAFe
• ART - Agile Release Train
• Numero di team che interagiscono
• PIPE
• SOS
• PO - non è proprietario del business
• RTE
• Il quinto sprint per la formazione
• System Demo

Increment in Scrum e Program Increment in SAFe. In realtà sono termini diversi, ma è facile confondersi perché nessuno da noi usa il termine Program Increment, tutti dicono semplicemente Increment - che è già un altro termine, usato in SCRUM. Ma nel complesso sono abbastanza simili dal punto di vista del significato, a mio parere. Increment in SCRUM è in sostanza il prodotto attuale + le storie pianificate per lo sprint in stato completato (che hanno superato il DOD del team). Program Increment è l'intervallo di tempo durante il quale il treno (Agile Release Train) consegna valore incrementale in produzione. In termini di durata da noi sono 4 sprint da 2 settimane per lo sviluppo e uno sprint per la formazione.

Agile Release Train - è un team di team che lavorano su un unico flusso di creazione di valore. Noi lo chiamiamo semplicemente treno, ma secondo il framework la denominazione corretta è "Solution". Nel nostro caso, questa regola non è pienamente rispettata e i team spesso lavorano su prodotti diversi dal punto di vista tecnico, poiché la maggior parte delle funzionalità di business viene realizzata in modo complesso e coinvolge più prodotti. Questo dal punto di vista tecnico. Ma sono certo che qualcuno consideri tutti i sistemi IT come un unico prodotto dell'azienda e, forse, sia anche più corretto.

Numero di team che interagiscono in SAFe da noi è sostanzialmente maggiore, in totale si raccomandano fino a 125 persone in un solo treno. Noi abbiamo 3 treni e non in tutti questa regola è rispettata, ci sono treni con più di 125 persone. SCRUM non descrive come interagire con gli altri team, per quanto ne so, a differenza di SAFe, dove ci sono raccomandazioni molto chiare al riguardo. L'artefatto più evidente, a mio parere, per questo è il Program Board.

Su di esso vengono mostrate le interdipendenze tra i team del treno e, discutendolo, si svolgono gli eventi settimanali Scrum Of Scrums (SOS) da noi.

Circa ogni 2,5 mesi (ogni 5 sprint) avviene l'evento PIPE - Programm Increment Planning Event. È quando tutti i team distribuiti si riuniscono in un'unica sala per 2 giorni e pianificano il proprio lavoro per i successivi 2,5 mesi. Nel corso di questo evento emergono artefatti come il Program board, ad esempio, sul quale vengono mostrate tutte le dipendenze dei team tra loro per ciascuno dei treni, sopra ho già mostrato come appare. Il compito dello Scrum Master di ogni team in questo evento è la facilitazione dell'individuazione del massimo numero di dipendenze, poi, ove possibile, la loro rimozione (mediante il trasferimento di competenze oralmente, ad esempio, da un team a un altro o mediante l'assorbimento di una dipendenza da un team all'altro, affinché il team possa realizzare autonomamente la propria funzionalità senza dipendere da nessuno). In pratica da noi avviene proprio così. Prima le funzionalità vengono decomposte in User Story, le User Story vengono distribuite su 4 sprint. Le funzionalità vengono collocate sul Program Board e vengono indicate le dipendenze da altri team esistenti. Nel corso dell'evento questo viene discusso e corretto.

SOS - Scrum Of Scrum. Questo evento si svolge una volta alla settimana per ciascun treno separatamente. Gli Scrum Master di tutti i team del treno si riuniscono online, viene trasmesso il Program Board del treno e vengono discussi gli stati di tutte le dipendenze e funzionalità dei team del treno specifico. In sostanza questo evento è necessario per la sincronizzazione centralizzata dei team all'interno del treno. Qualcosa come uno standup, ma una volta alla settimana e non per il team, ma per gli Scrum Master.

PO (Product Owner) - non è proprietario del business. C'è il Product Manager - che lavora con i Business Owner delle corrispondenti aree di business e in sostanza distribuisce le funzionalità ai Product Owner. Il Product Owner lavora già direttamente nel team - suddivide le funzionalità in User Stories (nel nostro caso insieme al team) e non sempre le suddivide, ma progrediamo costantemente in questa direzione.

RTE (Release Train Engineer - capotreno. Scrum Master degli Scrum Master. Conduce gli eventi SOS del proprio treno. Interagisce con il Product Manager a livello di feature. Facilita il PIPE.

Il quinto sprint per la formazione - sì, a differenza di Scrum, qui alla squadra viene dedicato un intero sprint alla fine dell'incremento per la formazione. Noi, di norma, in pratica lo utilizziamo innanzitutto per frequentare corsi di formazione interni, anche su SAFe, ma non solo. Cerchiamo di pianificare corsi privati e meetup in questo periodo quando possibile. Inoltre abbiamo sviluppatori che ampliano il proprio stack durante il 5° sprint, per poter coprire la competenza di qualcun altro nel team (fare da backup se necessario).

System Demo. Di conseguenza al PIPE ogni squadra ha un elenco di obiettivi per l'incremento e ciascuno di questi obiettivi è valutato dal Business Owner del treno su una scala da 10 punti. Questo si chiama Business Value. Questi obiettivi si dividono in principali ed estesi. Gli obiettivi principali sono quelli in cui la squadra non vede alcun rischio nel raggiungimento. Gli estesi sono obiettivi con rischi di raggiungimento. Tutti gli obiettivi sono obbligatori e il volume di lavoro è pianificato per tutti gli obiettivi. Alla System Demo il Business Owner accetta i risultati del lavoro per l'incremento. Supponiamo che la squadra avesse 3 obiettivi principali con valutazioni 10, 6, 8 e 2 estesi con valutazioni 10, 3. Immaginiamo che il Business Owner abbia assegnato rispettivamente le seguenti valutazioni: 8, 6, 4, 2, 0. Ora si può calcolare la percentuale di raggiungimento degli obiettivi: come 100% si prende la somma iniziale dei punti per gli obiettivi principali, nel nostro caso 10+6+8=24. I punti raggiunti si calcolano tenendo conto degli obiettivi estesi (cioè 20 su 24 la squadra ha raggiunto), quindi di conseguenza la percentuale di raggiungimento degli obiettivi della squadra sarà (20*100)/24 = 83,3%. Un risultato normale è considerato il raggiungimento dall'80% al 100%.

In tutto il resto lavoriamo secondo SCRUM. Beh, o quasi in tutto :) Per quanto riguarda la nostra esperienza: posso dire che, dal mio punto di vista, l'evoluzione è evidente. In un anno di lavoro le squadre sono cresciute molto, sono diventate auto-organizzate, alcune squadre, è vero, si sono sciolte, ma anche in questo si intravede una certa evoluzione. C'è ancora spazio per crescere.

Commenti dei colleghi da facebook

«Ženja, ciao! È fantastico che tu scriva, bravo! Correggerò un po' la parte sui treni - non si formano attorno al prodotto, ma attorno al flusso di creazione del valore. E nel retail, dal punto di vista di SAFe, il nostro non è un treno, ma una Solution. Solo per comodità di comunicazione e semplificazione della comprensione, continuiamo a chiamarlo treno)»

– Konstantin Voronin (rappresentante dell'ufficio progetti di Ingosstrakh)

«Beh, e magari qualcuno noterà che dal punto di vista di SAFe la valutazione degli obiettivi avviene all'I&A; (dove la SD entra come parte, ma non è direttamente collegata alla valutazione) e le SD stesse dovrebbero avvenire ogni sprint (dopo le demo delle squadre). Ma noi siamo ancora lontani da questo, quindi consapevolmente chiamiamo tutto come è scritto nel tuo articolo)»

– Konstantin Voronin (rappresentante dell'ufficio progetti di Ingosstrakh)

«Ženja, continua, per favore, è molto utile!»

– Aleksej Ionov (Trainer certificato SAFe)