Scrum si connota per la semplicità del modello proposto per organizzare il proprio progetto. L‘articolo conclude questa miniserie introduttiva, prendendo in esame come scrivere un ProductBacklog, come si arriva al rilascio in produzione, come si gestice la comunicazione in Scrum, come è possibile personalizzare questa metodologia e come si possono inserire ruoli “tradizionali” all‘interno del metodo.

Finora è stato spiegato come si gestisce una iterazione di lavoro in Scrum, ma cosa succede prima e dopo uno sprint? Ossia:

• Come arrivo alla scrittura di Product Backlog?
• Come arrivo al rilascio in produzione?

Le richieste degli Stake Holder sono spesso fatte nei modi più disparati e certamente non sono già strutturate in User Story. Il compito del PO è di “trattare” con tutti (compreso lo Scrum Master e il Team) al fine di ottenere una lista di storie che abbia tre caratteristiche fondamentali:

• una importanza (dichiarata dal PO);
• un costo (dichiarato dal Team);
• la descrizione del modo in cui testare il contenuto della storia (concordata con tutti).

Scrum non dice come arrivare alla scrittura di un backlog e probabilmente questo sarà rivisto molte volte; sicuramente l’ultima cosa da indicare è il costo delle storie. Questo perche’ è molto difficile dire quanto tempo serve per realizzare un’attività se non è stato chiarito il suo contenuto e quindi non è stato definito il test per verificarlo.

Figura 1 – Il processo di scrittura del Product Backlog.

La prima versione del Product Backlog, di conseguenza, potrebbe essere un’attività molto lunga ed è da considerare cruciale per la riuscita del progetto e quindi non si deve avere fretta per completarla. Ci vuole il tempo necessario, ma occorre comunque in qualche modo compartimentare il tempo per arrivare a un backlog concordato: ricordare sempre che in Scrum tutto è time boxed!

Purtroppo non è definito quanto tempo dedicare a questa operazione; tuttavia, usando il buon senso, possiamo trattare con i nostri Stake Holder in termini di rilasci progressivi (no Big Bang!) anche perche’ spesso sono loro che non hanno chiaro cosa vuol realmente dire la loro richiesta e cosa comporta realizzarla.

Anche la realizzazione di uno o più prototipi può aiutare alla comprensione del problema e quindi alla definizione di un backlog chiaro e realistico.

Quando uno sprint viene concluso vi è un “avanzamento di prodotto” potenzialmente rilasciabile in produzione ed è il PO a decidere se eseguire un rilascio o meno. È possibile definire un Release Backlog che contiene l’elenco degli sprint necessari per un rilascio in produzione ed eventualmente un burndown chart dei rilasci, simile a quello fatto per lo sprint (si veda l’articolo precedente della serie).

Anche la procedura di rilascio è un’attività fortemente personalizzabile, dal molto informale al molto formale, e occorre tener presente che le competenze per il rilascio possono essere esterne al Team (e quindi occorre organizzarsi di conseguenza).

Il Team di sviluppo deve essere composto da poche persone e comunque non più di 9. A volte però sono necessarie molte risorse per riuscire a consegnare e quindi dobbiamo strutturarle in più squadre. Ogni Team ha le caratteristiche descritte in precedenza e quindi risultano delle unità indipendenti, ognuna con il suo Scrum Master.

A qualcuno potrebbe venire la tentazione di mettere un unico SM per tutti i Team, ma è una pratica assolutamente da scongiurare perche’ vuol dire che sarà sempre “lontano” dagli sviluppatori e quindi risulterà una figura “sfuggevole”; e comunque sarà sommerso da una mole di lavoro non sostenibile da una sola persona.

Risulta evidente però che tutti devono collaborare allo stesso progetto e quindi si deve prevedere una qualche forma di coordinamento tra i Team. Questo avviene in una riunione chiamata Scrum of Scrum (SoS), in cui sono presenti tutti gli Scrum Master. Essa serve a tutti per sapere a cosa si sta lavorando all’esterno del proprio Team e quindi per condividere soluzioni. In questo modo i singoli gruppi di lavoro sono facilitati nell’adottare standard e nel riuso di quanto prodotto in precedenza.

I singoli gruppi di lavoro possono inoltre esprimere gradi di competenza diversi e quindi potrebbe essere necessario uno SoS per suddividersi le storie da realizzare all’interno di uno sprint (in questo caso la presenza del PO è obbligatoria, negli altri casi no).

Come abbiamo visto, Scrum è un framework che offre delle regole generali e uno “schema” di base che però va poi calato nella realtà in cui si lavora. In particolare molto dipende dalla grandezza dell’azienda, dal numero di fornitori e dai loro contratti, dalla grandezza del progetto e dal carattere dei manager coinvolti. Di seguito quindi vengono riportate una serie di varianti al processo che possono essere utili… ognuno è libero di adottarle o meno.

Quando si dà inizio a un progetto, è fondamentale essere assolutamente onesti e sinceri nel perseguire gli obiettivi dichiarati. Occorre però tenere presente che può succedere che non tutti gli attori coinvolti siano necessariamente leali a tali interessi e obiettivi.

Questo significa che il progetto deve essere tracciato e documentato in tutte le sue fasi, per evitare contestazioni e inutili litigi; naturalmente non è necessario che ogni dettaglio sia scritto in modo formale e sottolineato in modo eccessivo, però resta fondamentale tenere una traccia abbastanza dettagliata del progetto.

Il modo migliore per evitare questi problemi è rendere il progetto il più trasparente possibile, in modo tale che chiunque possa capire “al volo” come esso procede in relazione all’obiettivo finale e come si svolgono le normali attività di tutti i giorni.

La comunicazione è un elemento fondamentale e volendo citare Wikipedia [WP2]

“La comunicazione è un processo costituito da un soggetto che ha intenzione di far sì che il ricevente pensi o faccia qualcosa”

In Scrum questa operazione è svolta nei meeting e soprattutto nel daily scrum, ma avviene completamente “faccia a faccia” e gli artefatti prodotti, i backlog, devono essere letti e capiti per poter essere anche uno strumento di comunicazione.

Questo, a mio parere, rende i backlog utili per condividere informazioni, ma la vera comunicazione avviene durante i meeting: coloro che non sono presenti perdono le informazioni e hanno scarse possibilità di capire cosa succede e come intervenire (per tempo) se qualcosa non va per il verso giusto. In tal senso si comprende come il meeting non sia un “rito” da seguire inconsapevolmente ma diventi uno dei punti fondanti per il buon funzionamento dell’intera metodologia.

Nell’affermazione precedente c’è la consapevolezza che le persone sono spesso allocate su molte attività, tutte importanti e molte urgenti e che il grado di attenzione di chi “osserva” il progetto (come gli Stake Holder) può essere basso anche per lunghi periodi. Al contempo, le organizzazioni spesso tendono a ignorare le voci dei tecnici (come lo Scrum Master o gli sviluppatori).

A mio parere è quindi compito del PO rendere effettiva la comunicazione. Quindi con una certa regolarità (almeno una volta alla settimana) il Product Owner dovrebbe inviare agli Stake Holder uno stato avanzamento lavori (SAL) molto sintetico in cui risponde alle seguenti domande:

• Il progetto è in linea con costi e tempi?
• Esiste la necessità di un intervento di qualche tipo da parte degli Stake Holder?

Naturalmente tutto cià può sembrare a qualcuno un’operazione normale, mentre ad altri può sembrare un’eresia visto che esistono le demo e quindi le situazioni sono “evidenti” a tutti.

Io credo semplicemente che se gli attori coinvolti (committente e fornitori) sono abbastanza piccoli, allora i loro “rappresentanti” avranno modo di partecipare a tutte le demo e di essere sufficientemente a disposizione del PO per poter chiarire gli aspetti del prodotto che si vuole realizzare. Ma se stiamo parlando di grandi aziende, allora gli Stake Holder potrebbero non essere in grado di dedicare sempre il loro tempo a tutte le demo; e soprattutto possono non capire lunghe e-mail che spiegano dettagli per loro poco tangibili.

A tutto questo, va aggiunto che è spesso necessario tracciare questi andamenti anche per tutti coloro che stanno al margine del progetto (quelli chiamati “chicken” che nel gergo di Scrum) ed evitare inutili interferenze e richieste. In ogni caso il “costo” di una dettagliata e-mail alla settimana non è certo enorme e, se il PO svolge il suo lavoro scrupolosamente, farà le sue dichiarazioni sapendo realmente quali sono le condizioni del progetto, altrimenti se ne assumerà in ogni caso la responsabilità.

Come il Product Owner è responsabile di mantenere allineati tutti gli Stake Holder, allo stesso modo lo Scrum Master è responsabile di rimuovere tutti gli ostacoli che in generale mettono a rischio la consegna del progetto e dello sprint corrente in particolare. Per farlo quindi sarà necessario che si attivi in prima persona per identificare tutti questi impedimenti per tempo: utilizzerà tutte le informazioni portate alla sua attenzione durante il daily scrum per indagare le situazioni più preoccupanti.

In questo senso è preferibile tracciare gli ostacoli e associarli a una o più User Story: chiaramente quelli che bloccano le storie “in progress” saranno da affrontare come prioritari. A volte gli impedimenti si risolvono con una telefonata al sistemista, altre volte bastano quattro chiacchiere con gli sviluppatori per chiarire una situazione tecnicamente “strana”, altre volte sarà necessario intervenire in prima persona sul codice al fine di realizzare componenti particolarmente critici.

In ogni caso se l’impedimento non si risolve entro la giornata in cui è stato segnalato, allora sarà compito dello SM comunicare via e-mail al PO la situazione, in modo tale che lui, essendo l’interfaccia del progetto verso l’esterno, sia anche al corrente di tutti gli elementi di rischio per lo stesso. L’e-mail deve essere molto sintetica e priva di dettagli tecnici. Questo perche’ il PO non è un tecnico (perlomeno in gran parte dei casi) e di sicuro non può svolgere direttamente nessun task che viene normalmente affidato al Team di sviluppo.

Tale comunicazione deve quindi semplicemente rispondere alle seguenti domande:

• Esiste un impedimento che mette a rischio lo sprint corrente o il progetto?
• Il Team e lo SM ritengono ragionevolmente di poter risolvere in autonomia tale impedimento?

Si può usare Scrum senza necessariamente adottare la sua peculiare terminologia: in definitiva è meglio mettere in atto la sostanza delle cose piuttosto che affezionarsi alla sola forma. In determinate situazioni, ai manager, C-Level, e altre figure di questo tipo non piacerà essere chiamati “galline”. Così come qualche sviluppatore non gradirà essere apostrofato come “maiale”: se questo può in qualche modo creare problemi si possono tranquillamente usare altri termini come “osservatore” per i primi o “programmatore” per i secondi, o qualsiasi altra cosa serva per allontanare questioni di scarsa importanza dall’implementazione del processo.

Dov’è finito il PM? Secondo Ken Schwaber [WP5], il ruolo di Project Manager è ricoperto dallo Scrum Master [KEN1]. A mio parere questo non è del tutto esatto: per essere precisi il PM è responsabile del progetto e lo rappresenta di fronte agli Stake Holder. Ha poi il compito di gestire il progetto a partire dalle allocazioni, la trattativa con i fornitori o con gli altri “enti” o uffici coinvolti. Il Project Manager, infine, è colui a cui si pensa come “responsabile” e quindi su di lui si concentrano tutte le pressioni in caso di problemi (e si spera anche di lodi in caso di successo).

A mio avviso, pertanto, il compito del tradizionale PM viene in Scrum suddiviso in parte sul PO e sullo SM, ma quello della gestione rimane un suo compito esclusivo a partire dal determinare chi è il PO e chi lo SM del progetto. È probabile che alla fine le sue competenze possano essere fatte ricadere in gran parte su uno dei ruoli di Scrum, ragionevolmente sul PO, anche se sullo SM dovranno ricadere le competenze di “guida tecnica” de iure [WP6].

Con questo secondo articolo della mniserie, abbiamo concluso la nostra introduzione a Scrum, una metodologia agile che, pur essendo molto ben strutturata nei suoi elementi fondamentali, lascia anche ampio margine a personalizzazione e adattamento, prestandosi molto bene ad essere adottata in situazioni anche piuttosto diverse tra loro.

In particolare, oltre ad alcuni aspetti inerenti la scrittura del Product Backlog, abbiamo visto in questo articolo come sia importante il delicato capitolo della comunicazione, nonche’ come il ruolo del tradizionale Project Manager possa essere ricondotto all’interno di Scrum.

Torneremo in futuro ad approfondire questa metodologia.

[SC1] Henrik Kniberg, “Scrum and XP from the Trenches”

[WP1] Wikipedia, locuzione latina “Si vis pacem, para bellum”

[WP5] Wikipedia, pagina su uno dei due inventori di Scrum, fondatore della Scrum Alliance

[SW2] Scrum Tools – ScrumWorks Pro & ScrumWorks Basic