Retrospettiva
Partiamo dalle parole dei principi sottostanti al Manifesto Agile [1]
A intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza.
Nell’ambito delle pratiche agili, questo principio è alla base della Sprint Retrospective come previsto dalle meccaniche Scrum e del concetto di retrospettiva agile in senso più ampio e generale.
Fedeli più allo spirito che alla lettera di quanto enunciato, abbiamo pensato che potesse essere il caso di “fare un tagliando” a Scrum, esattamente a due anni dalla pubblicazione dell’ultima versione della Guida Scrum [2], avvenuta proprio nel novembre del 2020.
Cambia tutto o non cambia niente?
Su queste pagine già era stata affrontata a suo tempo la questione [3] rilevando come in occasione dell’uscita della Guida Scrum versione 2020 ci fossero state reazioni contrastanti, che oscillavano tra chi affermava che nulla cambiasse, tranne qualche denominazione, e chi invece si era convinto che nelle poche pagine della Guida ci fossero invece stavolta dei cambiamenti anche sostanziali, seppur “mitigati” dalla stringatezza dello stile tipico della Guida.
A distanza di tempo, “facendo il tagliando” dopo due anni, credo si possano scrivere alcune considerazioni basate non solo sull’impressione del momento, ma anche su quanto è accaduto nella realtà della pratica di Scrum. Come detto nell’articolo citato [3], infatti: “Nella realtà aziendale, Scrum non è mai la pedissequa applicazione meccanica di quanto scritto nella Scrum Guide. La quale […] non ‘esaurisce’ Scrum in tutte le sue sfaccettature. […] Chi ‘fa Scrum’ nella realtà aziendale sa bene che, pur senza tradire affatto lo spirito (e la lettera) della Scrum Guide, in quel documento poi non ci sono scritte le tante competenze, le tante pratiche e strumenti, le tante esperienze che sono tutte necessarie per ‘far funzionare’ Scrum sul campo”.
Pertanto, i cambiamenti da verificare non sono tanto quelli riportati nel testo, ma soprattutto nella effettiva applicazione delle “regole del gioco” sul campo.
I cambiamenti ufficiali
Facciamo un breve riassunto schematico di alcune delle modifiche più significative apparse nella Guida Scrum ultima versione.
Ampliamento degli orizzonti di applicazione
Che si intenda spingere Scrum verso un’adozione da parte di realtà produttive non strettamente software è indicato fin dalle prime pagine della guida dove viene data notevole importanza ai valori di Scrum, citando peraltro esplicitamente la teoria Lean.
Mai come prima, inoltre, vengono ricordati e “inquadrati” gli stakeholder a rendere ancora più esplicita la realtà produttiva ampia verso cui si orienta adesso Scrum. Sempre meno “meccanica di base”, sempre più infrastruttura adatta a un ampio spettro di produdizioni nell’ambito dell’economia della “conoscenza”. C’è un certo svincolamento dal solo sviluppo software, tendenza peraltro già in atto da anni.
Svincolamento dallo sviluppo software
Conseguentemente a quanto scritto sopra, laddove nelle precedenti versioni della Guida Scrum si parlava sostanzialmente di Scrum come di un’infrastruttura metodologica per sviluppare software, adesso si parla di lightweight framework capace di supportare nella generazione di valore attraverso soluzioni adattative per problemi complessi.
Chiaro che questo riguardi ogni tipo di produzione immateriale — e, perché no, anche materiale in certi casi — e non solo lo sviluppo del software. Identica impressione si ricava dal fatto che, a parte la parola “developers”, non c’è più una terminologia strettamente legata al mondo informatico.
Relazione stretta tra Artifacts e Goals
Altro cambiamento che in molti hanno notato, e che in diversi hanno però trascurato, è stata l’istituzione di una relazione “schematica” tra i diversi Artifacts e un corrispettivo obiettivo (goal). In tal senso
- il Product Backlog prevede come impegno il Product Goal (concetto di nuova introduzione);
- lo Sprint Backlog prevede come impegno lo Sprint Goal;
- lo Increment prevede come impegno la Definition of Done.
Questo aspetto, che a molti è apparso esclusivamente teorico, ha in realtà avuto il merito di contribuire a definire meglio la stessa Definition of Done, specificandone l’ambito di applicazione precipuo, e di costruire una simmetria tra artifact e goal.
Ulteriori precisazioni sui “ruoli” dello Scrum Team
Una delle aree in cui le cose, almeno in teoria, sono cambiate più evidentemente è quella dello Scrum Team e dei “ruoli” che, tanto per cominciare, non si chiamano più così ma accountabilities cioè “responsabilità” il che non è solo un cambiamento di denominazione, ma un modo per specificare che chi svolge quel ruolo si assume anche le responsabilità ad esso connesso.
Viene poi specificato che l’intero Scrum Team è composto da 10 persone o meno.
In terzo luogo, dal momento che lo Scrum Team non prevede sottogruppi o “divisioni” o “compartimenti” — e questo è sempre stato specificato anche in passato — si sceglie, molto correttamente di ridefinire come Developers, cioè semplicemente “sviluppatori” quello che un tempo era il DevTeam. Non è nulla di più che una modifica “cosmetica” ma, d’altro canto, se non ci devono essere team secondari dentro il team principale non si capiva perché ci fosse un team di sviluppatori…
Quanto alle singole “responsabilità”, lo Scrum Master non viene più definito come servant leader, definizione che per molti anni ha rappresentato un po’ lo standard degli stili di leadership, nonostante altri approcci fossero possibili e ben documentati. Per il Product Owner viene enfatizzato il compito di rendere sempre ben presente il Product Goal a tutte le parti in gioco, senza ovviamente perdere di vista la cura del Product Backlog. Quanto ai Developers, oltre al già citato e corretto cambio di nome, si specifica che l’incremento completato a ogni Sprint deve essere di valore, utile e usabile: qualcosa di ovvio e già assodato per molte realtà, ma non ancora così esplicitamente enunciato.
Collaborazione e autogestione
Altro aspetto, forse più di facciata che non sostanziale, è quello rappresentato dal fatto che non si parla più di feedback — la parola è assente dal documento — mentre si insiste sul concetto di collaborazione.
Inoltre, al posto di parlare di un team autoorganizzato, si parla di uno Scrum Team self-managing cioè “autogestito”, vale a dire che chi fa cosa, quando e come viene deciso dai suoi componenti all’interno del gruppo.
Ciò che resta invariato
Ma, se in un contesto quacosa cambia, significa anche che qualcosa resta invariato. E forse su questo aspetto non ci si è concentrati abbastanza.
Da un lato ci sono degli aspetti che restano invariati anche ufficialmente, dall’altro ci sono degli elementi che non sono cambiati nella pratica, e il significato di questo secondo aspetto sarà specificato meglio più avanti. Guardiamo alcuni elementi invariati.
“Architettura”, regole e applicazioni di Scrum
È chiaro che certi concetti fondamentali non possono cambiare, altrimenti non saremmo più davanti a Scrum ma a qualcosa di diverso. Scrum resta un framework metodologico basato su un approccio iterativo e incrementale, declinato in maniera empirica, sulla base dei principi di ispezione, adattamento e trasparenza: e ci mancherebbe che questo cambiasse. Scrum, come descritto nella Scrum Guide, resta anche molto “scheletrico” nel senso che l’infrastruttura è decritta pienamente nei suoi elementi costituenti e nelle sue meccaniche di base, ma molti altri aspetti — ad esempio l’uso o meno di certi strumenti per la visualizzazione del processo, o le tecniche specifiche per condurre le retrospettive e così via — vengono lasciati alla libera iniziativa di chi adotta Scrum.
A fronte di questa “libertà”, resta tassativo l’invito a non adottare Scrum in maniera parziale prendendo solo qualche evento, magari modificandone la durata prescritta, o cambiando le attività delle diverse accountabilities oppure rinunciando a certi artifact. Nel caso lo si facesse, non si starebbero seguendo le “regole del gioco” e non si potrebbe dire di stare facendo effettivamente Scrum. Quindi, va bene un limitato livello di “personalizzazione”, laddove la Guida non specifichi l’argomento. Ma guai a “tradire” l’architettura ideale di Scrum o a eliminare elementi previsti, perché questo porterebbe a una metodologia che non è Scrum e che potenzialmente può rivelarsi inefficace.
Su questo aspetto — che forse è il più importante ed è quello su cui si può ragionare “a bocce ferme” due anni dopo l’uscita della Guida — torneremo nelle conclusioni.
Persone
Per quanto il framework Scrum sia importante, e sia adesso ancor meglio specificato, la sua applicazione vive e fiorisce nella concreta implementazione che ne faranno le persone. Se chi vuole applicare Scrum non sposa i valori e principi enunciati nella Guida, non ha una approfondita conoscenza delle meccaniche di base e non si assume le responsabilità insite nel suo ruolo… Scrum non funzionerà perché non si tratta di una formula magica o di un evento miracoloso.
Per quanto possa risultare scontato, questa è una verità invariata ormai da almeno un paio di decenni
Scrum Team e Accountabilities
Abbiamo già parlato delle novità e di come alcuni dettagli siano stati meglio speficicati, sia in termini formali che sostanziali. Tuttavia, alcuni dei cambiamenti sono stati fatti proprio per ribadire meglio, ad esempio, quel che si è sempre detto, ossia che nello Scrum Team non ci sono sottogruppi, non c’è una gerarchia, e che i suoi componenti hanno competenze cross-functional.
E non cambiano caratteristiche e compiti fondamentali del Product Owner, a partire dal fatto che resta una singola persona — non un comitato — ed è responsabile della massimizzazione del valore del prodotto. Nonostante i cambiamenti alla tipologia di leadership in cui lo si inquadra, non cambia per lo Scrum Master la responsabilità di rimuovere gli impedimenti, tanto facile da enunciare, molto più complessa da mettere in pratica.
Eventi
Altro aspetto fondamentale di Scrum, che probabilmente non cambierà mai, è il fatto che gli eventi sono time-boxed, ossia limitati a una precisa durata temporale, e collocati in una ben definita scansione cronologica.
E non cambia il fatto che gli eventi contenuti nello Sprint (Sprint Planning, Daily Scrum, Sprint Review e Sprint Retrospective) restano eventi collaborativi. Se così non fosse, non sarebbe Scrum.
Artifacts
Come visto sopra, si è ben specificata la corrispondenza tra artifact e rispettivo goal, ma questo non ha mutato certe caratteristiche dei singoli “manufatti”. Il Product Backlog resta — e resterà — la fonte delle attività che vengono intraprese nel corso dei vari Sprint. E ci fermiamo qui per non ripetere l’ovvio.
Conclusioni
Conclusioni non significa che l’articolo è finito. O meglio sì, ma non avrebbe senso non trarre delle conclusioni e sollevare anche degli interrogativi.
Passando dalla teoria alla pratica, quel che si è potuto notare è che in certi casi molte delle novità introdotte due anni fa sono passate abbastanza inosservate: si vede ancora, in certi casi, introdurre Scrum nei gruppi di lavoro con la terminologia e l’approccio precedenti al 2020, quando non succede ancora di peggio.
Da un lato questo è comprensibile: alla fine ciò che conta trasmettere sono certi meccanismi di base e se parliamo ancora di Dev Team invece che di Developers, poco cambia. Così come se si ricorre ancora alla metafora del servant leader per lo Scrum Master. E va anche detto che chi veramente applica Scrum in azienda, deve necessariamente andare oltre la Guida Scrum, apportare quelle “personalizzazioni” — non tagli o stravolgimenti — che proprio l’ufficialità delle “regole del gioco” consente e favorisce. Quindi è probabile che in pochi si limitino ad applicare Scrum solo come descritto nella Guida, dove ad esempio non si parla assolutamente di come fare uno Sprint Planning nel concreto, con le varie tecniche di stima per “pesare” le storie, né tantomeno si suggerisce l’adozione di una lavagna in stile Kanban per gestire il flusso di lavoro durante lo Sprint.
Ma da un altro lato, chi ha il compito di formare le organizzazioni e le persone al framework Scrum non dovrebbe mancare di cogliere, dopo due anni, il fatto che alcune sottili differenze introdotte dalla versione 2020 della Guida Scrum non sono solo dettagli “nominali”. Sono infatti, per ora, il punto di arrivo di un lungo processo cominciato embrionalmente circa trent’anni fa, e che va trovando la precisazione della sua definizione in modo empirico.
Scrum non ha più quell’alone di rivoluzionaria novità che poteva avere nelle sue implementazioni iniziali, quando era materia per pochi sviluppatori software particolarmente aperti alle novità “ideologiche” e alla ricerca di un modo più efficace per lavorare. Scrum è diventato “industria” nel senso che ormai viene adottato nei processi di produzione più disparati. E questi cambiamenti, compresa la necessità di precisare quanto poteva lasciare adito a interpretazioni fuorvianti, o di schematizzare — pure troppo — certi elementi in maniera che sia più facile la loro comprensione e la loro messa in pratica, fanno parte del processo.
Non sappiamo quando la nuova versione della Guida verrà pubblicata, né quali eventuali modifiche saranno apportate. Quel che ci auguriamo è che valori, principi, struttura e meccaniche di Scrum vengano aggiornate sempre partendo dall’esperienza di chi applica questo framework medologico nella realtà della produzione.
Riferimenti
[1] Manifesto per lo Sviluppo Agile di Software
https://agilemanifesto.org/iso/it/principles.html
[2] Scrum Guide
https://scrumguides.org/scrum-guide.html
[3] Francesco Saliola, La nuova Guida Scrum. Niente di nuovo o cambiamento sostanziale? MokaByte 267, dicembre 2020
https://www.mokabyte.it/2020/12/16/scrumguide2020/
Luigi Mandarino ha cominciato ad appassionarsi ai computer con il glorioso ZX Spectrum 48k: una bomba, per l‘epoca 🙂 Dopo gli studi di ingegneria, si è dedicato per diversi anni allo sviluppo di applicazioni Java, specie per la piattaforma Enterprise. Successivamente, ha svolto il ruolo di architetto dei sistemi interessandosi particolarmente alle architetture di integrazione. Attualmente, svolge consulenze a svariate aziende in particolare nel settore bancario, assicurativo e finanziario, principalmente su temi inerenti le architetture Java EE e le dinamiche di processo secondo un approccio Lean/Agile.