L’approccio nasce negli anni ‘80 dal teorico organizzativo Nonaka e dal professore universitario Takeuchi. Interamente ispirato al modello Toyota giapponese, lo SCRUM Framework è stato successivamente sviluppato e teorizzato dagli americani Jeff Sutherland e Ken Shwaber.
Il metodo SCRUM: l’Etimologia
Il metodo SCRUM deve il suo nome allo sport del rugby. Secondo questa metodologia infatti, lo sviluppo del prodotto - nel nostro caso del software - non si articola più seguendo il classico approccio in cui si attraversano tutte le fasi standard (dallo studio delle specifiche fino all’implementazione e al mantenimento), ma viene fortemente enfatizzato il concetto di squadra.
Lo sviluppo del prodotto è visto metaforicamente come l’avanzamento della mischia dei giocatori di rugby a fino alla meta - [...] moving the SCRUM Downfield: un faticoso processo in cui la squadra è obbligata a cooperare mentre si sposta sul campo verso l’obiettivo comune.
Il metodo SCRUM: gli Obiettivi
L’obiettivo primario dello SCRUM framework è quello di dare evidenza al team del modo in cui sta effettivamente lavorando, facendo sì che sia il team stesso a evidenziare pregi, difetti e outcome del suo operato.
Il concetto che sta al centro del framework è il costante e ciclico miglioramento, raggiungibile tramite una continua analisi introspettiva e un’assidua attuazione di tutte quelle misure che riescono a far avanzare l’individuo, il team e l’azienda passo dopo passo verso l’ambita perfezione.
Alcuni dati dimostrano come con l’adozione del metodo SCRUM si siano registrati degli incrementi di produttività con picchi del 450%, raggiungendo ciò che tra gli scrum fans viene definita iperproduttività.
Il metodo predittivo a cascata: l’utopia che sfocia nel fallimento
Il metodo predittivo a cascata è l’approccio più largamente adottato nel mondo del project management; secondo questo metodo, il progetto si articola mediante un’ampia fase iniziale di studio delle specifiche e dei requisiti che - diciamoci la verità - non si conclude mai nella modalità pattuita o secondo le specifiche fornite dal cliente.
Il metodo a cascata, detto anche waterfall method, prevede un flusso simile:
Raccolta dell’intera mole delle specifiche del progetto in fase preliminare
Pressoché impossibile
Progettazione di ogni singolo modulo del progetto
Possibile, ma talvolta è veramente complicato far comprendere al cliente quanto un minimo dettaglio possa destrutturare parte intere di progetto
Implementazione
Solitamente la fase in cui emergono i problemi derivanti dal punto 1 e 2
Test
Fase in cui la direzione, i manager e gli sviluppatori incrociano le dita nella speranza che il cliente non avanzi richieste ulteriori (o ripensamenti) che destrutturerebbero l’intero progetto. A quel punto le vie sono 2: dire di no (poco carino nei confronti del cliente...) o chiedere al cliente di rimettere mano al portafogli (anche questo, non troppo elegante...).
Mantenimento
Se dopo tutte le premesse arriviamo fino a questa fase, dobbiamo veramente complimentarci con la nostra azienda e preoccuparci soltanto del funzionamento del prodotto rilasciato.
SCRUM: non additate l’individuo, agite sul Team
Secondo alcuni studi condotti negli Stati Uniti, intervenire sul singolo individuo cercando di renderlo più produttivo, più responsabile - in poche parole migliore - può arrivare a richiedere fino a 54 volte le energie necessarie a raddoppiare la produttività di un gruppo.
Oltre a questo, secondo i vari requisiti che lo scrum prevede, un team è in grado in modo completamente autonomo di agire direttamente sulla responsabilità e sulla produttività dell’individuo.
Secondo alcuni studi condotti negli Stati Uniti, intervenire sul singolo individuo cercando di renderlo più produttivo, più responsabile - in poche parole migliore - può arrivare a richiedere fino a 34 volte le energie necessarie a raddoppiare la produttività di un gruppo.
Inoltre, se applicato a pieno, lo SCRUM renderà il team capace di agire direttamente sul singolo individuo, aumentandone responsabilità e rendimento.
SCRUM: il miglioramento ciclico… tendente all’infinito
Di seguito riportiamo un elenco di principi sui quali SCRUM getta le proprie basi. Anche questi, come tutto il framework del resto, prevedono un approccio ciclico e correttivo sulla base delle esperienze pregresse:
The OODA Cycle Observe, Orient, Decide, Act: createvi un’ampia visuale di ciò che vi circonda, capite dove siete, decidete come agire, non indugiate e mantenete il focus fino all’obiettivo.
The PDCA Cycle Plan, Do, Check, Act: pianificate ogni azione, agite secondo i piani e riguardate questo film - che vi vede protagonisti - con spirito fortemente critico; chiedetevi come sareste potuti arrivare allo stesso risultato più velocemente e a minor costo. Ora agite, iniziando nuovamente il ciclo, tenendo presente il percorso fatto ma sperimentando sempre nuovi modi per migliorare le performance.
Il Multitasking non esiste. Molti di noi si vantano di avere tra le proprie skill l’ambitissimo multitasking... Gli studi dimostrano che il cervello umano ha una resa del 37% maggiore se si mantiene la concentrazione sullo stesso task, evitando cambi di contesto. In poche parole? Svolgere più mansioni contemporaneamente diminuisce sensibilmente la vostra produttività.
Fatelo bene, e alla prima. Questo è uno dei motivi per cui durante il dopoguerra i produttori di automobili giapponesi erano invidiati a livello mondiale per i loro “numeri”. Cosa facevano di così tanto speciale? Qualsiasi operaio, qualora riscontrasse un errore, una non conformità o un difetto nei vari componenti, aveva la facoltà di interrompere la catena affinché venisse risolto all’istante. È grazie a questo approccio che i giapponesi riescono ormai da anni a distribuire automobili qualitativamente equiparabili ai produttori tedeschi... ma a circa la metà del prezzo.
SCRUM: brevi Cicli, infiniti Feedback
Questa è forse una delle prerogative che maggiormente differenziano lo SCRUM e tutte le metodologie agile dagli altri approcci al project management. Lo SCRUM prevede infatti brevi cicli di sviluppo al termine dei quali si presenta una nuova funzionalità del prodotto.
Questo aiuta non soltanto il team di sviluppo ad avere dei sotto-obiettivi da raggiungere, ma anche il cliente a percepire veramente il valore del proprio prodotto e, eventualmente, a segnalare delle modifiche per tempo e non “a cose fatte”.
I protagonisti dello SCRUM
Gli Stakeholder
Lo SCRUM identifica negli stakeholder quelle figure che trarranno valore dal progetto. Questi possono essere i clienti stessi, degli sponsor o dei colleghi che dovranno far prendere al progetto una direzione piuttosto che un’altra.
Il Team
Come avrete ben capito, il team gioca un ruolo fondamentale nello scrum framework: è infatti la figura responsabile della creazione del prodotto e in lui devono coesistere le seguenti caratteristiche:
Un fine trascendente: Un team affiatato composto da individui mediocri è in grado di raggiungere una produttività quasi pari al 200% rispetto a un team totalmente slegato composto dalle migliori figure sulla piazza;
Cross-Functional. Un team deve essere in grado di far fronte a problemi disparati che possono riguardare ambienti anche diversi tra loro (nel caso del web development front-end, back-end, design, ecc.)
Libertà di organizzazione. Un team deve essere libero di prendere le proprie decisioni, senza alcuna pressione da parte della direzione e dei manager per la modalità in cui intendono svolgere un lavoro;
Addio ai ruoli. Un vero team agisce dimenticandosi pienamente dei ruoli dei suoi componenti e valorizza i suoi membri per ciò che fanno, non per il loro biglietto da visita.
Addio agli Eroi. Un team che funziona non ha bisogno di un eroe per arrivare all’obiettivo comune, ma è pienamente in grado di farlo in autonomia. Se esiste un elemento sul quale ricadono troppe responsabilità (o troppe ore di lavoro), significa il vostro team deve fare ancora molta strada.
Questo approccio prevede quindi che si venga inevitabilmente a creare una forte coesione all’interno del gruppo che, muovendosi in modo totalmente autonomo, sarà in grado di far fronte a tutte le difficoltà per poter raggiungere l’obiettivo comune.
Uno dei grandi pregi di questo approccio è che permette di attaccare i processi non funzionanti, piuttosto che gli individui non perfettamente preparati. Questo, oltre a rafforzare lo spirito del gruppo, non crea inutili climi di tensione all’interno di ambienti di lavoro.
Il Product Owner
Il Product Owner è la figura preposta alla massimizzazione del ROI all’interno di un progetto. Questa figura è in stretto contatto con il cliente ed è quindi in grado di definire quali sono le feature di un progetto che possono apportare il maggior business value. Per questo il Product Owner definisce le priorità delle feature da rilasciare per un progetto sulla base del rapporto tra maggiore valore percepito per il minor rischio.
Lo SCRUM Master o Servant Leader
Lo Scrum Master è una figura tecnica e manageriale che si inserisce all’interno del team di sviluppo come un leader a servizio del suo team. In tal senso, uno Scrum Master non assegna soltanto dei compiti, ma assiste il team anche nello svolgimento degli stessi. Il compito principale dello scrum master è quello di eliminare impedimenti vari riscontrati dal team durante la fase di sviluppo.
I rituali dello SCRUM
Lo Sprint
Lo Sprint è il periodo mediante il quale si articolano le fasi cicliche dello scrum. Al fine di dare il ritmo a tutte le figure coinvolte, lo sprint deve avere una durata fissa compresa tra 1 e 4 settimane.
La fase iniziale dello sprint è lo Sprint Planning, ovvero una riunione durante la quale il team, il Product Owner e lo scrum master si riuniscono per definire insieme le priorità delle feature e lo Sprint Goal, ovvero l’obiettivo che la squadra si propone di raggiungere entro la fine dello sprint.
Lo Sprint Planning
Durante la fase dello sprint planning entrano in gioco due oggetti fondamentali dello scrum framework:
il product backlog, una bacheca dove risiedono tutte le funzionalità del prodotto, ordinate, priorizzate e descritte come storie, piuttosto che come task;
la scrum board, una semplicissima whiteboard divisa in tre colonne - to do, doing, done - sulla quale saranno apposte le user stories sotto forma di sticky notes, di modo da rendere l’intera mole di lavoro visibile da tutto il team;
Il Planning Poker
Una volta presa visione di tutte le stories del prodotto, la squadra passa alla stima delle attività mediante una banalissima partita a carte, il Planning Poker: si distribuiscono al team delle carte raffiguranti dei numeri organizzati secondo la sequenza Fibonacci (1, 2, 3, 5, 8, 13, 21...).
Sulla base di difficoltà e tempistiche di implementazione, i giocatori daranno il loro voto, rigorosamente all’unisono, per non incappare nell’halo effect (alcuni membri del team potrebbero essere condizionati dal voto del membro più esperto e seguire la sua valutazione irrazionalmente). Se le stime combaciano, o comunque sono molto vicine tra loro, si attribuiscono alla feature la media algebrica risultato degli story points emersi dalla mano di poker. Qualora ci dovessero essere grosse differenze nella votazione, i membri che hanno espresso i voti più bassi e più alti spiegheranno al team ciò che li ha spinti ad attribuire il voto. Sulla base di queste spiegazioni, il resto del team potrebbe rendersi conto di dettagli che non aveva tenuto in considerazione al momento della votazione. Si ripete quindi la votazione all’unisono, attribuendo al task la media dei voti raccolti.
Il DoD
Una fase che sottolinea la meticolosità del metodo scrum, contrapposta alle varie libertà che lascia, è la redazione del DoD, il documento che determina la Definition of Done. In questo documento si elencano informalmente tutti i requisiti per contrassegnare una user story - una feature del prodotto - come done.
Il Burndown Chart
Una volta acquisito il necessario, il team può procedere allo sviluppo delle prime attività, monitorando, mediante un burndown chart, l’avanzamento delle attività: l’asse delle X rappresenta l’asse temporale: l’unità è rappresentata dalla giornata lavorativa e l’ultima data coincide con la fine dello sprint. L’asse delle Y indica invece l’ammontare dei task raccolti nello sprint e diminuirà nel tempo in base al loro stato di completion.
Grazie al burndown chart, il team può misurare la propria velocity, ovvero la quantità di story points che riesce a definire done in un determinato arco temporale. La velocity di un team darà al Product Owner la possibilità di valutare con gli stakeholders la fattibilità dei rilasci richiesti e la possibilità di effettuare stime economiche sempre più accurate.
I “Daily Stand-up” o Daily “SCRUMS”
Una volta organizzato il product backlog e riempita la scrum board da decine di sticky notes, il team si mette all’opera, riunendosi ogni mattina per un massimo di 15 minuti durante i quali ogni membro risponde a 3 domande:
Cosa hai fatto ieri per aiutare il team?
Cosa farai oggi per aiutare il team?
Che impedimenti hai avuto durante il lavoro?
È importante che il team risponda soltanto a queste tre domande e che il meeting non si trasformi in un brainstorming o altro. Questi 15 minuti serviranno al team per uniformarsi, orientarsi e per ripartire, ognuno cosciente dello stato di avanzamento dei lavori.
Lo Sprint Goal
Lo sprint goal è l’ultima fase dello sprint e si articola con una demo tenuta dal Product Owner con gli stakeholders. La demo dovrà rappresentare delle funzionalità tangibili, apprezzabili dagli stakeholders, di modo che ogni ciclo diffonda un senso di soddisfazione tra il team, tra i manager e tra gli stakeholders.
Il Product Owner si curerà di raccogliere tutti i feedback possibili dal cliente, di modo da intervenire quanto prima su eventuali modifiche da apportare al prodotto.
La Sprint Retrospective
Prima di concludere un ciclo e dare la vita al nuovo, ogni membro del team deve rispondere a quattro domande, al fine di monitorare non soltanto il livello di produttività del team, ma anche il livello di felicità e soddisfazione personale all’interno dell’azienda. Le domande sono:
In una scala da 1 a 5, come percepisci il tuo ruolo all’interno dell’azienda?
In una scala da 1 a 5, come percepisci l’azienda nel suo insieme?
Puoi giustificare i tuoi voti?
Qual è quella cosa che potrebbe renderti più felice durante il prossimo sprint?
Una volta finito il giro, il team seleziona una delle proposte di miglioramento emerse dal team e le attribuisce priorità massima per lo sprint successivo. Questo farà sì che la crescita aziendale non sia dovuta soltanto ad un aumento di produttività, ma anche ai vari miglioramenti proposti nel corso del tempo da coloro che più da vicino conoscono e vivono l’azienda.