Che cos'è Scrum e come iniziare

Le persone spesso pensano che Scrum e Agile siano la stessa cosa perché Scrum è incentrato sul miglioramento continuo, che è un principio fondamentale di Agile. Tuttavia, Scrum è un framework per portare a termine il lavoro, mentre Agile è una filosofia. La filosofia Agile è incentrata sul miglioramento incrementale continuo attraverso rilasci piccoli e frequenti. Non puoi davvero "diventare Agile", poiché ci vuole la dedizione di tutto il team per cambiare il modo in cui pensa a come offrire valore ai clienti. Puoi, però, usare un framework come Scrum per iniziare a pensare in modo Agile ed esercitarti a integrare i principi Agile nei flussi di comunicazione e di lavoro quotidiani.

La differenza tra Agile e Scrum e la definizione di Scrum sono illustrate nella Guida Scrum e nel Manifesto Agile. Il Manifesto Agile evidenzia quattro valori:

• Gli individui e le interazioni più che i processi e gli strumenti

• Il software funzionante più che la documentazione esaustiva

• La collaborazione col cliente più che la negoziazione del contratto

• Rispondere al cambiamento più che seguire un piano

La definizione di Scrum si basa sull'empirismo e sul pensiero Lean. L'empirismo afferma che la conoscenza deriva dall'esperienza e che le decisioni vengono prese in base a ciò che si osserva. Il pensiero Lean riduce gli sprechi e si concentra sull'essenziale. Scrum è un framework euristico: si basa sull'apprendimento continuo e sull'adattamento a fattori variabili. Tiene conto del fatto che il team non dispone di tutte le conoscenze all'inizio di un progetto e che si evolverà man mano che acquisirà esperienza. Scrum è strutturato per aiutare i team ad adattarsi in modo naturale alle mutevoli condizioni ed esigenze degli utenti, con una ridefinizione delle priorità integrata nel processo e cicli di rilascio brevi che consentono al team di imparare e migliorare costantemente.

Sebbene sia strutturato, il framework Scrum non è del tutto rigido. La sua esecuzione può essere adattata alle esigenze di qualsiasi organizzazione. Ci sono molte teorie sul modo esatto in cui i team Scrum devono operare per avere successo. Tuttavia, dopo oltre dieci anni in cui abbiamo aiutato i team Agile a svolgere il lavoro in Atlassian, abbiamo imparato che la comunicazione chiara, la trasparenza e la dedizione al miglioramento continuo devono sempre rimanere al centro di qualsiasi framework con cui scegli di lavorare. E il resto dipende da te.

Il framework Scrum delinea una serie di valori, principi e pratiche che i team Scrum seguono per fornire un prodotto o un servizio. Descrive i membri del team e le loro responsabilità, gli "artefatti" che definiscono e contribuiscono a creare il prodotto, nonché le cerimonie Scrum che guidano il team nel lavoro.

Un team Scrum è una squadra snella e agile che si occupa di fornire incrementi di prodotto mirati. Le dimensioni dei team Scrum sono in genere ridotte (circa 10 persone), ma sufficienti per completare una notevole quantità di lavoro in un solo sprint. Un team Scrum ha bisogno di tre ruoli specifici: owner di prodotto, Scrum Master e team di sviluppo. Inoltre, poiché i team Scrum sono interfunzionali, il team di sviluppo include non solo sviluppatori ma anche tester, progettisti, esperti in interfaccia utente e tecnici operativi.

L'owner di prodotto Scrum

Gli owner di prodotto sono i promotori dei loro prodotti. Sono concentrati sulla comprensione delle esigenze aziendali, dei clienti e del mercato, quindi definiscono le priorità del lavoro che deve essere svolto dal team di progettazione. Gli owner di prodotto efficaci:

• Creano e gestiscono il backlog di prodotto.

• Collaborano a stretto contatto con l'azienda e il team per garantire che tutti comprendano gli elementi del lavoro nel backlog di prodotto.

• Forniscono al team indicazioni chiare su quali funzionalità fornire in futuro.

• Decidono quando rilasciare il prodotto, con una predisposizione verso una distribuzione più frequente.

L'owner di prodotto non è sempre il product manager. Gli owner di prodotto si concentrano sul garantire che il team di sviluppo offra il massimo valore all'azienda. Inoltre, è importante che l'owner di prodotto sia una persona fisica. Nessun team di sviluppo desidera una guida mista da parte di più owner di prodotto.

Lo Scrum Master

Gli Scrum Master sono i promotori delle attività Scrum nell'ambito dei propri team. Affiancano i team, gli owner di prodotto e l'azienda nel processo Scrum e si adoperano per perfezionarne le prassi.

Uno Scrum Master efficace ha una comprensione profonda del lavoro svolto dal team e può aiutarlo a ottimizzare la trasparenza e il flusso di consegna. In qualità di capo facilitatore, pianifica le risorse necessarie (sia umane che logistiche) per la pianificazione dello sprint, la riunione stand-up, la revisione dello sprint e la retrospettiva dello sprint.

Il team di sviluppo Scrum

I team Scrum sono sempre operativi. Sono i promotori delle pratiche di sviluppo sostenibile. I team Scrum più efficaci sono affiatati e ubicati nello stesso luogo e in genere includono da cinque a sette membri. Un metodo utile per stabilire le dimensioni ottimali del team è quello della famosa "regola delle due pizze" coniata da Jeff Bezos, CEO di Amazon, secondo cui per sfamare un qualsiasi team non dovrebbero essere necessarie più di due pizze.

I membri del team hanno competenze diverse, ma condividono le proprie conoscenze in modo che nessuno possa essere d'ostacolo nella consegna del lavoro. I team Scrum solidi si organizzano in modo autonomo e affrontano i progetti con un evidente spirito collaborativo. Tutti i membri del team si aiutano a vicenda per garantire il completamento efficace dello sprint.

Il team Scrum guida il piano per ogni sprint. Prevede la quantità di lavoro che ritiene di poter completare nel corso dell'iterazione utilizzando come linea guida la propria velocity storica. Mantenere una durata fissa dell'iterazione offre al team di sviluppo un feedback importante sul processo di stima e consegna, il che a sua volta rende le previsioni sempre più accurate nel corso del tempo.

Gli artefatti Scrum sono informazioni importanti utilizzate dal team Scrum che aiutano a definire il prodotto e il lavoro da svolgere per crearlo. I tre artefatti Scrum sono il backlog di prodotto, il backlog dello sprint e l'incremento rispetto alla definizione di "completato", e rappresentano i concetti cardine sui quali un team Scrum dovrebbe riflettere durante gli sprint e nel tempo.

• Il backlog di prodotto è l'elenco principale dei lavori che devono essere eseguiti e viene redatto dall'owner di prodotto o dal responsabile di prodotto. Si tratta di un elenco dinamico di funzioni, requisiti, miglioramenti e correzioni che funge da input per il backlog dello sprint. È, essenzialmente, l'elenco delle cose "da fare" del team. Il backlog di prodotto viene costantemente rivisto, modificato in termini di priorità e gestito dall'owner di prodotto perché, man mano che si acquisiscono maggiori conoscenze o che il mercato cambia, gli elementi potrebbero non essere più pertinenti o i problemi potrebbero essere risolti in altri modi.

• Il backlog dello sprint è l'elenco di elementi, storie utente o correzioni di bug selezionati dal team di sviluppo per l'implementazione nel ciclo di sprint corrente. Prima di ogni sprint, durante la riunione di pianificazione dello sprint (di cui parleremo più avanti nell'articolo) il team sceglie dal backlog di prodotto gli elementi su cui lavorerà per lo sprint. Un backlog dello sprint può essere flessibile ed evolversi durante uno sprint. Tuttavia, l'obiettivo fondamentale dello sprint, ossia quello che il team desidera ottenere dallo sprint corrente, non può cambiare.

• L'incremento (o obiettivo dello sprint) è il prodotto finale utilizzabile di uno sprint. In Atlassian, di solito forniamo una dimostrazione dell'incremento durante la demo di fine sprint, in cui il team illustra quali elementi dello sprint sono stati completati. È possibile che il termine "incremento" ti risulti nuovo in questo contesto, dove è spesso utilizzato in riferimento alla definizione di "completato", a milestone raggiunte, a obiettivi dello sprint o a una versione completa o un epic rilasciato. Tutto dipende dal modo in cui i membri del tuo team definiscono il concetto di "completato" e da come tu definisci gli obiettivi dello sprint. Ad esempio, alcuni team scelgono di effettuare dei rilasci parziali per i propri clienti alla fine di ogni sprint. Quindi la loro definizione di "completato" sarebbe in realtà quella di "rilasciato". Questa definizione, tuttavia, potrebbe non essere realistica per altri tipi di team. Se, ad esempio, lavori su un prodotto basato su server che può essere rilasciato ai clienti solo ogni trimestre, potresti comunque scegliere di lavorare in sprint di due settimane, ma la tua definizione di "completato" potrebbe essere il completamento di parte di una versione più ampia che prevedi di rilasciare in seguito. Ovviamente, maggiore è il tempo necessario per rilasciare il software, più alto è il rischio che il software manchi il bersaglio.

Come puoi immaginare, ci sono molte varianti, anche all'interno degli artefatti, che il tuo team può scegliere di definire. Ecco perché è importante rimanere aperti riguardo al modo in cui si gestiscono anche i propri artefatti. Magari la tua definizione di "completato" espone i membri del tuo team a un inutile stress; in tal caso, è necessario fare un passo indietro e scegliere una nuova definizione.

Il framework Scrum include le prassi, le cerimonie e le riunioni che i team Scrum eseguono regolarmente. Le cerimonie Agile rappresentano gli eventi in cui le divergenze di opinioni dei team si manifestano in misura maggiore. Ad esempio, alcuni team ritengono che tante cerimonie siano ingombranti e ripetitive, mentre altri le usano come uno strumento di controllo necessario. Il nostro consiglio è di iniziare a utilizzare tutte le cerimonie per due sprint e valutare i risultati. Puoi quindi eseguire una retrospettiva rapida per capire quali correzioni apportare.

Di seguito è riportato un elenco di tutte le cerimonie chiave a cui un team Scrum potrebbe partecipare:

1. Organizzazione del backlog: a volte noto come backlog grooming, questo evento rientra nell'ambito delle responsabilità dell'owner di prodotto, il cui compito principale è favorire l'attuazione della vision del prodotto e avere un quadro costante del mercato e del cliente. Pertanto, l'owner di prodotto gestisce questo elenco utilizzando il feedback degli utenti e del team di sviluppo per definire le priorità e mantenere l'elenco pulito e pronto per essere utilizzato in qualsiasi momento. Puoi leggere ulteriori informazioni su come gestire un backlog efficace qui.

2. Pianificazione dello sprint: il lavoro da eseguire (ambito) durante lo sprint corrente viene pianificato dall'intero team di sviluppo nel corso di questo incontro, che è guidato dallo Scrum Master e nell'ambito del quale il team decide l'obiettivo dello sprint. Le storie utente specifiche vengono quindi aggiunte allo sprint dal backlog di prodotto. Queste storie sono sempre in linea con l'obiettivo e sono anche concordate dal team Scrum in modo che siano implementabili durante lo sprint.

   Al termine della riunione di pianificazione, ogni membro del team Scrum deve sapere con chiarezza cosa può essere rilasciato nello sprint e come può essere rilasciato l'incremento.

3. Sprint: con "sprint" si intende il periodo di tempo effettivo in cui il team Scrum collabora per completare un incremento. In genere lo sprint ha una durata di due settimane, anche se alcuni team ritengono che una settimana sia sufficiente per definire l'ambito o che un mese sia un periodo adeguato per consegnare un incremento importante. Dave West di Scrum.org ritiene che più il lavoro è complesso e il numero di incognite è elevato, minore dovrebbe essere la durata dello sprint. Durante questo periodo, l'ambito può essere nuovamente negoziato tra l'owner di prodotto e il team di sviluppo, se necessario. È questo l'aspetto cruciale della natura empirica di Scrum.

   Tutti gli eventi, dalla pianificazione alla retrospettiva, avvengono durante lo sprint. Una volta stabilito un certo intervallo di tempo per uno sprint, questo deve rimanere coerente per tutto il periodo di sviluppo. Ciò consente al team di imparare dalle esperienze passate e di applicare gli insegnamenti acquisiti agli sprint futuri.

4. Scrum quotidiano o riunione stand-up: si tratta di una riunione quotidiana estremamente breve che, per praticità, avviene sempre alla stessa ora (di solito al mattino) e nello stesso luogo. Molti team cercano di completarla entro 5 minuti, ma questa tempistica è solo indicativa. Questa riunione è anche definita "riunione stand-up quotidiana" per sottolineare il fatto che deve essere rapida. L'obiettivo dello Scrum quotidiano è di assicurarsi che tutti i membri del team siano allineati sull'obiettivo dello sprint e di definire un piano per le 24 ore successive.

   La riunione stand-up è il momento in cui vengono espresse tutte le preoccupazioni riguardo al raggiungimento dell'obiettivo dello sprint o a eventuali bloccanti.

   Un modo diffuso per condurre una riunione stand-up è di chiedere a ogni membro del team di rispondere a tre domande riguardanti il raggiungimento dell'obiettivo dello sprint:
   
   • Cosa ho fatto ieri?
   • Cosa ho intenzione di fare oggi?
   • Sto riscontrando eventuali ostacoli?
   
   Tuttavia, spesso la riunione si trasforma in una lettura rapida del calendario del giorno precedente e di quello successivo da parte dei membri del team. La riunione stand-up si basa su una teoria: limitare il più possibile le chiacchiere e far sì che il team possa concentrarsi sul lavoro per il resto della giornata.  Pertanto, se diventa una lettura giornaliera del calendario, non esitare a cambiarla in nuovi modi creativi.

5. Revisione dello sprint: alla fine dello sprint, il team si riunisce per una sessione informale allo scopo di visualizzare una demo o analizzare l'incremento. Il team di sviluppo mostra gli elementi di backlog completati alle parti interessate e ai membri del team per ottenere un feedback. L'owner di prodotto può decidere se rilasciare o meno l'incremento, sebbene nella maggior parte dei casi venga rilasciato.

   Questa riunione di revisione è anche il momento in cui l'owner di prodotto rielabora il backlog di prodotto in base allo sprint corrente, che può alimentare la prossima sessione di pianificazione dello sprint. Per uno sprint di un mese, valuta la possibilità di prolungare la revisione dello sprint a un massimo di quattro ore.

6. Retrospettiva dello sprint: la retrospettiva dello sprint è il momento in cui team si riunisce per documentare e discutere cosa ha funzionato e cosa non ha funzionato in uno sprint, in un progetto, tra le persone o nell'ambito di relazioni, strumenti o anche per determinate cerimonie. L'idea è quella di creare una situazione in cui il team possa concentrarsi sugli aspetti positivi e sulle aree di miglioramento per il futuro, mettendo in secondo piano ciò che non è andato per il verso giusto.

Nel 2016, abbiamo aggiunto cinque valori Scrum alla Guida Scrum. Questi valori forniscono indicazioni per il lavoro, le azioni e il comportamento del team Scrum e sono fondamentali per il successo del team.

Impegno

Poiché i team Scrum sono di ridotte dimensioni, ogni membro del team svolge un ruolo significativo per il conseguimento degli obiettivi. Pertanto, ciascun membro del team deve farsi carico soltanto dei task che sa di poter completare e comunicare con frequenza le informazioni sull'avanzamento del lavoro, ad esempio durante le riunioni stand-up.

Coraggio

Un team Scrum deve avere il coraggio di mettere in discussione lo status quo o tutto ciò che ostacola il successo. I membri del team Scrum non devono temere di sperimentare nuove soluzioni, e devono essere messi nelle condizioni di farlo. È necessario che si sentano liberi di essere trasparenti in merito a ostacoli, avanzamento dei progetti, ritardi e così via.

Focus

Il fulcro del flusso di lavoro è lo sprint, un periodo di tempo mirato e specifico in cui il team Scrum deve completare una determinata quantità di lavoro. Lo sprint crea una certa struttura e agevola la concentrazione necessaria per completare la mole di lavoro pianificata.

Apertura

La riunione stand-up quotidiana promuove un ambiente aperto che consente ai team di discutere liberamente del lavoro in corso e degli ostacoli. I team Scrum di Atlassian rispondono spesso a queste domande:

• Su cosa ho lavorato ieri?

• Su cosa lavorerò oggi?

• Quali problemi stanno bloccando il mio lavoro?

Questo approccio aiuta a mettere in evidenza l'avanzamento, identificare i bloccanti e creare un momento di condivisione che rafforza il team.

Rispetto

La forza di un team Agile risiede nella collaborazione e nel riconoscere che ogni membro del team contribuisce allo sprint. Tutti i partecipanti si congratulano per i risultati altrui e rispettano i colleghi, l'owner di prodotto, gli stakeholder e lo Scrum Master.

Scrum è un framework Agile così popolare che Scrum e Agile vengono spesso fraintesi come la stessa cosa. Ma ci sono altri framework, come Kanban, che è una delle alternative più diffuse. Alcune aziende scelgono persino di seguire un modello ibrido di Scrum e Kanban, che ha acquisito il nome di "Scrumban" o "Kanplan", ovvero Kanban con un backlog.  

Sia Scrum che Kanban utilizzano metodi visivi come la board Scrum o la board Kanban per tenere traccia dell'avanzamento del lavoro. Entrambi puntano sull'efficienza e sulla suddivisione di attività complesse in parti più piccole di lavoro gestibili, ma i loro approcci verso tale obiettivo sono diversi.

Scrum si concentra su iterazioni più piccole a lunghezza fissa. Una volta finalizzato il periodo di tempo per uno sprint, vengono quindi determinate le story o le voci del backlog di prodotto che possono essere implementate durante questo ciclo di sprint. In Kanban, tuttavia, il numero di attività o il lavoro in corso (limite WIP) da implementare nel ciclo corrente è inizialmente fisso. Il tempo impiegato per implementare queste funzionalità viene quindi calcolato a ritroso.

Kanban non è strutturato come Scrum. A parte il limite WIP, è abbastanza aperto all'interpretazione. Scrum, tuttavia, ha diversi concetti categorici applicati come parte della sua implementazione, come revisione dello sprint, retrospettiva, Scrum giornaliero ecc. Punta anche sulla funzionalità incrociata, che è la capacità di un team Scrum di non dipendere da membri esterni per raggiungere i propri obiettivi. Mettere insieme un team interfunzionale non è semplice. In questo senso, Kanban è più facile da adattare mentre Scrum può essere considerato un cambiamento fondamentale nel processo di pensiero e nel funzionamento di un team di sviluppo.

In sé il framework Scrum è semplice. Le regole, gli artefatti, gli eventi e i ruoli sono facili da capire. Il suo approccio semi-prescrittivo contribuisce effettivamente a eliminare le ambiguità nel processo di sviluppo, offrendo al contempo alle aziende un margine sufficiente per le personalizzazioni.

La possibilità di organizzare task complessi in storie utente gestibili lo rende ideale per i progetti difficili. Inoltre, la demarcazione chiara dei ruoli e degli eventi pianificati garantisce trasparenza e responsabilità collettiva nel corso dell'intero ciclo di sviluppo. Grazie alla rapidità dei rilasci, che permette di vedere in poco tempo i progressi compiuti, il team è sempre motivato e gli utenti sono soddisfatti.

Tuttavia, la comprensione del framework Scrum in tutti i suoi aspetti potrebbe richiedere del tempo, soprattutto se il team di sviluppo è abituato a un tipico modello a cascata. I concetti di iterazioni più piccole, riunioni Scrum quotidiane, revisioni di sprint e identificazione di uno Scrum Master potrebbero comportare un cambiamento culturale impegnativo per un nuovo team.

Tuttavia, i vantaggi a lungo termine hanno un peso notevolmente maggiore rispetto alla curva iniziale di apprendimento. I risultati offerti da Scrum nello sviluppo di prodotti hardware e software complessi in diversi settori e verticali lo rendono un framework di grande interesse per la tua organizzazione.

Per scoprire come utilizzare Scrum con Jira, dai un'occhiata a questo tutorial.