Cos'è Scrum?

Scrum è un framework per sviluppare, consegnare e sostenere prodotti complessi attraverso una collaborazione efficace del team. Fornisce un processo leggero per focalizzare e coordinare l'attività collaborativa basata sul team mentre il Team Scrum affronta problemi adattivi complicati e consegna un prodotto di valore ottimale in modo incrementale e secondo una pianificazione prevedibile.

Originariamente concepito dai professori Hirotaka Takeuchi e Ikujiro Nonaka e pubblicato come "The New Product Development Game" nella Harvard Business Review nel 1986, Scrum è stato adattato e reso popolare da Jeff Sutherland e Ken Schwaber negli anni '90. È diventato un modo di lavorare sempre più popolare, espandendosi dallo sviluppo software a molte aree dello sviluppo prodotto che possono applicare e beneficiare di un approccio iterativo e incrementale. Ha successo o fallisce in base alla competenza tecnica e agli sforzi collaborativi del team.

Da una prospettiva di processo, Scrum offre un approccio agile semplice ed estremamente efficace alla consegna dei prodotti. Come verrà mostrato più avanti, Scrum non è, e non è inteso per descrivere un approccio agile alla gestione dei progetti.  

Il framework include tre ruoli distinti che compongono un Team Scrum, ciascuno con responsabilità chiaramente definite, cinque eventi e tre artefatti. Le regole delineate nella Guida Scrum legano insieme i ruoli, gli eventi e gli artefatti, guidando le loro relazioni e interazioni.

• I 5 Eventi: lo Sprint, la Pianificazione dello Sprint, il Daily Scrum, la Revisione dello Sprint, la Retrospettiva dello Sprint
• I 3 Artefatti: Product Backlog, Sprint Backlog, Incremento del Prodotto
• I 3 Ruoli: Product Owner, Developer, Scrum Master.

1. Lo Sprint è un time-box, che può avere qualsiasi durata ma tipicamente è di 2-4 settimane, durante il quale vengono creati uno o più Incrementi di Prodotto "Done" (cioè utilizzabili e almeno potenzialmente rilasciabili). Lo Sprint contiene tutti gli altri eventi.
2. La Sprint Planning è dove il lavoro da svolgere nel prossimo Sprint viene pianificato dagli Sviluppatori. Negoziano un obiettivo di Sprint realistico con il Product Owner, selezionano elementi appropriati dal Product Backlog per contribuire a quell'obiettivo e pianificano il lavoro per raggiungerlo.
3. Il Daily Scrum è una riunione di 15 minuti tenuta dagli Sviluppatori nel Team Scrum. Si tiene ogni giorno dello Sprint e gli Sviluppatori lo utilizzano per riaffermare il loro impegno nel raggiungere l'obiettivo dello Sprint e adeguare i loro piani di conseguenza.
4. La Sprint Review si tiene alla fine dello Sprint. Il suo scopo è rendere visibile agli stakeholder ciò che è stato consegnato nello Sprint, per consentire loro di ispezionare formalmente e suggerire adattamenti al Product Backlog per guidare lo sviluppo in corso.
5. La Sprint Retrospective è un'opportunità per il Team Scrum di riflettere sull'efficacia del loro modo di lavorare e creare un piano di miglioramenti da attuare durante i prossimi Sprint successivi.

I tre artefatti di Scrum sono progettati per mantenere il focus sul valore da consegnare. Sono trasparenti – cioè deliberatamente visibili – a chiunque sia interessato a ciò che il Team Scrum sta facendo e a come stanno svolgendo il loro lavoro. Ogni artefatto include un impegno.

Il Product Backlog è una lista ordinata di tutto ciò che deve essere fatto per raggiungere il proprio Product Goal. È l'unica fonte di lavoro per il Team Scrum. Sebbene possano esserci più di un Product Goal, ad esempio per descrivere una roadmap di prodotto, si lavora su un solo obiettivo alla volta. Il Product Goal è l'obiettivo, l'impegno, che il Product Backlog è progettato per raggiungere.

Lo Sprint Backlog include l'insieme degli elementi del Product Backlog selezionati per uno Sprint e tutto il lavoro necessario per raggiungere lo Sprint Goal. Mentre uno o più Product Increment possono essere consegnati durante lo Sprint, c'è un solo Sprint Goal. Lo Sprint goal è l'impegno per lo Sprint Backlog ed è ciò che gli Sviluppatori si sforzano di raggiungere.

Il Product Increment è ciò che gli sviluppatori creano per soddisfare il bisogno descritto da uno o più elementi del product backlog. È un passo tangibile verso il raggiungimento dello Sprint Goal. Quando ne viene consegnato più di uno in uno Sprint, ogni Product Increment include quello precedente. L'impegno è raggiungere la 'Definition of Done' per il Product Increment. Questa 'Definition of Done' è una descrizione formale degli standard di qualità necessari che il prodotto deve soddisfare.

Sappiamo dal manifesto Agile che i praticanti dell'agilità valorizzano gli individui e le interazioni più dei processi e degli strumenti – il che significa che, pur essendoci uno spazio per processi e strumenti – e siamo molto chiari su questo, Scrum include un elemento di processo significativo – noi valorizziamo le persone e il modo in cui lavorano insieme, di più. I ruoli e le responsabilità associate a tali ruoli, così come le interazioni collaborative tra gli individui che ricoprono quei ruoli, sono fondamentali per l'uso efficace di Scrum.

Un Team Scrum è composto da un Product Owner, uno Scrum Master e, tipicamente, tra 5 e 9 Developer. Il team deve essere cross-funzionale – possedendo collettivamente tutte le competenze necessarie per consegnare il prodotto desiderato e la capacità di collaborare per raggiungere tale obiettivo. Il team è auto-organizzante – non riconosce alcuna struttura gerarchica e consente alla leadership per lavori specifici di emergere come appropriato.

Product Owner

Il Product Owner è responsabile della massimizzazione del valore del prodotto risultante dal lavoro del Team Scrum. Il Product Owner è un individuo, non un comitato e tipicamente rappresenta i bisogni di molti stakeholder, inclusi i clienti per i quali si sta creando valore. Nel contribuire al lavoro del Team Scrum, sono responsabili della gestione efficace del Product Backlog, che include:

• Sviluppare e comunicare esplicitamente il Product Goal.
• Creare e comunicare chiaramente gli elementi del Product Backlog.
• Dare priorità agli elementi del Product Backlog.
• Assicurarsi che il Product Backlog sia trasparente, visibile e compreso.

Qualsiasi stakeholder che voglia modificare il Product Backlog può farlo solo attraverso il Product Owner.

Developer

Il ruolo di Developer nel Team Scrum si applica a chiunque collabori attivamente con altri membri del team per sviluppare il Prodotto – anche qualcuno che ricopre uno degli altri ruoli può essere un Developer. Le competenze necessarie a un Developer varieranno a seconda del tipo di lavoro svolto e di ciò che viene prodotto. I Developer che lavorano in un Team Scrum per progettare un giardino avranno bisogno di un set di competenze molto diverso da quelli che preparano una cena elaborata o da quelli che sviluppano un nuovo gioco per smartphone. Scrum può essere applicato in tutti questi ambienti di sviluppo.

In Scrum, i Developer sono sempre responsabili di:

• Creare un piano per lo Sprint, il Sprint Backlog;
• Infondere qualità aderendo a una Definition of Done;
• Adattare il loro piano ogni giorno verso lo Sprint Goal; e,
• Ritenersi reciprocamente responsabili come professionisti.

Scrum Master

Lo Scrum Master è responsabile di stabilire Scrum come definito nella Scrum Guide. Lo fa aiutando tutti a comprendere la teoria e la pratica Scrum, sia all'interno del Team Scrum che nell'organizzazione.

Spesso definito come servant leader, lo Scrum master non detiene alcuna autorità di comando – non dice alle persone cosa fare e come comportarsi, le aiuta a capire come Scrum dovrebbe funzionare e fa tutto il possibile per facilitarne l'adozione. Fornisce un servizio a:

• Il Team Scrum – guidandoli nell'adozione di Scrum, aiutandoli a trovare modi per migliorare continuamente il modo in cui consegnano valore e causando la rimozione di tutto ciò che ostacola questo processo.
• Il Product Owner – aiutandolo nella gestione del Product Backlog e aiutandolo ad assicurarsi che i Product Goal e gli elementi del Product Backlog siano adeguatamente definiti, espressi e compresi.
• L'organizzazione più ampia in cui esiste il Team Scrum – aiutandola a comprendere il modo di lavorare Scrum e come devono lavorare e comportarsi per consentire ai Team Scrum di essere ottimamente efficaci.

Il framework Scrum si basa sulla teoria del controllo empirico dei processi, o empirismo, che sostiene che la conoscenza deriva dall'esperienza e il processo decisionale si basa su ciò che può essere osservato. I pilastri del controllo empirico dei processi sono la trasparenza del processo e del progresso, l'ispezione del processo e del progresso e l'adattamento sia del prodotto emergente (migliorandolo ad ogni iterazione e incremento) sia dei modi di lavorare (migliorando continuamente l'efficacia e le prestazioni del team).

È importante comprendere come rendere efficace il processo empirico. La Trasparenza consente l'Ispezione, l'Ispezione consente l'Adattamento e gli Adattamenti devono essere Trasparenti. L'Ispezione senza Trasparenza è fuorviante e dispendiosa, l'Ispezione senza un'intenzione di Adattamento è inutile e l'Adattamento senza Trasparenza per Ispezionarne l'impatto rende l'Adattamento rischioso.

I team Scrum efficaci vivono e respirano un insieme di cinque valori. Questi valori non sono unici di un team Scrum, ma rendendoli espliciti incoraggiano un lavoro di squadra collaborativo ed efficace. I valori sono Impegno, Focus, Apertura, Rispetto e Coraggio.

• Impegno: I membri del team Scrum si impegnano a raggiungere gli obiettivi dello sprint e a fornire lavoro di alta qualità attraverso lo sviluppo iterativo e la consegna incrementale. Questo favorisce la responsabilità e l'accountability tra i membri del team.
• Coraggio: I membri del team Scrum hanno il coraggio di affrontare apertamente sfide e impedimenti. Sono disposti a correre rischi e a parlare di questioni che potrebbero influenzare il successo del team.
• Apertura: I membri del team Scrum condividono informazioni, progressi e preoccupazioni tra loro, favorendo così fiducia e collaborazione all'interno del team.
• Focus: I membri del team Scrum mantengono un focus collettivo sugli obiettivi del Prodotto e dello Sprint, dando priorità al loro lavoro per ottimizzare la consegna di valore.
• Rispetto: I membri del team Scrum si rispettano reciprocamente come professionisti riconoscendo le competenze, le prospettive e i contributi degli altri mentre lavorano per consegnare il prodotto. Questo crea un ambiente di lavoro positivo e migliora la cooperazione tra i membri del team.

Questi valori possono e dovrebbero essere applicati per rendere efficace qualsiasi metodo di lavoro agile.

I valori Scrum contribuiscono collettivamente alla capacità del team Scrum di:

• Adattarsi al Cambiamento: Scrum è altamente reattivo ai requisiti che cambiano. Accoglie le esigenze in evoluzione del cliente consentendo aggiustamenti alla fine di ogni sprint, promuovendo flessibilità e maggiore soddisfazione del cliente.
• Collaborare per prendere decisioni: La natura auto-organizzante del Team Scrum e il fondamento empirico del modo di lavorare Scrum incoraggia la collaborazione. Vivere i valori Scrum dà vita al lavoro collaborativo.  
• Migliorare Continuamente: Scrum incorpora retrospettive regolari – il cui scopo è fornire opportunità regolari al Team Scrum per ispezionare l'efficacia del modo in cui lavora e identificare aree di miglioramento. Questo è il miglioramento continuo in azione.
• Abbracciare un Approccio Centrato sul Cliente: Scrum pone una forte enfasi nel fornire valore al cliente. Il Product Owner, che rappresenta gli interessi del cliente, stabilisce le priorità delle funzionalità, assicurando che il prodotto si allinei con i bisogni e le aspettative del cliente durante tutto il suo sviluppo.

Scrum offre numerosi vantaggi per lo sviluppo di prodotti, migliorando efficienza, collaborazione e adattabilità:

• Flessibilità
• Time to Market più Veloce
• Collaborazione Migliorata
• Qualità del Prodotto Migliorata
• Maggiore Soddisfazione del Cliente
• Produttività Aumentata
• Migliore Gestione del Rischio
• Trasparenza
• Team Responsabilizzati
• Miglioramento Continuo.

Scopri di più sui 10 vantaggi principali dell'utilizzo di Scrum, approfonditi in questo blog.

Scrum può presentare diverse sfide e svantaggi. Quando si implementa Scrum, come con tutti i nuovi modi di lavorare, potrebbe esserci resistenza al cambiamento. I team possono avere difficoltà con il livello di collaborazione e comunicazione necessario perché Scrum funzioni efficacemente. Ruoli come lo Scrum Master hanno anche responsabilità specifiche che differiscono dai ruoli tradizionali, e fraintendere questi ruoli può portare a confusione e inefficienza. Una volta implementato Scrum, ci sono ancora sfide da affrontare, i rischi o svantaggi comuni includono:-

1. Supporto Inadeguato del Management: Come per qualsiasi iniziativa di cambiamento senza un forte supporto del management all'interno dell'organizzazione, l'adozione di Scrum incontrerà resistenza o affronterà sfide nel superare le barriere organizzative. La mancanza di comprensione del cambiamento culturale necessario e un impegno debole a questo ai livelli superiori può limitare gravemente il valore che Scrum può offrire come modo di lavorare.
2. Curva di Apprendimento: Interruzioni e aggiustamenti iniziali possono impattare la produttività mentre i membri del team si adattano ai nuovi ruoli, eventi e processi collaborativi introdotti da Scrum. L'adagio che le cose possono peggiorare prima di migliorare è spesso vero. La chiave è concedere tempo per l'apprendimento e identificare persone con una storia di successo in questo ambito altrove che possano aiutare.
3. Eccessivo Impegno:  I team possono affrontare il rischio di impegnarsi eccessivamente nel lavoro durante la pianificazione dello sprint, portando a burnout o compromessi nella qualità dei deliverable. Bilanciare il desiderio di progresso rapido con un'impostazione realistica degli obiettivi è cruciale per mantenere pratiche di sviluppo sostenibili. È importante stabilire un ritmo sostenibile – aspettarsi fallimenti nel raggiungere gli Obiettivi dello Sprint mentre il team capisce cosa può essere realizzato.
4. Eccessiva Enfasi sugli Obiettivi a Breve Termine: Il focus su sprint brevi e di lunghezza fissa in Scrum può a volte portare a una visione miope, dove i team danno priorità agli obiettivi immediati rispetto agli obiettivi strategici a lungo termine. In un ambiente di prodotto puro, un buon Product Owner dovrebbe essere in grado di comunicare e mantenere un focus appropriato a lungo termine. Quando sfidati dalla complessità potrebbe essere necessario qualcosa di più…
5. Problemi nell'integrare il lavoro di più team per iniziative più grandi e complesse: Scrum è forte quando applicato a singoli team ma estremamente debole quando il lavoro da fare supera la capacità delle '10 o meno' persone nel team per realizzarlo. In questa circostanza, è raccomandato un framework più ampio per gestire scala e/o complessità.

Per scala estrema in un contesto di prodotto – dove sono necessarie centinaia di sviluppatori – un framework scalato come SAFe può essere consigliabile. Per problemi di scala più piccola – fino a 100 sviluppatori, per esempio – e/o dove la complessità della soluzione aziendale complessiva abbraccia più prodotti, servizi e altre attività, allora un framework di progetto agile come AgilePM risponderà al bisogno.  

Basandosi sul problema di scaling menzionato sopra, in questo episodio della serie 'Level Up' di APMG, gli esperti di gestione progetti agile rispondono a domande sulla gestione progetti agile e scrum. Una delle domande chiave affrontate è la differenza tra questi approcci.  Vengono discusse questioni come la pianificazione degli sprint, la durata ideale di uno Sprint e il valore dei daily stand-up.

L'Agile Business Consortium ha fatto evolvere il proprio approccio leader mondiale alla Gestione Agile dei Progetti (AgilePM) per fornire una versione progettata specificamente per funzionare con Scrum. AgilePM for Scrum offre un framework unico per la consegna di soluzioni aziendali complete. Si occupa esplicitamente di soluzioni che comprendono più prodotti o servizi, richiedendo lo sforzo di sviluppo combinato di più team scrum, o una combinazione di team scrum e non-scrum. Con tecniche per gestire la pianificazione e il coordinamento agile tra team, la leadership dal punto di vista della visione aziendale, dell'architettura della soluzione e della gestione dei progetti, governance, rischi e altro ancora, questo merita sicuramente di essere considerato per situazioni progettuali più complesse.

In questo video, Richard Pharro, CEO di APMG International, e io discutiamo di 'AgilePM for Scrum.' Questo nuovo framework unisce i punti di forza di due framework Agile leader. Richard pone domande chiave, mirando a fornire approfondimenti sul framework, incluso il suo ambito, la logica alla base del suo sviluppo e chi può trarne maggior beneficio. Inoltre, esploriamo il programma di formazione e certificazione accreditato che supporta questo framework.

Scrum ha tracciato un sentiero significativo per l'agilità nello sviluppo di prodotti software ed è un approccio molto popolare e versatile per ottime ragioni, essendo perfettamente adatto per fornire prodotti che deliziano i clienti di fronte a requisiti complessi e in evoluzione. Sfrutta i vantaggi di team interfunzionali e collaborativi per fornire valore più rapidamente ed efficientemente rispetto alle loro controparti meno agili.

Non è privo di sfide, però... Ken Schwaber e Jeff Sutherland affermano nella loro Scrum Guide 2020 che "Il framework Scrum, come delineato qui, è immutabile. Sebbene sia possibile implementare solo parti di Scrum, il risultato non è Scrum. Scrum esiste solo nella sua interezza..."

Scrum è un framework agile semplice, elegante ed efficace per la consegna di prodotti. Questo è stato dimostrato più e più volte in tutto il mondo in molte applicazioni diverse attraverso molti settori diversi, ma solo quando utilizzato nella sua interezza. Se lasci fuori qualsiasi elemento di Scrum, semplicemente non funzionerà correttamente. Scrum funziona, ScrumBut rischia il fallimento. ScrumBut descrive una situazione in cui "usiamo Scrum ma non facciamo questo".  Per 'non facciamo questo' inserisci quello che vuoi... "Non facciamo uno Scrum quotidiano", "non collaboriamo", "non abbiamo uno Scrum Master abbiamo un manager", "non abbiamo un product backlog, abbiamo una specifica", "non definiamo un Sprint Goal" ecc. Schwaber e Sutherland hanno sviluppato Scrum, hanno supervisionato la sua evoluzione graduale e attenta dalla metà degli anni '90 – accetta la loro saggezza e fallo correttamente.  

Se il tuo obiettivo è lo sviluppo di prodotti, allora è facile vedere come portare agilità a quell'obiettivo applicando e migliorando continuamente l'applicazione di Scrum potrebbe fornire enormi benefici. Ma se la tua preoccupazione si estende oltre il puro sviluppo di prodotti, allora, da solo, Scrum potrebbe rivelarsi inadeguato.

Formazione, educazione e incoraggiamento e supporto continui dei Team Scrum sono necessari per sfruttare il successo di Scrum. APMG offre le seguenti certificazioni per i ruoli chiave.

Questo corso ti insegna a eccellere come Scrum Master, migliorando lo sviluppo di prodotti e soluzioni utilizzando Scrum. Gli apprendimenti chiave includono una comprensione completa del Framework Scrum, i principi Scrum e il ruolo dello Scrum Master. Imparerai anche come costruire team di sviluppo efficaci, agire come servant-leader, facilitare gli eventi Scrum, aiutare i Product Owner nella gestione del backlog e promuovere l'adozione di Scrum.

In questo corso impara come massimizzare il valore dei prodotti consegnati dai Team Scrum. Acquisisci una comprensione approfondita del Framework Scrum e del ruolo del Scrum Product Owner. Padroneggia i principi Scrum e come costruire e dare priorità a un product backlog orientato al valore, suddividendo epic e temi in user story attuabili.

Il primo giorno dei corsi Scrum Master e Product Owner è identico – parla con il tuo provider di formazione APMG riguardo alla erogazione di questa giornata come corso autonomo, ideale per i membri del team e gli stakeholder. Copre tutto ciò che è contenuto nella Scrum Guide – e hanno bisogno di conoscerlo tutto.   

AgilePM for Scrum combina Scrum con il principale approccio di gestione dei progetti agile al mondo (AgilePM) per offrire un unico framework per la realizzazione di soluzioni aziendali complete dove è richiesto uno sviluppo iterativo e incrementale. Questa certificazione ti fornisce le competenze per integrare Scrum con Agile Project Management. I corsi affrontano i principi e la teoria alla base del framework Scrum – erogati da fornitori accreditati APMG e Agile Business Consortium.

L'immagine del 'Scrum Framework' è stata creata dall'Agile Business Consortium. Copyright © 2024, Agile Business Consortium. Tutti i diritti riservati.