L’avvento delle metodologie agile è stato sicuramente un fenomeno simile alla rivoluzione degli anni 60 , credo che tra i vari convegni in cui se ne è discusso ce ne siano stati molti epocali simili a una Woodstock dell’informatica, che, come mi succede spesso nella vita, ho solo sfiorato.
Però continuo ad incontrare gente che c’è stata e che si ferma sempre a raccontarmi che un evento così non si ripeterà mai più e come i programmatori di una volta si amavano, si scambiavano corone di fiori, ecc. Vabbè insomma il meme di Robert Downey Jr. ci sta tutto.
Il mio retaggio storico da consulente mi ha insegnato che parlare di Agile in contesti di Pubblica Amministrazione mette di malumore tutto il dipartimento in cui dovreste lavorare e vi fa sembrare uno di quei personaggi pronti per essere lapidati in Brian di Nazareth.
Al contrario in contesti di start up mostrare un gantt provoca un attacco di narcolessia e vertigini in molti board, se poi ci sono degli esagitati si rischia la rissa.
I non ortodossi però sanno che entrambi possono essere applicati in contesti dove il Cynefin ci permette di inquadrare il problema in termine di complessità, caos, semplice e complicato.
Ma una volta che si è presa una strada agile, si incomincia a valutare quale framework scegliere e lì inizia un’altra guerra, più piccola ma non per questo meno sanguinosa.
Nasce prima Scrum o l’Agile ?
Benché Scrum sia un framework agile, una sua forma primordiale è stata introdotta per la prima volta da Jeff Sutherland, John Scumniotales e Jeff McKenna nel 1986 presso la società di consulenza “Easel Corporation”. Inizialmente, il termine “Scrum” è stato mutuato dal contesto del rugby per descrivere un modo di giocare collaborativo, riprendendo le azioni della mischia.
Nel 1991, Jeff Sutherland presenta Scrum alla conferenza OOPSLA (Object-Oriented Programming, Systems, Languages & Applications), contribuendo a formalizzare i concetti di Scrum. In questo periodo, Ken Schwaber stava lavorando indipendentemente su metodi di sviluppo iterativi e si è unito a Sutherland per estendere e promuovere Scrum. Nel 1995 Schwaber e Sutherland pubblicano il primo articolo sulla Scrum Development Process nel 1995. In questo periodo, iniziano a definire i ruoli chiave di Scrum, come Product Owner, Scrum Master e Team di Sviluppo, insieme a eventi come Sprint e Sprint Review.
“Se intervistassimo 3 persone esperte di Scrum lo descriverebbero in maniera talmente diversa che sembrerebbe di stare in un celebre film di Kurosawa“
Nel 2001, Schwaber viene coinvolto nella stesura del Manifesto Agile a Snowbird, Utah, che sottolinea i principi fondamentali degli approcci agili nello sviluppo del software. Come è possibile leggere nella pagina che rievoca l’evento, Scrum è stato uno dei framework chiave menzionati nel Manifesto Agile.
Nel 2009, Ken Schwaber e Jeff Sutherland pubblicarono la prima versione dello “Scrum Guide”, un documento che definisce in modo chiaro e conciso i ruoli, gli eventi e gli artefatti di Scrum. Lo Scrum Guide è diventato la risorsa ufficiale per comprendere Scrum.
Scrum ha guadagnato popolarità oltre lo sviluppo software, estendendosi ad altre discipline come il project management, il product management e persino il marketing, ma c’è chi lo usa anche per cucinare. La sua applicazione si è diffusa in vari settori oltre quello tecnologico e oggi Scrum è uno dei framework agili più utilizzati, offrendo un approccio flessibile e collaborativo allo sviluppo di prodotti e alla gestione dei progetti. La Scrum Guide è periodicamente rivista per riflettere le migliori pratiche emergenti e mantenere Scrum aggiornato.
Ma cosa è Scrum?
Se intervistassimo 3 persone esperte di Scrum lo descriverebbero in maniera talmente diversa che sembrerebbe di stare in un celebre film di Kurosawa, quindi su quello che segue mettiamo tutti i manleva del mondo. Anche la descrizione che ne da scrum.org Scrum “aiuta le persone e i team a fornire valore in modo incrementale in modo collaborativo. In quanto framework agile, Scrum fornisce la struttura sufficiente per consentire a persone e team di integrarsi nel modo in cui lavorano, aggiungendo al contempo le pratiche giuste per ottimizzare le loro esigenze specifiche.” esordisce con la laconica frase “se state iniziando con scrum pensate a lui come….” ovvero il viaggio è meglio della destinazione e voi siete solo all’inizio.
In pratica fornisce una struttura per il lavoro collaborativo nell’ambito di progetti (complessi). È progettato per consentire il rapido sviluppo e la consegna di prodotti di qualità, concentrandosi sulla flessibilità e la risposta alle esigenze del cliente o del mercato.Quindi è:
Iterativo ed incrementale: Scrum organizza il lavoro in iterazioni chiamate sprint, ciascuna della durata di solito da una a quattro settimane. Durante ogni sprint, viene prodotto un incremento del prodotto.
Ruoli definiti: Scrum definisce chiaramente i ruoli principali, tra cui il Product Owner (responsabile del prodotto), lo Scrum Master (facilitatore del processo) e il Team di Sviluppo. Ogni ruolo ha responsabilità specifiche.
Backlog dei prodotti Il Product Owner mantiene un backlog dei prodotti, una lista prioritizzata di elementi di lavoro che rappresentano le funzionalità o gli obiettivi desiderati per il prodotto finale.
Pianificazione Sprint e riunioni Scrum All’inizio di ogni sprint, il team si riunisce per pianificare quali elementi del backlog saranno completati durante l’iterazione. Al termine di ogni giorno, si tiene una breve riunione chiamata Scrum daily per monitorare il progresso e identificare eventuali ostacoli. Ad oggi gli eventi più sanguinosi dopo le riunioni di condominio.
Revisione e retrospettiva: Alla fine di ogni sprint, il team tiene una revisione per dimostrare i risultati ottenuti durante lo sprint e rivedere il backlog. Successivamente, si svolge una retrospettiva per riflettere sulle prestazioni del team e identificare miglioramenti per gli sprint successivi.Qui viene misurata anche la famigerata “velocità del team”.
Trasparenza e ispezione regolari: Scrum è sinonimo di trasparenza.Attraverso strumenti come il backlog e il burndown chart, permette l’ispezione costante del progresso e la correzione del percorso, se necessario.
Adattabilità: Scrum è progettato per adattarsi a cambiamenti nei requisiti del prodotto o nelle priorità del cliente. L’adattabilità è incorporata nel framework, consentendo al team di rispondere prontamente ai feedback e alle modifiche richieste. Di solito in questi contesti il meno adattabile si dimostra lo scrum master.
Perchè scrum fa ‘schifo’
L’opinione su Scrum, o su qualsiasi framework o metodologia, varia a seconda delle esperienze personali, delle esigenze del progetto e del team che si ha a disposizione.
Molte persone trovano che Scrum non si adatta bene al loro contesto o che ci sono sfide specifiche nell’implementarlo, ma questa è la prima reazione ‘conservativa’ di ogni azienda che si trova di fronte a una novità e sappiamo dopo numerosi studi e altrettanti meme che la frase più pericolosa nell’economia moderna è “abbiamo sempre fatto così”
Se scendiamo un pò più nel dettaglio possiamo trovare delle critiche comuni:
Complessità: Molti sostengono che Scrum può sembrare complicato e richiedere una curva di apprendimento considerevole per essere implementato correttamente. Chiaramente questo dipende molto da chi ha provato a implementare scrum in azienda.
Come sappiamo la strada per l’inferno è lastricata delle migliori intenzioni e se avessi un euro per ogni persona inesperta che ha provato scrum nelle aziende lasciandolo morire dopo un po’, adesso avrei almeno l’equivalente di un Bitcoin.
Adattabilità: Alcuni contestano la capacità di Scrum di adattarsi efficacemente a tutti i tipi di progetti, soprattutto quelli di piccole dimensioni o altamente complessi. Personalmente per i piccoli funziona benissimo, sugli altamente complessi non posso metterci la mano sul fuoco perchè non ho mai mandato razzi sulla luna(per ora)
Focus sulla quantità di lavoro: Più d’una volta in corso d’opera molti si lamentavano che la focalizzazione su sprint e pianificazione basata sulla quantità di lavoro (stima degli story point) portava a una mancanza di attenzione sulla qualità del prodotto.E questo ahimè ho avuto modo di verificarlo più volte sulla mia pelle.Il team è formato da persone(per adesso 😀 ) e le persone, a seconda della seniority, ignorano che l’aspetto qualitativo non deve mai essere tralasciato. un problema culturale che è alla base del fallimento dell’adozione di scrum in quasi tutti i contesti.
Ruoli rigidi: Alcuni team potrebbero trovare che la struttura rigida dei ruoli in Scrum (Scrum Master, Product Owner, Team) può non adattarsi bene alla loro cultura aziendale o alle dinamiche del team.Anche qui non è la rigidità di scrum, ricordiamoci che è un framework, piuttosto quella delle persone, che lo fa sembrare poco adattabile in contesti non convenzionali.
Cambiamenti culturali difficili: Implementare Scrum può richiedere cambiamenti culturali significativi all’interno di un’organizzazione, e le persone possono resistere a tali cambiamenti. Credo che questo sia il nodo principale. Non è possibile adottare Scrum dove ci sia una resistenza culturale al cambiamento e le persone non capiscano appieno i benefici di un cambiamento del genere. Si rischia non solo di fallire nell’ implementazione del framework ma addirittura di uscirne molto meno convinti che Scrum possa essere la soluzione a molti problemi, rendendoci insicuri sulla sua adattabilità
Quasi tutte le critiche a Scrum derivano da interpretazioni o implementazioni scorrette, piuttosto che da difetti intrinseci del framework. Molte organizzazioni trovano Scrum estremamente utile per migliorare la trasparenza, la comunicazione e la ‘consegna’ del valore.
Come con qualsiasi metodologia, è importante adattare e personalizzare Scrum in base alle esigenze specifiche del team e del progetto.Ma sopratutto è sempre meglio testare la volontà di cambiamento dell’organizzazione in cui si va ad operare, come dice il poeta “non regalate terre promesse a chi non le mantiene”
