Metodologia Scrum: istruzioni per l’uso…

Se siete affezionati ad una visione meccanicistica del mondo, fatta di metodologie, modelli e strutture di semplificazione della realtà, questo è l’articolo che fa per voi!

Vi illustreremo essenzialmente quattro messaggi su scrum:

– Perché scrum NON è una metodologia per il project management;

– Cosa compone il framework scrum;

– Come far fallire un team scrum;

– Perchè Scrum genera fiducia all’interno del team e dell’organizzazione.

Perché Scrum NON è una metodologia per il project management ?

Ci sono diversi aspetti da considerare per rispondere a questa domanda:

1) Il project management intrinsecamente definisce il successo della pianificazione tramite aspetti che riguardano l’operatività, quanto più i tempi e costi effettivi del progetto son prossimi ai tempi e ai costi stimati, tanto più il Project Manager e il team di progetto saranno considerati competenti e di successo. Tuttavia, tali aspetti operativi non pongono nessuna attenzione al valore effettivo del lavoro che viene consegnato al cliente finale. Scrum è un forte sostenitore del PRODUCT MANAGEMENT, in quanto l’obiettivo di Scrum è quello di massimizzazione il valore del lavoro prodotto misurando il successo della pianificazione con i feedback effettivi dell’utente finale. Ecco perché Scrum non ha nulla a che vedere con il project management, Il successo di un team Scrum non è misurato dalla sua capacità rispettare tempi e costi previsti, perché questi sono definiti a priori e sono fissi. Il successo di un team Scrum è misurato tramite la capacità di generare valore ad ogni iterazione in modo da ottenere un ritorno sul tempo e sul budget investito.

2) La metodologia definisce in maniera dettagliata e rigorosa come applicare un determinato modello alla realtà che ci circonda. Scrum in tal senso è del tutto agli antipodi, infatti è volutamente incompleto su tutti quegli aspetti che implicano complessità come ad esempio:

a. definizione della visione di prodotto;

b. definizione del valore da generare tramite ipotesi;

c. definizione dell’approccio strategico di validazione delle ipotesi tramite una roadmap

Tali aspetti sono così legati al dominio di prodotto che non possono essere stabiliti a priori tramite una metodologia, ecco perché il framework Scrum non li definisce.

3) Scrum cerca di raggiungere compromessi rilevanti secondo due direttrici del tutto ignorate dal project management:

a. Il compromesso tra il cost of delay e il cost of ownership: le iterazioni scrum ci impongono di ragionare in termini di necessità ed emergenza in modo da non ritardare la generazione di valore che ripaghi sia il costo opportunità (cost of delay) ma anche il costo di sviluppo e mantenimento del prodotto stesso (cost of ownership).

b. Il compromesso tra complessità accidentale e complessità essenziale, infatti Scrum punta a gestire la complessità relativa al product management (cioè la complessità essenziale nel creare un prodotto che delizi i clienti) cercando di ridurre la complessità accidentale (cioè la complessità di processo legata a discontinuità, interruzioni e possibili cambiamenti sulla base dei feedback del cliente), minimizzando in questo modo i rischi e riducendo tutto il lavoro relativo alla loro gestione, tipico del project management.

Cosa compone il FRAMEWORK scrum?

Partendo appunto dalla gestione della complessità accidentale Scrum utilizza cinque eventi e un’attività, quest’ultima, al contrario degli eventi non ha una cadenza definita e un time-box prescritto.

L’obiettivo di quasi tutti gli eventi scrum è quello di ispezionare quanto è avvenuto in un arco temporale per poi adattarsi di conseguenza e a tal proposito tale ciclo di miglioramento continuo deve essere alimentato secondo diversi punti di vista che sono in campo alle tre accountabilities del team scrum, infatti:

– Il Product Owner è il responsabile ultimo della massimizzazione del valore prodotto dal team e in tal senso deve ispezionare continuamente i feedback dei clienti e far sì che questi siano letteralmente deliziati dal prodotto/servizio offerto;

– I Developers sono i responsabili ultimi della qualità del lavoro sviluppato durante lo sprint;

– Lo Scrum Master è il responsabile ultimo del miglioramento riguardante le interazioni all’interno del team e la comprensione/diffusione dei principi e dei valori agili all’interno del team e dell’organizzazione.

Affinché tutto questo avvenga è necessario che sia garantita la trasparenza all’interno del team: tale trasparenza è assicurata dalla gestione/mantenimento degli artefatti in linea con i relativi commitment. Il commitment che guida tutto lo scrum team è il product goal cioè la visione condivisa del prodotto che giustifica l’esistenza dell’artefatto all’origine di tutti gli altri, cioè il product backlog.

Una volta che parte di questo product backlog è presa in carico dai developers per esser sviluppata, cessa di essere product backlog e diventa sprint backlog in quanto risponde al commitment dello sprint goal (cioè un micro-obiettivo, autoconsistente in termini di valore, che porterà al raggiungimento del product goal).

Quando tutto lo sviluppo sarà completato, secondo quando stabilito dal commitment Definition of Done definita dai Developer, allora lo sprint backlog diventerà un Incremento di prodotto che si aggiungerà a quelli esistenti permettendo così di generare ulteriore e rinnovato valore che ripagherà il tempo e il budget investito durante lo sprint.

Come far fallire un team Scrum ?

Per le esperienze che ho avuto modo di osservare da vicino, spesso i limiti che sovrastano le possibilità di successo di un team scrum sono riassumibili in quattro categorie:

– Organizzazione suddivisa in team funzionali: già nel 1967 Conway si rese conto di come “qualsiasi organizzazione che progetta un sistema (definito in senso ampio) produrrà un progetto la cui struttura è una copia della struttura di comunicazione dell’organizzazione”. Tradotto in soldoni, significa che le organizzazioni con un mindset orientato al project management tendono a strutturare il proprio interno secondo le diverse parti funzionali del prodotto che sviluppano: abbiamo così uno svariato numero di team specializzati a gestire una piccola parte del prodotto senza una chiara visione end to end del prodotto stesso. Questo provoca lavoro ulteriore per la gestione delle dipendenze (ecco il perché si ricorre al project manager), che nonostante ce la metta tutta, non è messo in condizioni di produrre valore per il cliente finale in quanto vi è la mancanza di una visione di insieme da parte di chi sviluppa il lavoro e un continuo passaggio di semi-lavorati privi di valore per il cliente finale da un team all’altro che spesso implica ri-lavorazioni;

– Mancanza di empowerment e delega decisionale: sempre figlio di un’organizzazione strutturata per funzioni e non per prodotto, tale aspetto riduce di gran lunga le capacità di un team scrum, in quanto non sarà mai messo in condizioni di prendere decisioni in autonomia. Il product management non è altro che una ricerca continua di valore, in quanto tale, necessita della capacità di modificare rapidamente le scelte fatte man mano che si ottengono feedback. Un scrum team senza empowerment che vede:

– Product Owner privo di delega nella gestione del prodotto e relativo budget;

– Developer mancanti di tutte le competenze necessarie a generare un incremento;

– Scrum Master privo di supporto da parte dell’organizzazione;

non potrà mai produrre valore e soddisfazione per il cliente e per chi lavora.

– Flusso di lavoro turbolento: Scrum è un framework che supporta il product management in contesti complessi, pertanto può esser molto utile nel caso in cui abbiate da sviluppare un lavoro poco ripetitivo e che consta di continui esperimenti, se invece il vostro lavoro consta di attività più o meno ripetitive per le quali non riuscite a a prevedere la numerosità e la frequenza, perché aspetti che non dipendono da voi ma sono del tutto imprevedibili, allora scrum non fa al caso vostro.

– Assenza di chiarezza in merito al cliente finale: implica una mancanza di misurazione del valore prodotto, nonché una mancanza della visione stessa del prodotto. Spesso alla domanda “qual è l’obiettivo da raggiungere?” nessuno dà una risposta concreta: questo silenzio è sintomo della evidente mancanza di un cliente definito, oppure di un numero eccessivo di clienti da accontentare. La chiarezza in merito a chi dovete deliziare con il lavoro prodotto è la base fondante per avere criteri di prioritizzazione del lavoro; misurazione del valore prodotto e allineamento di aspettative con i vostri clienti che permetterà così la creazione di un rapporto di fiducia non solo con i clienti stessi, ma anche in voi stessi come scrum team.

Perché Scrum genera fiducia all’interno del team e dell’organizzazione?

Questo è possibile solo se vengono rispettati i valori scrum. Spesso molte organizzazioni più che scrum implementano quello che viene definito “scrum-ble”, cioè l’unione tra scrum e “stumble” (che in inglese significa inciampare) e quindi è come se letteralmente “inciampassimo” nell’utilizzo di scrum anziché sfruttarne le potenzialità intrinseche.

Pertanto, è necessario che l’organizzazione e il team rispettino i valori di:

– Openess: apertura alla sperimentazione, ad essere trasparenti in merito al lavoro che viene svolto e a come viene svolto, disponibili a condividere tanto i successi quanto i fallimenti poiché entrambi sono ottimi spunti per il miglioramento continuo, apertura alla diversità in termini di idee coadiuvata sempre da una visione empirica che ne permetta il confronto e che permetta uno scambio facendo leva sulle evidenze delle esperienze vissute in qualità di team;

– Focus: lasciare la possibilità al team scrum di perseguire lo sprint goal senza interruzioni, quando questo avviene state permettendo alla complessità accidentale di avere la meglio e di ridurre la mitigazione dei rischi ad essa associati tramite l’utilizzo degli eventi scrum;

– Respect: tenere conto della delega che ogni persona ha in capo a sé e ritenersi ugualmente responsabili all’interno dello scrum team per il raggiungimento del product goal e per il rispetto dello stesso. Questo implica anche rispettare il cliente consegnando ad ogni sprint incrementi di prodotto che siano di valore e in linea con le sue aspettative.

– Courage: coraggio di iniziare a lavorare dalle iniziative più complesse ma allo stesso tempo che hanno maggiore impatto sulla vita dei nostri clienti, come anche coraggio di saper individuare quali aspettative non sono fattibili e comunicarlo in maniera schietta al nostro cliente.

– Commitment: fare il massimo per raggiungere l’obiettivo prefissato a prescindere che questo sia il product goal, lo sprint goal o la definition of done. Questo implica anche aiutarsi all’interno del team e delegarsi a vicenda attività nel buon nome della collaborazione e del raggiungimento di quanto promesso al cliente.

Spero di essere riuscito a “diradare” qualche dubbio su Scrum. Per approfondire, ai seguenti link troverete le informazioni per iscriverti ai nostri corsi Professional Scrum Product Owner e Professional Scrum Master preparatori al conseguimento delle certificazioni PSPO I e PSM I di scrum.org

Scrum Master con certificazione PSM I https://inspearit.it/formation/scrum-master-con-certificazione-psm-i/  

Scrum Product Owner + certificazione PSPO I https://inspearit.it/formation/scrum-product-owner-con-certificazione-pspo-i/