Molto rumore per nulla?
La recente pubblicazione della nuova Guida Scrum nella penultima settimana dello scorso novembre ha suscitato attenzione e dibattito. Ed è giusto così, dal momento che Scrum rappresenta un po’ la pratica più tangibile e diffusa del più ampio panorama Agile. In molte realtà produttive, diventare agili equivale ad adottare Scrum come infrastruttura metodologica nel lavoro dei team, anche se poi sappiamo bene che quest’equazione è tutt’altro che vera.
Ad ogni modo, una novità che riguardi specificamente Scrum è un fatto importantissimo nell’ambito Agile ed è quindi normale che, a seguito della presentazione della nuova versione della Scrum Guide [1], ci siano state numerose e variegate reazioni.
La cosa “buffa” è che tali commenti — a volte semplici battute su Twitter scritte forse più per il gusto del salace epigramma che per una reale valutazione del testo, a volte articoli più ampi e strutturati —, sono tranquillamente oscillati tra i due estremi del “Ma, in fondo, son solo modifiche sui termini da usare: in sostanza non è cambiato nulla” al “Ma qui sono cambiate tante cose significative”.
Oltretutto, nei sostenitori di questa seconda opinione, ci si è ulteriormente divisi in “Scrum è cambiato. In meglio” e “Scrum è cambiato. In peggio”. Insomma, se fossimo nell’Italia ai tempi di Dante Alighieri, potremmo parlare di Ghibellini, Guelfi neri e Guelfi bianchi… tanto per non farsi mancare nulla.
Senza tergiversare oltre, ci iscriviamo al partito di quelli che pensano che in questa nuova Guida Scrum, dei cambiamenti anche significativi ci siano eccome. Ma capire quali siano i motivi profondi, la portata e le ripercussioni concrete di tali cambiamenti è un discorso più ampio che merita sicuramente qualche parola in più.
Dal testo alla realtà
Diciamolo chiaramente: per quante modifiche, alcune anche sostanziali, si vogliano trovare alla definizione e alla meccanica di Scrum nella Scrum Guide edizione 2020 rispetto alla precedente del 2017, un conto è discutere di un testo, per quanto importante esso sia, un altro paio di maniche è considerare la effettiva applicazione delle “regole” riportate in quel testo una volta che si scenda al livello dell’implementazione pratica.
Nella realtà aziendale, Scrum non è mai la pedissequa applicazione meccanica di quanto scritto nella Scrum Guide. La quale, per quanto sia davvero ben fatta e sintetica, resta comunque un documento di poche pagine (19 nella versione 2017, addirittura solo 13 nella nuova edizione) che fornisce sicuramente un ben preciso riferimento da seguire, ma 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.
La Guida Scrum resta un riferimento, ma Scrum si apprende studiandolo anche su altri testi, sperimentandolo con formazione esperienziale e workshop, “praticandolo” nel proprio ambito e guardando anche a cosa fanno altri in ambiti diversi e, infine, sottoponendo tutto questo a un processo di critica e revisione, in un’ottica di miglioramento continuo.
Il partito del “nulla cambia”
Tutto questo per dire che coloro che hanno liquidato sbrigativamente la Scrum Guide 2020 dicendo che, in concreto, nulla cambia, forse un motivo di ragione ce l’hanno. Ed è proprio il fatto che, indipendentemente da questo testo, Scrum si concretizza nella realtà lavorativa quotidiana, con i team, sui progetti, attenti a non stravolgerne i principi e le meccaniche, ma anche consapevoli che un certo grado di adattamento alla peculiare realtà in cui si opera è inevitabile.
Del resto, fermo restando il valore della infrastruttura metodologica e dell’organizzazione dei contenuti della Guida Scrum, si fa Scrum per migliorare il processo di produzione di qualche bene o servizio, non per seguire i precetti di un “testo sacro” che, a tutti gli effetti, la Scrum Guide non è…
Ma ci sono cambiamenti, allora?
Riconosciamo quindi che non basta cambiare un po’ di frasi in un “manuale” affinché, di conseguenza e con rapidità, cambi anche l’applicazione pratica di quel che si faceva fino a una settimana prima, nelle realtà aziendali.
Ma è pur vero che in questa nuova Guida Scrum i cambiamenti ci sono, sono intenzionali, anche come “visione” globale di Scrum, e non sono solo piccoli aggiustamenti. Se questi cambiamenti non fossero così evidenti e “pesanti”, nessuno si sarebbe spinto a parlare addirittura di un ritorno quasi al waterfall [3].
Eppure non è la prima volta che qualcosa cambia: dalla prima versione del febbraio 2010 all’attuale settima versione di novembre 2020, sono passati dieci anni in cui tante cose sono cambiate, in generale, nel mondo Scrum e nella Guida stessa [4].
Ci sono state tappe, come la seconda versione (luglio 2011), molto importanti perché segnarono l’introduzione dei classici ruoli di Product Owner, Scrum Master e Development Team, e tappe che hanno rappresentato solo un minimo aggiustamento, come nella terza versione dell’ottobre 2011. Ci sono state poi versioni della guida, come la quinta (luglio 2016) che pur non cambiando nulla in termini di “meccaniche” di Scrum, hanno introdotto concetti importanti, quali i “valori di Scrum”, insistendo sul fatto che rispetto, impegno, concentrazione, apertura e coraggio rappresentavano il punto di partenza per far sì che i team Scrum potessero svolgere proficuamente le loro attività.
Con questa settima versione, siamo di fronte a una delle edizioni che apporta maggiori e più significativi cambiamenti, sia in termini “ideologici” che di meccanica. Anche qui, però, capiamoci: non è che venga stravolto tutto; non è che Scrum diventi Kanban…
Una nota sulle traduzioni
Oltre che nella versione originale in americano, la Scrum Guide è disponibile in numerose altre lingue, compreso ovviamente l’italiano [5]. A parte l’ormai annoso problema di insistere a voler erroneamente tradurre il termine americano artifact (= “manufatto”) con “artefatto” (che in lingua italiana significa però “risultato spurio” o, come aggettivo, “falsato”, “manomesso”), i traduttori italiani questa volta si sono dovuti confrontare con una serie di ulteriori problemi e hanno fatto, in molti casi, la scelta comprensibile di non tradurre certi termini e di lasciarli in inglese per favorire una maggiore condivisione del gergo di Scrum.
Certe scelte di traduzione, poi, assolutamente corrette sul piano linguistico e sostanziale — e, per quel nulla che conta, totalmente condivise anche da chi scrive — sortiscono però un effetto “strano”: quando, per rendere self-managing e self-management, vengono — correttamente, lo ribadiamo — usati i termini “autogestiti” e “autogestione”, l’effetto che si ottiene è più quello di pensare a un Centro Sociale Occupato e Autogesito degli anni Novanta, che non a un’azienda del terziario avanzato, ma tant’è… L’opera di traduzione non è mai facile, e di questo dobbiamo dare sempre atto a chi se ne assume il compito meritorio.
Qualche cambiamento degno di nota
Veniamo quindi ad analizzare alcuni dei cambiamenti presenti nella Guida Scrum, settima versione (novembre 2020). Non faremo un’analisi esaustiva, anche perché c’è chi si è già preso la briga di farla [6] ma vedremo alcuni dei punti salienti, con qualche considerazione.
In generale
Uno dei primi aspetti che colpisce in questa versione 2020 della Guida Scrum è la sua stringatezza. Rispetto alla versione precedente, che ne aveva 19, adesso le pagine sono solo 13. Questo ha un significato: se si sceglie di ridurre all’osso le informazioni contenute nel documento, si sta anche dicendo che quel poco che c’è è fondamentale. Non ci sono più certe spiegazioni, certe riflessioni, ma quel che è rimasto, in alcuni casi decisamente riformulato, assume ancora più valore. I concetti sono condensati, non diluiti, e questo fa assumere loro ancora maggior densità.
Accanto a questa generale maggiore sintesi, c’è un linguaggio generalmente più semplificato — a tratti addirittura schematico — e un minor legame con il mondo specificamente IT: Scrum è diventata un’infrastruttura metodologica utilizzabile da un più ampio “pubblico” per la produzione di beni e servizi non strettamente legati al mondo del software.
Lean Thinking
Stavolta c’è davvero. Il paragrafo La teoria di Scrum comincia con la frase “Scrum si basa sull’empirismo ed il pensiero Lean”. Il Lean Thinking, rielaborazione americana delle pratiche Toyota di ascendenza giapponese, è dichiaratamente accolto negli elementi costitutivi di questa infrastruttura metodologica. Del resto, per quanto lo sviluppo agile del software volesse essere un ulteriore passo in avanti rispetto a ciò che, in senso lato, era la produzioni “lean”, quel pensiero, quell’ispirazione ha sempre permeato molte pratiche che oggi raccogliamo sotto il vasto ombrello dell’agilità. Questo cambia qualcosa a livello di meccanica? Ma certamente no. Però a livello “ideologico” il passo non può essere ignorato.
“Abolizione” dei ruoli e introduzione delle accountabilities
Molte e significative sono le modifiche che riguardano quelli che fino a oggi abbiamo comunemente chiamato ruoli nello Scrum Team, ossia le figure del Product Owner, dello Scrum Master e del DevTeam.
Anzitutto, scompare — molto giustamente a parere di chi scrive — la definizione di Development Team, che viene sostituita da quella di Developers. A livello pratico cambia poco, ma, se da un lato si era sempre detto che all’interno dello Scrum Team non esistevano gerarchie e sottogruppi, poi non si capiva perché dentro il team Scrum ci fosse invece il team di Development. Parlare quindi di “sviluppatori”, e non più di Development Team, è un passo intelligente verso la chiarezza e la semplificazione, seppur si tratti solo di un cambiamento di “etichetta”. Adesso davvero si può dire che, all’interno dello Scrum team non sono previsti sottogruppi: ci sono il PO, lo SM, i developers.
Ma se questa vi sembra solo una modifica “cosmetica”, con la seconda forse vi ricrederete: infatti il termine “ruolo” viene sostituito da “responsabilità” (accountability). Va notato che il termine scelto in inglese, accountability, ha una sfumatura un po’ diversa rispetto al sinonimo resposibility: la accountability è, più o meno, la responsabilità rispetto ai risultati prodotti, e non una responsabilità in senso lato o di tipo “morale”. Quindi, quando la Guida Scrum dice “Scrum definisce tre specifiche responsabilità all’interno dello Scrum Team: i Developer, il Product Owner e lo Scrum Master” il termine responsabilità ha un significato ben chiaro di accountability.
Spingendoci ancor più in là, questo cambiamento da roles ad accountabilities indica anche che PO, SM e developers vengono identificati un po’ di più per le responsabilità che si assumono nel processo che non per il fatto di rientrare nei canoni di una determinata “figura professionale”. Possono sembrare, anche queste, disquisizioni filosofiche, ma l’intenzione della Guida Scrum in tal senso è chiara. Non si interpreta una parte in una rappresentazione, ma ci si assume una responsabilità in un processo produttivo.
E infine, sempre rimanendo nell’ambito dei vecchi “ruoli” che adesso sono “responsabilità”, lo Scrum Master vede un riaggiustamento nella sua vecchia definizione: non è più un servant leader ma è un leader “vero”. In questo ha probabilmente influito la considerazione che la concezione, peraltro interessante e valida, della servant leadership in voga qualche anno fa e inglobata in Scrum, è stata affiancata e sostituita prima da quella della host leadership e, successivamente, da un’ancor più globale e funzionale leadership situazionale. Per non stare a inseguire tendenze e stili di leadership, con quel termine di “vero leader” ci si è probabilmente concentrati sul fatto che lo Scrum Master deve conoscere il tema della leadership e saperla esercitare, con il corretto stile adattato alle diverse situazioni.
Le altre funzioni e responsabilità dello Scrum Master nei confronti di PO, developers, e organizzazione aziendale in generale restano invariate, ma l’affermazione “Lo Scrum Master è responsabile dell’efficacia dello Scrum Team” nella versione precedente non c’era… e questa affermazione così perentoria ad alcuni è sembrata spostare un po’ la collocazione ideale dello SM da un ambito di Agile Coach più verso quello di Project Manager classico…
Autogestione!
Abbiamo già accennato al cambiamento del termine “autoorganizzato” (self-organizing) in quello di “autogestito” (self-managing). Anche qui, non è solo una modifica di una “etichetta” quanto piuttosto un cambiamento volto a specificare meglio che gli Scrum Team “decidono al loro interno chi fa cosa, quando e come” e non solo genericamente il modo migliore per completare il loro lavoro.
In quest’ottica di maggiore “autonomia organizzata” possiamo far rientrare la definitiva scomparsa delle tre canoniche domande da porsi durante il Daily Scrum, il breve incontro da ternersi tutte le mattine, stando in piedi, per iniziare la giornata di lavoro. Sebbene già non fossero più “obbligatorie”, ma solo un esempio per procedere, nella versione 2017 erano sempre presenti le tre domande che gli sviluppatori si ponevano a riguardo dell’obiettivo di quello sprint da raggiungere come DevTeam (“Cosa ho fatto ieri…?”, “Cosa farò oggi…?”, “Quali impedimenti ho incontrato…?”). Nella nuova Guida Scrum 2020, tali domande non sono più presenti e il Daily Scrum viene concepito meno come “cerimonia” con una struttura preimpostata e più come un evento focalizzato alle azioni applicabili quel giorno per raggiungere il progresso verso l’obiettivo dello sprint, in cui gli sviluppatori possono scegliere liberamente struttura e tecniche per condurlo nel modo più adeguato a tale scopo.
Modifiche agli eventi
Visto che abbiamo toccato il tema del Daily Scrum, continuiamo a parlare di eventi: la quantità e la struttura generale degli eventi restano invariate, ma vengono riformulate alcune definizioni per fornire un quadro più schematico e preciso.
C’è un evento “contenitore” (lo Sprint) all’interno del quale si svolgono tutti gli altri quattro eventi: lo Sprint Planning a inizio Sprint, il Daily Scrum ogni giorno, la Sprint Review come dimostrazione e valutazione di quanto realizzato in quello Sprint e la Sprint Retrospective a chiusura del ciclo, in un’ottica di miglioramento continuo. Quindi, nella sostanza nulla cambia.
In realtà, ci sono dei piccoli aggiustamenti e qualche modifica. In particolare, come punto da discutere nello Sprint Planning, viene preposto un “Argomento uno: perché questo Sprint è di valore?” al cosa e al come già esistenti (“Argomento due: cosa si può fare in questo Sprint?”, “Argomento tre: come si svolgerà il lavoro scelto?”). Non sarà uno stravolgimento alla meccanica di Scrum, ma il fatto che, nello Sprint Planning, lo Scrum Team si interroghi esplicitamente anche sul perché si svolgerà quello Sprint è una modifica che, oltre forse ad aggiungere un po’ di complessità, potrebbe però garantire anche una migliore visione globale di ciò che si sta facendo.
Modifiche agli artifacts
Qualche modifica è prevista anche per gli artifacts. La loro concezione viene maggiormente schematizzata, in particolare con la ridefinizione del valore del commitment (= “impegno”) in modo tale che, a ciascun “artefatto” sia associato un corrispondente “impegno per assicurare che esso fornisca le informazioni che accrescano la trasparenza e la concentrazione in base alle quali possa essere misurato l’avanzamento:
- per il Product Backlog esso è il Product Goal.
- per lo Sprint Backlog esso è lo Sprint Goal.
- per l’Increment esso è la Definition of Done.”
Viene messo in luce che lo Scrum Team adesso deve allineare lo Sprint Goad al Product Goal in tutte le iterazioni: a un più vago concetto di “visione” che era presente nella versione precedente, viene sostituito un più concreto “obiettivo di prodotto”.
Conclusioni
A voler continuare con la nostra esegesi, altre modifiche, meno sostanziali ma comunque presenti, si potrebbero trovare. Concludiamo con due considerazioni.
La prima è che in questa edizione 2020 convivono sia scelte in direzione di un maggiore schematismo, che ad alcuni è apparso come un irrigidimento, sia decisioni che invece rimuovono definitivamente alcune strutture preimpostate presenti nelle edizioni precedenti e anzi spingono in direzione di una maggiore “autogestione”. Questa può essere una delle ragioni per cui le reazioni alla nuova Guida Scrum sono oscillate tra “Scrum vira decisamente da una parte”, “Ma no! Scrum va nella direzione completamente opposta!”.
Quanto a coloro che non hanno riscontrato serie differenze, è probabile che abbiano un po’ anche voluto sospendere il giudizio, in attesa di un po’ di mesi di applicazione reale sul campo delle novità che innegabilmente ci sono. Solo così, nella realtà produttiva, sarà possibile finalmente valutare con il tempo l’impatto concreto di tali modifiche, e decidere se si tratta solo di piccoli aggiustamenti o di significative modifiche. Del resto, non vogliamo che l’ispezione e l’adattamento restino solo teoria.
A MokaByte mi occupo dei processi legati alla gestione degli autori e della redazione degli articoli. Collateralmente, svolgo attività di consulenza e formazione nell‘ambito dell‘editoria "tradizionale" e digitale, della scrittura professionale e della comunicazione sulle diverse piattaforme.