Guida Scrum

Scopo della Guida Scrum

Abbiamo sviluppato Scrum nei primi anni ’90. Abbiamo scritto la prima versione della Guida Scrum nel 2010 per aiutare le persone in tutto il mondo a comprendere Scrum. Da allora abbiamo fatto evolvere la Guida attraverso piccoli aggiornamenti funzionali. Insieme, ne sosteniamo il contenuto.

La Guida Scrum contiene la definizione di Scrum. Ogni elemento del framework serve uno scopo specifico che è essenziale per il valore complessivo e i risultati ottenuti con Scrum. Modificare il design fondamentale o le idee di Scrum, tralasciare elementi o non seguire le regole di Scrum, nasconde i problemi e limita i benefici di Scrum, potenzialmente rendendolo persino inutile.

Seguiamo la crescente adozione di Scrum in un mondo sempre più complesso. Siamo onorati di vedere Scrum adottato in molti ambiti che presentano lavoro essenzialmente complesso, oltre allo sviluppo di prodotti software dove Scrum ha le sue radici. Man mano che l’uso di Scrum si diffonde, sviluppatori, ricercatori, analisti, scienziati e altri specialisti svolgono il lavoro. Utilizziamo la parola “sviluppatori” in Scrum non per escludere, ma per semplificare. Se ottieni valore da Scrum, considerati incluso.

Man mano che Scrum viene utilizzato, pattern, processi e intuizioni che si adattano al framework Scrum come descritto in questo documento, possono essere trovati, applicati e ideati. La loro descrizione va oltre lo scopo della Guida Scrum perché sono sensibili al contesto e differiscono ampiamente tra i diversi utilizzi di Scrum. Tali tattiche per l’utilizzo all’interno del framework Scrum variano ampiamente e sono descritte altrove.

Ken Schwaber & Jeff Sutherland, novembre 2020

Definizione di Scrum

Scrum è un framework leggero che aiuta persone, team e organizzazioni a generare valore attraverso soluzioni adattive per problemi complessi.

In sintesi, Scrum richiede uno Scrum Master per creare un ambiente in cui:

• Un Product Owner ordina il lavoro per un problema complesso in un Product Backlog.
• Il team Scrum trasforma una selezione del lavoro in un Incremento di valore durante uno Sprint.
• Il team Scrum e i suoi stakeholder ispezionano i risultati e si adattano per lo Sprint successivo.
• Ripetere

Scrum è semplice. Provalo così com’è e determina se la sua filosofia, teoria e struttura aiutano a raggiungere gli obiettivi e creare valore. Il framework Scrum è volutamente incompleto, definendo solo le parti necessarie per implementare la teoria Scrum. Scrum è costruito dall’intelligenza collettiva delle persone che lo utilizzano. Piuttosto che fornire istruzioni dettagliate, le regole di Scrum guidano le relazioni e le interazioni.

Vari processi, tecniche e metodi possono essere impiegati all’interno del framework. Scrum si integra con le pratiche esistenti o le rende superflue. Scrum rende visibile l’efficacia relativa dell’attuale gestione, ambiente e tecniche di lavoro, in modo che possano essere apportati miglioramenti.

Teoria di Scrum

Scrum si fonda sull’empirismo e sul pensiero lean. L’empirismo afferma che la conoscenza deriva dall’esperienza e dalle decisioni basate su ciò che viene osservato. Il pensiero lean riduce gli sprechi e si concentra sull’essenziale.

Scrum impiega un approccio iterativo e incrementale per ottimizzare la prevedibilità e controllare il rischio. Scrum coinvolge gruppi di persone che collettivamente possiedono tutte le competenze e l’esperienza per svolgere il lavoro e condividere o acquisire tali competenze secondo necessità.

Scrum combina quattro eventi formali per l’ispezione e l’adattamento all’interno di un evento contenitore, lo Sprint. Questi eventi funzionano perché implementano i pilastri empirici di Scrum: trasparenza, ispezione e adattamento.

Trasparenza

Il processo emergente e il lavoro devono essere visibili a chi svolge il lavoro e a chi lo riceve. Con Scrum, le decisioni importanti si basano sullo stato percepito dei suoi tre artefatti formali. Gli artefatti con bassa trasparenza possono portare a decisioni che diminuiscono il valore e aumentano il rischio.

La trasparenza abilita l’ispezione. L’ispezione senza trasparenza è fuorviante e dispendiosa.

Ispezione

Gli artefatti Scrum e il progresso verso gli obiettivi concordati devono essere ispezionati frequentemente e diligentemente per rilevare variazioni o problemi potenzialmente indesiderati. Per facilitare l’ispezione, Scrum fornisce una cadenza attraverso i suoi cinque eventi.

L’ispezione abilita l’adattamento. L’ispezione senza adattamento è considerata inutile. Gli eventi Scrum sono progettati per provocare il cambiamento.

Adattamento

Se qualsiasi aspetto di un processo devia oltre i limiti accettabili o se il prodotto risultante è inaccettabile, il processo applicato o i materiali prodotti devono essere adeguati. L’adeguamento deve essere effettuato il prima possibile per minimizzare ulteriori deviazioni.

L’adattamento diventa più difficile quando le persone coinvolte non sono empowered o auto-gestite. Un team Scrum è tenuto ad adattarsi nel momento in cui apprende qualcosa di nuovo attraverso l’ispezione.

Valori di Scrum

Il successo nell’uso di Scrum dipende dalla capacità delle persone di diventare più competenti nel vivere cinque valori:

• Impegno
• Focus
• Apertura
• Rispetto
• Coraggio

Il team Scrum si impegna a raggiungere i propri obiettivi e a sostenersi reciprocamente. Il focus principale è sul lavoro dello Sprint per fare il miglior progresso possibile verso questi obiettivi. Il team Scrum e i suoi stakeholder sono aperti riguardo al lavoro e alle sfide. I membri del team Scrum si rispettano reciprocamente come persone capaci e indipendenti, e sono rispettati come tali dalle persone con cui lavorano. I membri del team Scrum hanno il coraggio di fare la cosa giusta, di lavorare su problemi difficili.

Questi valori danno direzione al team Scrum riguardo al loro lavoro, alle azioni e al comportamento. Le decisioni prese, i passi compiuti e il modo in cui Scrum viene utilizzato dovrebbero rafforzare questi valori, non diminuirli o comprometterli. I membri del team Scrum imparano e esplorano i valori mentre lavorano con gli eventi e gli artefatti Scrum. Quando questi valori sono incarnati dal team Scrum e dalle persone con cui lavorano, i pilastri empirici di Scrum – trasparenza, ispezione e adattamento – prendono vita costruendo fiducia.

Team Scrum

L’unità fondamentale di Scrum è un piccolo team di persone, un team Scrum. Il team Scrum è composto da uno Scrum Master, un Product Owner e i Developer. All’interno di un team Scrum non ci sono sotto-team o gerarchie. È un’unità coesa di professionisti concentrati su un obiettivo alla volta, il Product Goal.

I team Scrum sono cross-funzionali, il che significa che i membri possiedono tutte le competenze necessarie per creare valore a ogni Sprint. Sono anche auto-gestiti, il che significa che decidono internamente chi fa cosa, quando e come.

Il team Scrum è abbastanza piccolo da rimanere agile e abbastanza grande da completare un lavoro significativo all’interno di uno Sprint, tipicamente 10 persone o meno. In generale, abbiamo riscontrato che i team più piccoli comunicano meglio e sono più produttivi. Se i team Scrum diventano troppo grandi, dovrebbero considerare di riorganizzarsi in più team Scrum coesi, ciascuno focalizzato sullo stesso prodotto. Pertanto, dovrebbero condividere lo stesso Product Goal, Product Backlog e Product Owner.

Il team Scrum è responsabile di tutte le attività legate al prodotto: dalla collaborazione con gli stakeholder, alla verifica, alla manutenzione, all’operatività, alla sperimentazione, alla ricerca e sviluppo e a qualsiasi altra cosa possa essere necessaria. Sono strutturati e abilitati dall’organizzazione a gestire il proprio lavoro. Lavorare in Sprint a un ritmo sostenibile migliora il focus e la coerenza del team Scrum.

L’intero team Scrum è responsabile della creazione di un Incremento di valore e utile a ogni Sprint. Scrum definisce tre responsabilità specifiche all’interno del team Scrum: i Developer, il Product Owner e lo Scrum Master.

Developer

I Developer sono le persone nel team Scrum impegnate a creare qualsiasi aspetto di un Incremento utilizzabile a ogni Sprint.

Le competenze specifiche necessarie ai Developer sono spesso ampie e variano con il dominio di lavoro. Tuttavia, i Developer sono sempre responsabili di:

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

Product Owner

Il Product Owner è responsabile della massimizzazione del valore del prodotto risultante dal lavoro del team Scrum. Come questo viene fatto può variare ampiamente tra organizzazioni, team Scrum e individui.

Il Product Owner è anche responsabile della gestione efficace del Product Backlog, che include:

• Sviluppare e comunicare esplicitamente il Product Goal;
• Creare e comunicare chiaramente i Product Backlog Item;
• Ordinare i Product Backlog Item; e
• Assicurare che il Product Backlog sia trasparente, visibile e compreso.

Il Product Owner può svolgere il lavoro sopra descritto o può delegare la responsabilità ad altri. In ogni caso, il Product Owner rimane il responsabile.

Perché i Product Owner abbiano successo, l’intera organizzazione deve rispettare le loro decisioni. Queste decisioni sono visibili nel contenuto e nell’ordinamento del Product Backlog e attraverso l’Incremento ispezionabile alla Sprint Review.

Il Product Owner è una persona, non un comitato. Il Product Owner può rappresentare le esigenze di molti stakeholder nel Product Backlog. Coloro che desiderano modificare il Product Backlog possono farlo cercando di convincere il Product Owner.

Scrum Master

Lo Scrum Master è responsabile dell’istituzione di Scrum come definito nella Guida Scrum. Lo fa aiutando tutti a comprendere la teoria e la pratica di Scrum, sia all’interno del team Scrum che nell’organizzazione.

Lo Scrum Master è responsabile dell’efficacia del team Scrum. Lo fa abilitando il team Scrum a migliorare le proprie pratiche, all’interno del framework Scrum.

Gli Scrum Master sono veri leader che servono il team Scrum e l’organizzazione più ampia. Lo Scrum Master serve il team Scrum in diversi modi, tra cui:

• Fare coaching ai membri del team nell’auto-gestione e nella cross-funzionalità;
• Aiutare il team Scrum a concentrarsi sulla creazione di Incrementi di alto valore che soddisfano la Definition of Done;
• Causare la rimozione degli impedimenti al progresso del team Scrum; e
• Assicurare che tutti gli eventi Scrum si svolgano e siano positivi, produttivi e contenuti nel timebox.

Lo Scrum Master serve il Product Owner in diversi modi, tra cui:

• Aiutare a trovare tecniche per una definizione efficace del Product Goal e la gestione del Product Backlog;
• Aiutare il team Scrum a comprendere la necessità di Product Backlog Item chiari e concisi;
• Aiutare a stabilire una pianificazione empirica del prodotto per un ambiente complesso; e
• Facilitare la collaborazione con gli stakeholder come richiesto o necessario.

Lo Scrum Master serve l’organizzazione in diversi modi, tra cui:

• Guidare, formare e fare coaching all’organizzazione nell’adozione di Scrum;
• Pianificare e consigliare le implementazioni di Scrum all’interno dell’organizzazione;
• Aiutare dipendenti e stakeholder a comprendere e attuare un approccio empirico per il lavoro complesso; e
• Rimuovere le barriere tra gli stakeholder e i team Scrum.

Eventi Scrum

Lo Sprint è un contenitore per tutti gli altri eventi. Ogni evento in Scrum è un’opportunità formale per ispezionare e adattare gli artefatti Scrum. Questi eventi sono specificamente progettati per abilitare la trasparenza necessaria.

Non operare qualsiasi evento come prescritto comporta la perdita di opportunità di ispezione e adattamento. Gli eventi sono utilizzati in Scrum per creare regolarità e minimizzare la necessità di riunioni non definite in Scrum.

Idealmente, tutti gli eventi si tengono nello stesso momento e luogo per ridurre la complessità.

Lo Sprint

Gli Sprint sono il battito cardiaco di Scrum, dove le idee vengono trasformate in valore.

Sono eventi a durata fissa di un mese o meno per creare coerenza. Un nuovo Sprint inizia immediatamente dopo la conclusione dello Sprint precedente.

Tutto il lavoro necessario per raggiungere il Product Goal, inclusi Sprint Planning, Daily Scrum, Sprint Review e Sprint Retrospective, avviene all’interno degli Sprint.

Durante lo Sprint:

• Non vengono effettuate modifiche che metterebbero in pericolo lo Sprint Goal;
• La qualità non diminuisce;
• Il Product Backlog viene raffinato secondo necessità; e
• L’ambito può essere chiarito e rinegoziato con il Product Owner man mano che si apprende di più.

Gli Sprint abilitano la prevedibilità garantendo l’ispezione e l’adattamento del progresso verso un Product Goal almeno ogni mese. Quando l’orizzonte di uno Sprint è troppo lungo, lo Sprint Goal potrebbe diventare invalido, la complessità potrebbe aumentare e il rischio potrebbe crescere. Sprint più brevi possono essere impiegati per generare più cicli di apprendimento e limitare il rischio di costi e sforzi a un arco temporale più breve. Ogni Sprint può essere considerato un breve progetto.

Esistono varie pratiche per prevedere il progresso, come burn-down, burn-up o flussi cumulativi. Sebbene si siano dimostrate utili, queste non sostituiscono l’importanza dell’empirismo. In ambienti complessi, ciò che accadrà è sconosciuto. Solo ciò che è già accaduto può essere utilizzato per decisioni orientate al futuro.

Uno Sprint potrebbe essere cancellato se lo Sprint Goal diventa obsoleto. Solo il Product Owner ha l’autorità di cancellare lo Sprint.

Sprint Planning

Lo Sprint Planning avvia lo Sprint definendo il lavoro da svolgere durante lo Sprint. Il piano risultante è creato dal lavoro collaborativo dell’intero team Scrum.

Il Product Owner assicura che i partecipanti siano preparati a discutere i Product Backlog Item più importanti e come si collegano al Product Goal. Il team Scrum può anche invitare altre persone a partecipare allo Sprint Planning per fornire consigli.

Lo Sprint Planning affronta i seguenti argomenti:

Argomento uno: Perché questo Sprint è prezioso?
Il Product Owner propone come il prodotto potrebbe aumentare il suo valore e la sua utilità nello Sprint corrente. L’intero team Scrum collabora quindi per definire uno Sprint Goal che comunichi perché lo Sprint è prezioso per gli stakeholder. Lo Sprint Goal deve essere finalizzato prima della fine dello Sprint Planning.

Argomento due: Cosa può essere fatto in questo Sprint?
Attraverso la discussione con il Product Owner, i Developer selezionano gli elementi dal Product Backlog da includere nello Sprint corrente. Il team Scrum può raffinare questi elementi durante questo processo, il che aumenta la comprensione e la fiducia.

Selezionare quanto può essere completato all’interno di uno Sprint può essere impegnativo. Tuttavia, più i Developer conoscono le proprie prestazioni passate, la propria capacità futura e la propria Definition of Done, più saranno fiduciosi nelle proprie previsioni di Sprint.

Argomento tre: Come verrà svolto il lavoro scelto?
Per ogni Product Backlog Item selezionato, i Developer pianificano il lavoro necessario per creare un Incremento che soddisfi la Definition of Done. Questo viene spesso fatto scomponendo i Product Backlog Item in elementi di lavoro più piccoli di un giorno o meno. Come questo viene fatto è a totale discrezione dei Developer. Nessun altro dice loro come trasformare i Product Backlog Item in Incrementi di valore.

Lo Sprint Goal, i Product Backlog Item selezionati per lo Sprint, più il piano per la loro consegna sono complessivamente denominati Sprint Backlog.

Lo Sprint Planning ha un timebox massimo di otto ore per uno Sprint di un mese. Per Sprint più brevi, l’evento è solitamente più corto.

Daily Scrum

Lo scopo del Daily Scrum è ispezionare il progresso verso lo Sprint Goal e adattare lo Sprint Backlog secondo necessità, aggiustando il lavoro pianificato successivo.

Il Daily Scrum è un evento di 15 minuti per i Developer del team Scrum. Per ridurre la complessità, si tiene alla stessa ora e nello stesso luogo ogni giorno lavorativo dello Sprint. Se il Product Owner o lo Scrum Master stanno lavorando attivamente su elementi dello Sprint Backlog, partecipano come Developer.

I Developer possono selezionare qualsiasi struttura e tecnica desiderino, purché il loro Daily Scrum si concentri sul progresso verso lo Sprint Goal e produca un piano attuabile per il giorno di lavoro successivo. Questo crea focus e migliora l’auto-gestione.

I Daily Scrum migliorano la comunicazione, identificano gli impedimenti, promuovono decisioni rapide e di conseguenza eliminano la necessità di altre riunioni.

Il Daily Scrum non è l’unico momento in cui i Developer possono aggiustare il loro piano. Spesso si incontrano durante la giornata per discussioni più dettagliate sull’adattamento o la ripianificazione del resto del lavoro dello Sprint.

Sprint Review

Lo scopo della Sprint Review è ispezionare il risultato dello Sprint e determinare gli adattamenti futuri. Il team Scrum presenta i risultati del proprio lavoro agli stakeholder chiave e si discute il progresso verso il Product Goal.

Durante l’evento, il team Scrum e gli stakeholder esaminano ciò che è stato realizzato nello Sprint e cosa è cambiato nel loro ambiente. Sulla base di queste informazioni, i partecipanti collaborano su cosa fare dopo. Il Product Backlog può anche essere aggiustato per soddisfare nuove opportunità. La Sprint Review è una sessione di lavoro e il team Scrum dovrebbe evitare di limitarla a una presentazione.

La Sprint Review è il penultimo evento dello Sprint ed ha un timebox massimo di quattro ore per uno Sprint di un mese. Per Sprint più brevi, l’evento è solitamente più corto.

Sprint Retrospective

Lo scopo della Sprint Retrospective è pianificare modi per aumentare la qualità e l’efficacia.

Il team Scrum esamina come è andato l’ultimo Sprint riguardo a individui, interazioni, processi, strumenti e la propria Definition of Done. Gli elementi esaminati variano spesso con il dominio di lavoro.

Le assunzioni che li hanno portati fuori strada vengono identificate e le loro origini esplorate. Il team Scrum discute cosa è andato bene durante lo Sprint, quali problemi ha incontrato e come quei problemi sono stati (o non sono stati) risolti.

Il team Scrum identifica i cambiamenti più utili per migliorare la propria efficacia. I miglioramenti di maggior impatto vengono affrontati il prima possibile. Possono anche essere aggiunti allo Sprint Backlog per lo Sprint successivo.

La Sprint Retrospective conclude lo Sprint. Ha un timebox massimo di tre ore per uno Sprint di un mese. Per Sprint più brevi, l’evento è solitamente più corto.

Artefatti Scrum

Gli artefatti di Scrum rappresentano lavoro o valore. Sono progettati per massimizzare la trasparenza delle informazioni chiave. Così, tutti coloro che li ispezionano hanno la stessa base per l’adattamento.

Ogni artefatto contiene un impegno per assicurare che fornisca informazioni che migliorano la trasparenza e il focus rispetto ai quali il progresso può essere misurato:

• Per il Product Backlog è il Product Goal.
• Per lo Sprint Backlog è lo Sprint Goal.
• Per l’Incremento è la Definition of Done.

Questi impegni esistono per rafforzare l’empirismo e i valori Scrum per il team Scrum e i loro stakeholder.

Product Backlog

Il Product Backlog è una lista emergente e ordinata di ciò che è necessario per migliorare il prodotto. È l’unica fonte di lavoro intrapreso dal team Scrum.

I Product Backlog Item che possono essere completati dal team Scrum all’interno di uno Sprint sono considerati pronti per la selezione in un evento di Sprint Planning. Solitamente acquisiscono questo grado di trasparenza dopo le attività di raffinamento. Il raffinamento del Product Backlog è l’atto di scomporre e definire ulteriormente i Product Backlog Item in elementi più piccoli e precisi. Questa è un’attività continua per aggiungere dettagli, come descrizione, ordine e dimensione. Gli attributi variano spesso con il dominio di lavoro.

I Developer che svolgeranno il lavoro sono responsabili del dimensionamento. Il Product Owner può influenzare i Developer aiutandoli a comprendere e selezionare i compromessi.

Impegno: Product Goal

Il Product Goal descrive uno stato futuro del prodotto che può servire come obiettivo verso cui il team Scrum pianifica. Il Product Goal è nel Product Backlog. Il resto del Product Backlog emerge per definire “cosa” soddisferà il Product Goal.

Un prodotto è un veicolo per fornire valore. Ha un confine chiaro, stakeholder noti, utenti o clienti ben definiti. Un prodotto potrebbe essere un servizio, un prodotto fisico o qualcosa di più astratto.

Il Product Goal è l’obiettivo a lungo termine per il team Scrum. Devono realizzare (o abbandonare) un obiettivo prima di assumerne un altro.

Sprint Backlog

Lo Sprint Backlog è composto dallo Sprint Goal (perché), dall’insieme dei Product Backlog Item selezionati per lo Sprint (cosa), nonché da un piano attuabile per la consegna dell’Incremento (come).

Lo Sprint Backlog è un piano dei Developer e per i Developer. È un’immagine altamente visibile e in tempo reale del lavoro che i Developer prevedono di realizzare durante lo Sprint per raggiungere lo Sprint Goal.

Di conseguenza, lo Sprint Backlog viene aggiornato durante tutto lo Sprint man mano che si apprende di più. Dovrebbe avere abbastanza dettaglio da permettere ai Developer di ispezionare il proprio progresso nel Daily Scrum.

Impegno: Sprint Goal

Lo Sprint Goal è l’unico obiettivo per lo Sprint. Sebbene lo Sprint Goal sia un impegno dei Developer, fornisce flessibilità in termini del lavoro esatto necessario per raggiungerlo. Lo Sprint Goal crea anche coerenza e focus, incoraggiando il team Scrum a lavorare insieme piuttosto che su iniziative separate.

Lo Sprint Goal viene creato durante l’evento di Sprint Planning e poi aggiunto allo Sprint Backlog. Mentre i Developer lavorano durante lo Sprint, tengono lo Sprint Goal presente. Se il lavoro risulta diverso da quanto previsto, collaborano con il Product Owner per negoziare l’ambito dello Sprint Backlog all’interno dello Sprint senza influire sullo Sprint Goal.

Incremento

Un Incremento è un concreto passo avanti verso il Product Goal. Ogni Incremento si aggiunge a tutti gli Incrementi precedenti ed è verificato accuratamente, assicurando che tutti gli Incrementi funzionino insieme. Per fornire valore, l’Incremento deve essere utilizzabile.

Più Incrementi possono essere creati all’interno di uno Sprint. La somma degli Incrementi viene presentata alla Sprint Review, supportando così l’empirismo. Tuttavia, un Incremento può essere consegnato agli stakeholder prima della fine dello Sprint. La Sprint Review non dovrebbe mai essere considerata una porta per il rilascio di valore.

Il lavoro non può essere considerato parte di un Incremento a meno che non soddisfi la Definition of Done.

Impegno: Definition of Done

La Definition of Done è una descrizione formale dello stato dell’Incremento quando soddisfa le misure di qualità richieste per il prodotto.

Nel momento in cui un Product Backlog Item soddisfa la Definition of Done, nasce un Incremento.

La Definition of Done crea trasparenza fornendo a tutti una comprensione condivisa di quale lavoro è stato completato come parte dell’Incremento. Se un Product Backlog Item non soddisfa la Definition of Done, non può essere rilasciato o nemmeno presentato alla Sprint Review. Invece, ritorna al Product Backlog per una considerazione futura.

Se la Definition of Done per un incremento è parte degli standard dell’organizzazione, tutti i team Scrum devono seguirla come minimo. Se non è uno standard organizzativo, il team Scrum deve creare una Definition of Done appropriata per il prodotto.

I Developer sono tenuti a conformarsi alla Definition of Done. Se più team Scrum lavorano insieme su un prodotto, devono definire reciprocamente e conformarsi alla stessa Definition of Done.

Nota finale

Scrum è gratuito e offerto in questa Guida. Il framework Scrum, come delineato nel presente documento, è immutabile. Sebbene sia possibile implementare solo parti di Scrum, il risultato non è Scrum. Scrum esiste solo nella sua interezza e funziona bene come contenitore per altre tecniche, metodologie e pratiche.

Ringraziamenti

Persone
Delle migliaia di persone che hanno contribuito a Scrum, dovremmo menzionare in particolare coloro che sono stati determinanti all’inizio: Jeff Sutherland ha lavorato con Jeff McKenna e John Scumniotales, e Ken Schwaber ha lavorato con Mike Smith e Chris Martin, e tutti hanno lavorato insieme. Molti altri hanno contribuito negli anni successivi e senza il loro aiuto Scrum non sarebbe perfezionato come lo è oggi.

Storia della Guida Scrum

Ken Schwaber e Jeff Sutherland hanno presentato insieme Scrum per la prima volta alla conferenza OOPSLA nel 1995. Questo documento ha essenzialmente documentato l’apprendimento che Ken e Jeff hanno acquisito nei pochi anni precedenti e ha reso pubblica la prima definizione formale di Scrum.

La Guida Scrum documenta Scrum come sviluppato, evoluto e sostenuto per oltre 30 anni da Jeff Sutherland e Ken Schwaber. Altre fonti forniscono pattern, processi e intuizioni che complementano il framework Scrum. Questi possono aumentare la produttività, il valore, la creatività e la soddisfazione con i risultati.

La storia completa di Scrum è descritta altrove. Per onorare i primi luoghi dove è stato provato e dimostrato, riconosciamo Individual Inc., Newspage, Fidelity Investments e IDX (ora GE Medical).

© 2020 Ken Schwaber e Jeff Sutherland

Questa pubblicazione è offerta in licenza sotto la licenza Attribution Share-Alike di Creative Commons, accessibile su https://creativecommons.org/licenses/by-sa/4.0/legalcode e descritta anche in forma sintetica su https://creativecommons.org/licenses/by-sa/4.0/. Utilizzando questa Guida Scrum, riconosci e accetti di aver letto e di essere vincolato ai termini della licenza Attribution Share-Alike di Creative Commons.