Scrum Guide 2020: facciamo il punto dopo tre anni

L’ultima versione della Scrum Guide è uscita nel 2020. Cosa possiamo dire con spirito critico dopo tre anni? Quanto è stata davvero compresa e applicata dalle aziende che hanno portato Scrum nelle loro organizzazioni? Proviamo a rispondere a queste domande con le considerazioni derivanti da quanto osservato durante le nostre esperienze sul campo e analizzando alcuni aspetti chiave della Scrum Guide 2020.

Scrum Guide 2020: meno regole Scrum, più profondità di significato

La versione Scrum Guide 2020 ha ridotto il numero delle regole e delle pratiche operative, senza però minare la profondità del significato trasmesso. Anzi, rendendola probabilmente più impegnativa da comprendere e complessa da implementare.

Gli autori Jeff Sutherland e Ken Schwaber hanno puntato ancor di più sull’importanza di un cambio di mentalità necessario per introdurre un differente modo di lavorare e favorire l’utilizzo di Scrum. 

Molte aziende purtroppo, per quello che la nostra esperienza ci ha mostrato, ragionano ancora in termini di regole, procedure, ruoli, mansioni, strumenti; meno sul significato che certe pratiche, ruoli, strumenti si portano dietro. Concentrate sulle meccaniche di implementazione, sono lontane dal comprendere il significato dell’evoluzione che l’implementazione di Scrum può portare.

La responsabilità e i percorsi di carriera

La guida pone il focus più sulla responsabilità che sui ruoli e competenze. Con responsabilità si intendono quelle che servono per sviluppare prodotti da curare tramite un percorso definito e continuo di apprendimento.
Non si tratta quindi solamente di introdurre nuove figure all’interno dell’azienda, ma anche di cambiare approccio nel processo di gestione durante il percorso di carriera.

[Sui percorsi di carriera abbiamo pubblicato una serie di articoli: Progettare la propria carriera in modo Agile. Carriera ed employability (1/3) e Progettare la propria carriera in modo Agile. Talento e Ownership (2/3)]

Purtroppo capita, che a tali percorsi non venga dato il supporto e la cura necessari: il Product Owner, figura chiave per l’organizzazione, viene ancora concepito come una figura “attivabile” dopo un breve percorso formativo in cui apprendere tecniche e strumenti di lavoro. Discorso analogo per lo Scrum Master, che ha il delicato compito di essere l’interlocutore con tutti i livelli dell’azienda supportando il processo di adozione delle metodologie agili, spesso viene visto come una figura da inserire in organico a contratto di affitto in base alle esigenze momentanee di progetto.

Il cambiamento per rimanere competitivi non è una soluzione veloce

In molte aziende si è ormai compreso come Agile possa essere lo strumento per guidare un cambiamento non più rimandabile e necessario per rimanere competitivi in un mercato complesso, volatile, incerto e spesso poco decifrabile (VUCA).
Spesso questa convinzione si traduce poi nel desiderio di trovare una soluzione rapida, la tattica che dia risultati sul problema di oggi, senza affrontare a livello strutturale il vero punto di debolezza sistemica (strategia).

Gli autori nello stilare la guida Scrum, non hanno assecondato questo desiderio, ma hanno invece puntato su principi e raccomandazioni che agiscano in profondità sulle fondamenta della cultura aziendale. Questo approccio si vede in molti punti della guida: abbiamo preso alcuni passaggi di esempio per dimostrare cosa intendiamo dire.

Gli obiettivi della strategia di prodotto

Nella guida del 2020, tutto tende a ruotare attorno al concetto di prodotto nonché allo scopo e valore ad esso associati.
Per esempio, se prima lo Sprint Backlog era essenzialmente una to-do list di cose da fare nello sprint, adesso è prima di tutto la descrizione di un obiettivo da raggiungere nello sprint (Sprint Goal) e solo dopo “anche” un elenco di cose da fare. 

Per questo, se prima tale lista era considerata intoccabile durante l’iterazione, adesso, pur riconoscendo l’importanza nella stabilità del piano di lavoro, si pone molta più rilevanza nel valutare costantemente se tale piano è in linea con lo scopo individuato per lo sprint e se questo contribuisce allo scopo del prodotto (Product Goal). Gli sviluppatori (insieme al PO) devono quindi periodicamente verificare se ci sono nuove informazioni che possono far cambiare elenco delle attività nello sprint backlog al fine di contribuire al prodotto.

Questo significa che serve, da parte di tutti, un approccio più strategico al prodotto. Il PO deve arrivare al Plan (e anche durante lo sprint) con una maggior consapevolezza del perché delle cose, più che stilare una task list. E questa consapevolezza deve essere condivisa costantemente coi colleghi.

Ruolo del Product Owner

Il PO non è un semplice compilatore di un elenco di cose da fare, ma è colui che deve costantemente interrogarsi sul perché delle cose da fare. Servono conoscenze, strumenti (metodologici), esperienza e visione che raramente si possono acquisire con un corso di due giorni, con una nomina e un cambio di ruolo (come da PM a PO) o, peggio ancora, con un l’ingaggio temporaneo di un consulente esterno in body rental.

Non deve spaventare, ma stiamo dicendo che per fare il PO serve tempo e serve un cammino in cui l’azienda supporti le persone nell’imparare nuove competenze e strumenti.

Frequentemente notiamo invece che per addestrare un PO basti insegnarli a fare una to do list ordinata e passarla ai colleghi.

La pianificazione dello Sprint

Parlando di pianificazione dello sprint c’è un passaggio molto interessante nella Scrum Guide: 

“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.”

Da questo brano si evince che lo Sprint Planning è un momento di discussione e di confronto fra Product Owner e Developers, in cui si smontano e riorganizzano gli elementi del backlog alla ricerca di un compromesso per aggirare qualche impedimento o gestire al meglio le dipendenze. 

Si osservi la parte in grassetto: ci dice che, oltre alla review finale, anche nel plan possiamo invitare partecipanti esterni per “provide advice”, quindi per contribuire insieme al PO e Developers alla pianificazione del lavoro (a tutto vantaggio della trasparenza e condivisione).

Sembra una cosa bella, sulla quale probabilmente nessuno potrebbe avere qualcosa da obiettare.

Nella realtà dei fatti, gli stakeholder esterni al team sono spesso impegnati in altre attività e sono poco, o addirittura per niente, coinvolti nella vita (o nello scopo) del progetto. Gli stakeholder sono più propensi alla delega di responsabilità verso il Product Owner: spesso si limitano a chiedere “Quando sarà pronto?” più che contribuire con un “che ne dite se questa cosa la facessimo in questo modo?”.

La guida sembra essere preparata a questa evenienza: “The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal.”
Di nuovo ci viene ricordato che uno dei compiti del PO, è proprio quello di assicurarsi che tutti conoscano il contenuto e il significato del backlog: deve quindi descrivere il prodotto, le sue funzionalità, lo scopo e il valore che ci si aspetta possa produrre per gli utilizzatori; e deve poi raccontare  come  gli item del backlog consentano di ottenere tali obiettivi.

Sprint Review collaborativa

Lo stesso tipo di approccio si trova anche nella parte che parla della Review. Forse qui addirittura si spinge ancora di più sul concetto di lavoro collaborativo. Per esempio si osservi la parte in grassetto del seguente estratto:

“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.”

Questo passaggio è denso di significato e di conseguenze: non è detto che l’organizzazione sia pronta a tale apertura o al fatto che il PO non è più il solo a decidere il contenuto del backlog, ma che anzi tutti gli stakeholder analizzino (inspect) il lavoro fatto fino a quel punto e di conseguenza adattino (adapt) il restante lavoro. Dire questo, vuol dire spingere su una maggior coinvolgimento da parte di tutti per discutere sul significato del lavoro che si sta svolgendo e sul valore che ci aspettiamo di ottenere.

E oltre a questo nuovamente si enfatizza sul lavoro corale: tutti i soggetti coinvolti valutano insieme cosa è stato fatto e decidono cosa fare dopo. Quindi tutti i partecipanti (Scrum Team e stakeholder) possono partecipare portando un contributo attivo alla riunione (e per farlo è probabile che ci arrivino preparati, magari svolgendo del lavoro prima e dopo la review).

La sensazione che le aziende spesso si stiano muovendo in tutt’altro modo è particolarmente forte.

Risorse

Dovre trovare la Scrum Guide completa: Scrum Guide 2020

Articolo di Mokabyte: Scrum 2020: e se la sfida fosse troppo impegnativa?