Tag: scrum

Spesso in formazione si discutono le differenze fra metodologia e framework. In questo articolo troverete la risposta alla domanda: “Perché Scrum non è una metodologia?”

Una metodologia di lavoro consiste ad applicare sempre lo stesso processo, con gli stessi input e output, per realizzare il lavoro. L’obiettivo è di ridurre i rischi e rendere il risultato del lavoro prevedibile.

L’apparizione delle metodologie di lavoro risale al periodo della rivoluzione industriale, l’esempio classico è la catena di montaggio che è pensata per assemblare diversi componenti il più rapidamente possibile ed ottenere come risultato finale il prodotto voluto. Una metodologia ottimizza l’output che si vuole creare, il risultato finale è conosciuto in anticipo.

Con l’avvento di nuovi mestieri, come l’informatica, profondamente differenti dal concetto di una catena di montaggio, si è applicato ciò che si conosceva, trascurando il fatto che la soluzione ad un problema non era conosciuta in anticipo. Ciò ha creato tensioni e problemi di vario tipo fra i lavoratori e il management.

Una metodologia è utile per risolvere un problema semplice, è un’approccio predittivo che presuppone la conoscenza anticipata dello stato finale che si vuole raggiungere.

Fabio Panzavolta

l’evoluzione del pensiero

Nel 1990 alcuni professionisti del mondo dell’informatica, fra i quali Ken Schwaber e Jeff Sutherland (creatori di Scrum) hanno capito che i ritardi, la scarsa qualità e le inefficienze nella creazione di software non erano dovute alle persone che non lavoravano abbastanza duramente, o che non applicavano correttamente la metodologia, bensì al paradigma adottato.

Prima con Extreme Programming poi con Scrum, le cose hanno cominciato a cambiare. L’accettazione del fatto che non si può prevedere in anticipo tutto il lavoro necessario alla creazione di un prodotto complesso ha lasciato lo spazio ad un cambiamento di paradigma.

L’empirismo a preso il posto del determinismo. Un processo empirico basa tutte le decisioni future sull’esperienza passata: la soluzione ad un problema, la creazione di un prodotto o servizio emergono dal feedback ricevuto dall’utilizzatore.

Ken Schwaber, co-creatore di Scrum, in questo articolo descrive le organizzazioni moderne prendendo come metafora il film “La tempesta perfetta” dove una serie di circostanze sfortunate e concomitanti creano una situazione praticamente incontrollabile per l’equipaggio del peschereccio. È evidente come, in questo contesto, nessun tipo di metodologia potrà aiutare l’equipaggio a sopravvivere. Al contrario, la sperimentazione di diverse manovre è necessaria per capire come la barca reagisce e trovare la via d’uscita.

Ecco perché Scrum non è una metodologia! Spesso descriviamo Scrum come un gioco di società, oppure come il Rugby, con le proprie regole, principi e valori. Se si vuole giocare a Scrum, bisogna avere il coraggio di affrontare l’incertezza e sperimentare diverse soluzioni fino a trovare quella più adatta al momento.

Scrum permette di navigare l’incertezza, esplorando diverse soluzioni adattative per risolvere problemi complessi.

Fabio Panzavolta

Conclusione

Perché Scrum non è una metodologia? Perché Scrum lascia le persone libere di prendere decisioni per adattarsi a qualsiasi situazione e seguendo poche regole semplici. Basti pensare che lo Scrum Guide in inglese è un libretto di 13 pagine!

Nella tabella qui sotto riassumo alcune differenze fra una metodologia ed un framework, con l’obiettivo di comprenderne la differenze ed aiutare nella scelta migliore per il problema che dovete risolvere.

Gli elementi associati a Scrum sono strumenti, pratiche e più in generale “tattiche di gioco”, che non sono obbligatorie in Scrum e che si sono rivelate utili nel tempo.

Tuttavia, in un contesto di complessità e imprevedibilità, non è automatico che questi elementi associati a Scrum vi siano utili.

Suggeriamo di sperimentarli e, eventualmente, adattarli al proprio contesto in maniera empirica.

Gli elementi associati a Scrum non dovrebbero essere imposti ad uno Scrum Team, eccone un elenco non esaustivo.

• Product Backlog Refinement: si tratta di un’attività ricorrente, durante la quale lo Scrum Team aggiunge dettaglio agli elementi del Product Backlog. Questa attività è molto utile quando diversi Scrum Team lavorano insieme per creare un prodotto o servizio. La durata e la frequenza di questa sessione di lavoro è definita dallo Scrum Team.

• Burndown chart: un modo per rappresentare visivamente il lavoro svolto e ancora da fare. Può essere applicato sia al Product Backlog che allo Sprint Backlog. Fornisce trasparenza sullo stato di raggiungimento dello Sprint Goal. Spesso assume la forma di un grafico che mostra sull’asse verticale la quantità di lavoro e sull’asse

• Poker Planning: tecnica per stimare la complessità del lavoro da svolgere. Un gioco divertente che permette ai Developers di allinearsi su un determinato argomento e comprenderne la complessità. Planning Poker si basa sulla sequenza di Fibonacci, presentata sotto forma di carte da gioco (un esempio delle carte Collective Genius fornite ai partecipanti durante una formazione). Ciascun partecipante, una volta discussa l’elemento del Product Backlog, sceglie una carta corrispondente al livello di complessità di realizzazione che percepisce (0 poco complesso, 55 molto complesso). I Developers girano le proprie carte contemporaneamente, rivelando così la propria percezione della complessità, senza esserne influenzati. Potrebbero esserci differenze nelle stime, nel qual caso gli estremi motivano la loro scelta e, dopo aver discusso le differenze i partecipanti rivotano. Alla fine otterremo una stima dei Developers, non di una singola persona.

• Business Model Canvas: è un modo per creare un business case agile in modo collaborativo e guidato. Usiamo questo Canvas nei nostri corsi di formazione Professional Scrum Product Owner per esplorare le diverse strategie business riconducibili alla visione aziendale.

E tu, quali altri elementi associ a Scrum?

Scarica e stampa (in A4 o A3) il poster relativo a questo articolo, può essere utile per te in ufficio, i codici QR consentono di approfondire la conoscenza del framework Scrum!

Questo articolo fa parte di una serie di dodici pubblicazioni, ognuna delle quali spiega le basi di Scrum, secondo lo Scrum Guide.  Potrebbe essere utile per te come presentazione alla direzione o per chiunque sia curioso di approfondire l’argomento.

Tradotto dal francese da Denise Monreale, grazie!