La Guida Scrum, un testo che si evolve

Nel 2020 è stata pubblicata quella che ad oggi è l’ultima versione della Guida Scrum [1], in cui sono stati inseriti alcuni cambiamenti che possono apparire piccoli nella forma ma che a mio parere sono invece fondamentali nella sostanza.

Quando la guida uscì su MokaByte pubblicammo alcuni articoli [2] [3] in cui analizzavamo quanto c’era di differente nei singoli passaggi che la componevano.

A distanza di quasi tre anni, provo a riprendere in mano “le sacre scritture” per vedere a posteriori e con spirito critico cosa è successo in quelle aziende che in questi anni hanno provato a portare Scrum all’interno delle loro organizzazioni.

Sebbene la nuova versione della guida sia divenuta meno prescrittiva, riducendo il numero di regole e delle pratiche operative, al contempo ha aumentato la profondità del significato trasmesso, rendendo probabilmente Scrum più impegnativo da comprendere e più complesso da implementare.

La mia personale esperienza è un po’ pessimista in questo senso: spesso vediamo aziende che ragionano ancora in termini di regole, procedure, ruoli, mansioni, strumenti, mentre i due autori hanno spinto molto sul cambiamento di mentalità necessario per fare Scrum.

Per quello che ho potuto osservare mi sento di dire che la maggior parte delle aziende con cui ho lavorato non abbia compreso questa evoluzione: molte sono  concentrate a dare una interpretazione meccanica delle regole, dei ruoli e delle pratiche, limitandosi a implementarle pedissequamente senza, forse, comprenderne il reale significato.

In questa miniserie di articoli condividerò alcuni dei passaggi del testo che mettono in luce questa “evoluzione filosofica” della guida, e rifletterò su quanto questa abbia messo in luce ancora di più l’approccio cargo cult [4] di certe aziende.

Scrum oggi

A tre anni dalla pubblicazione, osservo come  molte aziende e organizzazioni facciano ancora fatica a comprendere il reale impatto che la guida suggerisce, limitando il lavoro di trasformazione  sui “fattori estetici” — i nuovi ruoli, le nuove riunioni e i nuovi strumenti suggeriti da Scrum — per mezzo di un lavoro che viene percepito già di per sé come impegno piuttosto gravoso, sia in termini organizzativi che operativi; il risultato è che spesso si perde di vista la vera e più profonda necessità di lavorare a un livello più profondo.

Per esempio la nuova versione della guida pone l’accento sulle responsabilità — più che su ruoli e competenze — che servono per sviluppare prodotti, lasciando intendere in modo chiaro la necessità di curare queste competenze tramite un percorso definito e continuo di apprendimento, di presa di coscienza e di responsabilità. Non si tratta quindi solamente di introdurre nuove figure all’interno dell’azienda, ma anche di cambiare approccio nel processo di gestione del percorso di carriera.

Product Owner e Scrum Master: oltre il ruolo

Se da un lato infatti il Product Owner viene presentato come una figura chiave per l’organizzazione, da curare e supportare con percorsi specifici che durino nel tempo, dall’altra si vede sempre più marcata la tendenza a voler creare dall’oggi al domani dei PO — spesso temporanei, finché c’è da sviluppare il progetto — magari attingendo dal bacino dei Project Manager in modo estemporaneo senza una strategia di cura e supporto alla crescita di queste figure.

E per gli Scrum Master la situazione non è migliore: il compito dello SM è supportare il processo di adozione delle metodologie agili ponendosi come interlocutore credibile ed efficace nel suo lavoro con tutti i livelli dell’azienda, non solo con i colleghi dello Scrum Team. Per questo motivo lo  Scrum Master deve essere una figura interna dell’azienda, non un consulente esterno coinvolto a seconda del fabbisogno del singolo progetto. Purtroppo spesso nelle aziende, partendo dal presupposto che serve introdurre questa nuova figura in azienda, si finisce per “affittarlo” come si fa con un qualsiasi altro membro di un team contrattualizzato in body rental con fornitori esterni.

La politica di superficie

Se da un lato quindi si è presa coscienza della necessità di un cambiamento in azienda per poter continuare a essere competitivi, e quindi sopravvivere, in un contesto di forte e continuo cambiamento, di incertezza e volatilità (VUCA), dall’altro si è ormai compreso come Agile possa essere lo strumento per guidare questa trasformazione non più rimandabile.

Quando si parla di cambiamento, purtroppo osserviamo spesso una tendenza a ricercare la soluzione rapida, la tattica che dia risultati sul problema di oggi, senza affrontare a livello strutturale il vero punto di debolezza sistemica (strategia).

Questa “politica di superficie” è tipica di un certo modo di fare impresa ed è messa ancora più in luce dalle nuove indicazione di Scrum che rimarca la necessità di cambiamenti più profondi e impattanti.

Agile Washing

La guida 2020 spinge significato di portare Agile in azienda, evidenziando come spesso i processi messi in atto non siano altro che operazioni di facciata: è il cosiddetto effetto Cargo Cult o Agile Washing. Questo termine è diventato ormai di uso comune ed è stato coniato ispirandosi al concetto di Green Washing:, si adottano misure di facciata che sembrano migliorare la sostenibilità ecologica, ma poi in sostanza tutto resta inquinante come prima…

Tutto ciò mi fa tornare alla mente una vecchia metafora usata per spiegare il processo di introduzione dell’Agile in una organizzazione: quando si toglie l’acqua a un laghetto, man mano che il livello si abbassa, affiorano le pietre presenti sul fondo; erano presenti anche prima e forse erano pericolose per la navigazione, ma non se ne aveva percezione proprio perché nascoste dall’acqua.

Ecco perché in questi articoli vorrei analizzare alcune parti della guida che possono mettere in luce questa politica di superficie. Ad esempio il differente approccio del Product Owner alla pianificazione del lavoro e alla “fisica” dello sprint, o la diversa modalità di raccolta dei feedback alla review finale, per poi vedere le modalità di organizzazione e conduzione delle varie riunioni, fino al coinvolgimento degli stakeholder durante i vari passaggi.

Obiettivo di prodotto, obiettivo di sprint: prima di tutto l’obiettivo

Nella nuova versione della guida è ben presente l’importanza della strategia del prodotto, con lo scopo e il valore ad esso associati.

Si sottolinea che c’è un obiettivo di prodotto (Product Goal) e un obiettivo di sprint (Sprint Goal): se entrambi sono ben definiti e non vengono persi di vista, aumenta la flessibilità sul modo in cui viene organizzato il lavoro all’interno dello Sprint.

In precedenza, si poteva intendere lo Sprint Backlog come una to-do list, mentre è ora ben chiaro che si tratta prima di tutto di un lavoro da svolgere con un obiettivo (Sprint Goal) e poi che è anche una to-do list. In questa ottica, il Product Owner non può “cavarsela” presentando una semplice lista delle cose da fare, ma deve sempre ricordare in che misura la realizzazione di un determinato elemento vada a contribuire al Product Goal generale.

Dando maggiore enfasi al concetto di Sprint Goal, si afferma che in uno Sprint il piano di lavoro può anche cambiare, a patto che non cambi lo Sprint Goal e che sia sempre chiaro a tutti in che modo esso contribuisca al Product Goal.

Per quanto riguarda invece lo Scrm Master, penso sia importante osservare la maggior enfasi data al suo ruolo di “agente del cambiamento”, di curatore di aspetti organizzativi e di gestione della implementazione di Agile all’interno dell’azienda.

Sprint Planning

La Guida Scrum ci dice poi che

Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team.
The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal.
The Scrum Team may also invite other people to attend Sprint Planning to provide advice.

Ho evidenziato alcune parti in grassetto, per ricordarne l’importanza.

Partiamo dal secondo passaggio: già in precedenza la guida dava molta importanza al coinvolgimento degli stakeholders nella fase di review a fine Sprint. Adesso si spinge maggiormente su questo aspetto aprendo anche la riunione di pianificazione dello Sprint.

Questa cosa è certamente positiva se vista dal punto di vista della trasparenza e del contributo che possono dare altri portatori di interesse.

Lo Sprint Planning è infatti un momento di discussione, di confronto fra il Product Owner e i Developers: durante questa riunione si smontano e riorganizzano gli elementi del backlog spesso alla ricerca di un compromesso per aggirare qualche impedimento o gestire al meglio le dipendenze. Non di rado si cerca di arrivare a fine Sprint con qualcosa che, pur non essendo completo, permetta di capire meglio un punto oscuro, o di far provare agli utenti quanto stiamo realizzando.

Costantemente il Product Owner, con il resto del team, fa scelte guidate dal pragmatismo per fugare il prima possibile i dubbi e individuare il modo per rilasciare maggior valore possibile all’utente. Nel mezzo di queste scelte, il risultato può apparire bizzarro, incompleto, inesatto, ingiustificabilmente complesso.

Rapporto tra elementi del Product Backlog e Product Goal

Far partecipare uno stakeholder impreparato a questo modo di lavorare potrà suscitare commenti del tipo:  “Ma a me serve tutto… non voglio cose fatte a metà! E la qualità dove la mettiamo?”.

In tal senso il passaggio fondamentale nella guida è questo: “The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal.”

Appare chiara la necessità di condividere e discutere con i partecipanti alla riunione gli elementi del Product Backlog e il loro rapporto con l’obiettivo di prodotto. Ma i partecipanti devono arrivare preparati. Questa non è una grossa novità; anche prima fra i compiti del Product Owner vi era quello di raccontare il prodotto e preparare allo scopo del lavoro. In questo caso si rafforza il concetto di mappatura fra item del backlog e Product Goal, cosa che non sempre viene visto come un punto così importante: “In fondo sono il Product Owner, sono io che decido cosa mettere nel Product Backlog e cosa fare nel prossimo Sprint”. È un tema di cultura anche qui? Di capacità negoziale e di condivisione delle informazioni in azienda? Penso proprio di sì. Ancora un volta, e ancora di più, emerge come il Product Owner non sia un Project Manager. Ancora una volta si evidenzia come molte delle competenze richieste non sono facilmente acquisibili con un ruolo a tempo.

Sempre più in alto…

Ma l’asticella si alza per tutti. Se il Product Owner deve farsi carico di condividere la strategia di prodotto, e far si che tutti siano preparati alla riunione di pianificazione, è altresì indicato che è compito dello Scrum Master promuovere questo nuovo modo di lavorare al resto dell’azienda, con i vari stakeholder coinvolti sia nella riunione che dall’adozione di Agile. Scrum Master e Product Owner devono quindi lavorare in modo pervasivo in tutta l’organizzazione e non solo all’interno del team.

La Sprint Review non è una demo: inspect & adapt

Questo approccio al lavoro corale — da un lato forte coinvolgimento degli stakeholder, dall’altro Product Owner e Scrum Master che lavorano anche esternamente dallo Scrum Team, nei confronti delle altre componenti dell’azienda — si nota anche nella descrizione della Sprint review:

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.
During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.
The Sprint Review is the second to last event of the Sprint and is timeboxed to a maximum of four hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

Qui ancor più di prima si mette in luce l’importanza di valutare tutti insieme cosa è stato fatto e tutti insieme si decide cosa fare dopo, di apportare correzioni in funzione di eventuali cambiamenti di contesto. Si noti quanto è importante in tal senso la frase: “attendees collaborate on what to do next”.

La Sprint Review non è quindi solo una demo: tutti i partecipanti (Scrum Team e stakeholder) devono partecipare con un contributo attivo alla riunione e probabilmente devono svolgere del lavoro prima e dopo la review.

La realtà dei fatti

Ma nelle aziende, quante volte vediamo questo atteggiamento realmente esercitato? Assistiamo non di rado a stakeholders che sono impegnati nel loro lavoro di personalei del business o del demand  — quelli che in un qualche modo si preoccupano del “cosa” deve essere fatto in azienda — e che quindi sono spesso indaffarati a fare altro, non coinvolti; sono più disponibili alla delega di responsabilità verso il Product Owner che a un reale coinvolgimento. Sono interessati più al “Quando sarà pronto?”, che al “Forse questa cosa potremmo farla in questo modo”.

La mancanza di disponibilità e di focus, fa sfuggire che “iterativo e incrementale” è una strategia di risk management, più che semplicemente un modo per fare qualcosa un po’ per volta.

Quindi…

Per questo mese ci fermiamo qui: nel prossimo articolo vedremo altri aspetti che sottolineano come non solo Product Owner e Scrum Master devono lavorare “nell’azienda”, ma che ci deve essere la disponibilità del resto dell’azienda per trovare il tempo per ascoltare Scrum Master e Product Owner.

Riferimenti

[1] The 2020 Scrum Guide™
https://scrumguides.org/scrum-guide.html

[2] Francesco Saliola, La nuova Guida Scrum. Niente di nuovo o cambiamento sostanziale? MokaByte 267, dicembre 2020
https://www.mokabyte.it/2020/12/16/scrumguide2020/

[3] Luigi Mandarino, Fare “il tagliando” a Scrum. A due anni dalla pubblicazione della nuova guida. MokaByte 288, novembre 2022
https://www.mokabyte.it/2022/11/11/tagliandoscrum22/

[4] Giovanni Puliti, Verso l’Agile. II parte: Miti, fatti e pianificazione. MokaByte 189, novembre 2013
https://www.mokabyte.it/2013/11/01/versoagile-2/