Cosa è Scrum spiegato con i numeri

  🔢 UN FRAMEWORK CON I NUMERI!

Scrivo dopo l’ennesima lettura della Scrum Guide (comincio a chiedermi se leggerla non sia diventata una specie di mania ossessivo-compulsiva! 😊). E’ sorprendente come questo breve, asciutto documento possa rappresentare una fonte inesauribile di nuovi spunti e riflessioni ogni volta che lo si legge. Molti hanno scritto su Scrum prima di me e molti lo faranno dopo: credo che sia un bene se contribuisce ad aumentare la comprensione del framework più diffuso, ma anche più frainteso, del panorama agile.

Per raccontare cosa è Scrum, prendo spunto dai sui numeri perché sono pochi (5 e 3) e ricorrenti, delle ancore ideali per fissare i concetti core di questo framework:

• 3 PILLARS
• 5 VALUES
• 3 ACCOUNTABILITIES
• 5 EVENTS
• 3 ARTIFACTS
• 3 COMMITMENTS.

Mi limiterò in questo post a catturare l’essenza di Scrum, così come definito nella Scrum Guide (se vuoi approfondire puoi leggere il mio post qui). Per scongiurare una errata comprensione o un utilizzo improprio del framework, è importante chiarire cosa fa davvero parte integrante di Scrum e cosa può essere utilizzato con Scrum, anche in modo proficuo, ma non è prescritto da framework.

⚠️ Spero di non deluderti ma non troverai in questo post termini come Story Points, User Stories, Epics, Planning Poker e simili. Riserverò altri post a pratiche e tools compatibili con Scrum, diffusi nella comunità agile, ma non descritti nella Scrum Guide come elementi prescrittivi.

Buona lettura!

LA TEORIA ALLA BASE DI SCRUM

🏛️ 3 PILLARS

Ogni casa ha le sue fondamenta e, la “casa” di Scrum non fa eccezione: si erge sulle fondamenta dell’Empiricismo e del Lean Thinking:

• l’EMPIRICISMO ci fa prendere coscienza che, ahimé, non abbiamo la sfera di cristallo o doti divinatorie. La nostra capacità di prendere decisioni ed agire non può che basarsi sull’esperienza, sull’osservazione di ciò che è già successo: fatti, dati e numeri. Qualsiasi tentativo di prevedere il futuro basato su presupposti diversi è destinato a fallire: meglio lasciarlo a chi fa un altro mestiere (maghi, astrologi, chiromanti e via discorrendo)
• il LEAN THINKING ci aiuta a mantenerci focalizzati su ciò che è davvero essenziale perchè produce valore e a non disperdere tempo ed energie preziose per ciò che inutile.

Dalle fondamenta dell’Empiricismo si ergono le 3 Colonne, i 3 PILASTRI portanti di Scrum:

1. 👐TRANSPARENCY (Trasparenza): per agire basandosi sui fatti come minimo bisogna conoscerli. Tutti i fatti: positivi e negativi. Se nascondiamo o ci vengono nascoste informazioni, giungeremo a conclusioni errate, basate su una visione distorta della realtà e non potremo prendere le decisioni migliori
2. 📏 INSPECT (Verifica): l’avanzamento rispetto agli obiettivi va frequentemente e rigorosamente misurato per accorgerci tempestivamente di potenziali deviazioni o problemi.
3. 🦎 ADAPT (Adattamento): se verifichiamo che il processo è fuori controllo o produce risultati inaccettabili dobbiamo correre ai ripari, correggere il tiro e farlo il prima possibile per evitare che le cose peggiorino ulteriormente.

Nessuno di noi vorrebbe vivere in una casa sbilenca e anche la casa di Scrum ha bisogno di tutti e 3 i Pilastri per rimanere salda:

• Solo la Trasparenza permette la Verifica. Ti metteresti mai alla guida senza un contachilometri e delle spie che ti segnalino con precisione e affidabilità lo stato reale della tua auto?
• La Verifica che non porta all’Adattamento è totalmente sterile. Se le spie della tua auto funzionano alla grande e ti segnalano che i freni non vanno ma tu continui a premere sull'acceleratore è altamente probabile che, presto o tardi, ti schianterai su un muro di cemento armato. Scrum è stato concepito per stimolare il cambiamento.
• Un Adattamento rapido richiede un team “empowered”. In mezzo alla tempesta il timone va preso in mano subito altrimenti rischiamo di affondare. Se per farlo abbiamo bisogno dell’OK di qualcun’altro la tempesta avrà la meglio. Meglio rassegnarci perché andremmo presto a far parte del paesaggio sottomarino in compagnia di pesciolini e stelle marine! ☹️ Questo è il motivo per cui lo Scrum Team deve essere auto-organizzato ed auto-gestito: persone in grado di prendere rapidamente e in modo autonomo le decisioni giuste. Ma sul Team, ti prometto, ci torniamo tra un po'.

💎 5 VALUES

E’ davvero difficile pensare che un qualunque gruppo di persone possa sperare di avere successo in assenza di un mindset, di una visione, di un insieme di valori condivisi che ne dirigano in modo armonico e coerente gli sforzi, le azioni e i comportamenti.

Le persone che abitano la casa di Scrum agiscono guidate da 5 VALORI:

1. 👍 COMMITMENT: il nostro impegno è teso al raggiungimento degli obiettivi condivisi e al costante supporto reciproco. Uno per tutti e tutti per uno! 😊
2. 👁️ FOCUS: poniamo il massimo focus e un’energia costante rivolta a fare ciò che si deve, eliminando tutto ciò che è un’inutile fonte di distrazione e non è funzionale a raggiungere lo scopo
3. 🔓 OPENESS: agiamo con la massima apertura rispetto al lavoro: ai problemi, alle sfide da affrontare, ai successi, ai fallimenti, agli errori, al dare e chiedere aiuto. Nella casa di Scrum lo sporco non si nasconde sotto il tappeto, casomai lo si pulisce insieme! 😊
4. 🤝 RESPECT: ci impegniamo a rispettare gli altri in quanto persone competenti e indipendenti e pretendiamo lo stesso rispetto per noi stessi
5. ❤️ COURAGE: agiamo con coraggio sempre: il coraggio di fare la cosa giusta anche quando è scomoda, impopolare e non è la via più facile.

Agire con la trasparenza necessaria ad implementare un approccio empirico di verifica e adattamento continui è possibile solo se i 5 valori di Scrum diventano i nostri valori: i valori in cui crediamo e che agiamo concretamente. La differenza tra “essere agili” e “fare agile” è tutta qui. Non ci sono scorciatoie.

OK, TUTTO MOLTO BELLO MA COS'E' SCRUM?

📌 Scrum è un framework leggero che aiuta le persone, i team e le organizzazioni a generare valore grazie ad un approccio adattivo per risolvere problemi complessi.

Scrum:

• è semplice, elegante, essenziale e volutamente incompleto: definisce solo ciò che è strettamente necessario ad implementarne la teoria (Empiricismo + Lean Thinking)
• è un framework e non una metodologia, un processo o un insieme di tecniche: al contrario possiamo vederlo come un loro contenitore (integra strutturalmente alcune pratiche esistenti mentre ne rende altre, di fatto, superflue)
• piuttosto che imporre regole dettagliate e prescrittive da seguire, si limita a guidare le relazioni e le interazioni tra le persone lasciando il resto alla loro intelligenza collettiva
• con la sua essenzialità, mette a nudo l’efficacia del management, le fragilità della nostra organizzazione e dei nostri processi per fornirci delle opportunità di miglioramento. In pratica rende evidenti problemi culturali e strutturali che abbiamo ma di cui non siamo (o non siamo totalmente) consapevoli.

P.S.: Hey, ma non vorremo mica dare la colpa alla bilancia, che segna due chili in più, se siamo ingrassati: verooo??? 🤣🤣🤣

Scrum is like your mother-in-law, it points out ALL your faults.

-Ken Schwaber, co-papà di Scrum

📌 Scrum adotta un approccio iterativo e incrementale per permetterci di fare previsioni basate sui fatti e tenere sotto controllo i rischi.

L’approccio iterativo e incrementale ci permette di rilasciare valore, spesso e in modo tempestivo, al nostro cliente che ci ricambia con la cosa più preziosa: il suo feedback.

Accorciare il feedback loop ci permette di misurarci costantemente sulla base di ciò che abbiamo fatto, non di ciò che abbiamo dichiarato di voler fare, abilitando il processo empirico di Inspect & Adapt:

• adattarci rapidamente a fronte di condizioni o esigenze mutate
• tenere sotto controllo i rischi (e i costi) associati a scelte errate o non sostenibili.

♟️ 3 ACCOUNTABILITIES

LO SCRUM TEAM

L’intelligenza collettiva di Scrum risiede nel suo nucleo fondamentale, lo SCRUM TEAM, un piccolo gruppo di persone, con 3 specifiche responsabilità (che nelle versioni precedenti della Scrum Guide corrispondevano ai "Ruoli": leggi qui se ti interessa approfondire).

1. i DEVELOPERS
2. un PRODUCT OWNER
3. uno SCRUM MASTER

Lo Scrum Team:

• non ammette sottogruppi o gerarchie al suo interno: è un gruppo coeso di persone che contribuiscono, con le loro competenze, a creare valore condividendo l’obiettivo del prodotto e dello Sprint
• è Cross-Funzionale: possiede tutte le competenze necessarie per completare il lavoro di uno Sprint. E‘ auto sufficiente: il suo lavoro non dipende da nessun altro
• è Auto-Gestito: un team fatto di professionisti strutturato per decidere in autonomia chi lavorerà su cosa, quando e come lo farà
• è abbastanza piccolo da mantenersi agile e abbastanza grande da riuscire a completare il lavoro di uno Sprint (l’Iterazione agile). Di solito non più di 10 persone in tutto. In un team piccolo la comunicazione e l’auto organizzazione sono più semplici e veloci
• è collettivamente responsabile di tutte le attività necessarie per la creazione di valore e condivide, olisticamente, gli obiettivi del prodotto e dello Sprint.

❓ Ma come si declinano le 3 responsabilità all'interno dello Scrum Team?

I DEVELOPERS

I DEVELOPERS hanno la responsabilità di completare, entro la fine dello Sprint, ogni aspetto necessario a rilasciare un incremento di prodotto (o servizio) che sia utilizzabile e rappresenti valore per il cliente, aderendo alle regole di qualità concordate (Definition Of Done).

📌Un Developer è un professionista che “sviluppa valore”: qualunque sia il suo contributo tecnico o la sua skill specifica il suo nome in Scrum è Developer!

Il concetto di responsabilità condivisa trascende i confini ristretti del proprio ambito tecnico: i Developer si auto organizzano per raggiungere insieme l'obiettivo dello Sprint (Sprint Goal) e si ritengono reciprocamente responsabili per TUTTE le attività necessarie per raggiungerlo (pianificate nello Sprint Backlog).

IL PRODUCT OWNER

Il PRODUCT OWNER (PO per gli amici) è il proprietario del prodotto: l’unica voce (The Voice of the Customer) autorizzata a rappresentare le esigenze, che confluiscono nel Product Backlog, dei diversi stakeholders.

Come owner del prodotto, è responsabile:

• del suo obiettivo (il Product Goal)
• del suo scope (il Product Backlog)
• di massimizzarne il valore, realizzato attraverso il lavoro dello Scrum Team, prioritizzando gli item del Product Backlog per realizzare prima ciò che ha più valore e rimandare il resto agli Sprint successivi.

📌 Perché Scrum abbia successo, l’organizzazione deve riconoscere l’autorità del Product Owner e rispettarne le decisioni: chiunque voglia alterare il contenuto del Product Backlog dovrà vedersela con lui! 😊

LO SCRUM MASTER

 ⚠️ Che non ti passi per la mente di confondere il suo ruolo con quello del Project Manager: quando leggo di annunci in cui si cerca uno Scrum Master che coordini il team e gestisca il piano mi viene l’orticaria! 😖

Lo SCRUM MASTER:

• è lo Scrum “Sensei”, responsabile di promuovere Scrum aiutando chiunque (sia il Team che l’organizzazione) a comprenderne la teoria e padroneggiarne le pratiche agendo come maestro, mentor e coach
• non ha alcuna autorità sulle persone ma ne ha sul processo. E' un manager? Si, ma di Scrum e delle sue regole: è il garante della corretta comprensione e applicazione di Scrum per il Team e della sua promozione nell’intera organizzazione. E’ un leader “vero” (true leader) che mette se stesso al servizio degli altri: lavora per mettere gli altri in condizione di lavorare al meglio
• come impediment remover, rimuove qualsiasi “disturbo” (Impediment) che mini l’efficacia dello Scrum Team, rallentandone o bloccandone l’avanzamento (problemi, blocchi, ingerenze, etc.).

📌 E’ una responsabilità dello Scrum Master anche l’efficacia dello Scrum Team: lo Scrum Master non compie scelte che competono al team ma ne allena il muscolo dell’autonomia e del pensiero divergente perché il team sia in grado di decidere da se.

📅 5 EVENTS

Con il termine EVENTO, Scrum indica un meeting con un obiettivo chiaro e trasparente e un timebox (una durata) definito.

Scrum prescrive 4 Eventi:

1. Sprint Planning
2. Daily Scrum
3. Sprint Review
4. Sprint Retrospective.

Il 5^ Evento, lo Sprint, è una iterazione con un timebox (durata) fisso, che fa da contenitore agli altri quattro Eventi.

📌 Gli Eventi rappresentano occasioni formali di verifica e adattamento: scandiscono il ritmo con cui effettuare l’Inspect & Adapt mentre gli Artefatti di Scrum contengono le informazioni da verificare e adattare.

Rinunciare ad uno di questi Eventi equivale a perdere un’opportunità di verifica e adattamento. Sarebbe come comprarsi una Ferrari e lasciarla parcheggiata in garage: sciocco no? 😳

SPRINT

Lo SPRINT, è il cuore pulsante di Scrum: una iterazione (paragonabile a un mini ciclo di sviluppo o un mini progetto) timeboxed, della durata fissa di massimo un mese durante il quale il team trasforma le idee in uno o più incrementi di valore.

📌 Lo Sprint è il contenitore degli altri 4 Eventi. Tutto ciò che accade in Scrum accade durante lo Sprint e un nuovo Sprint inizia immediatamente dopo la conclusione del precedente.

Durante lo Sprint:

• i Developers lavorano per raggiungere un obiettivo specifico per lo Sprint (lo Sprint Goal) concordato con il Product Owner
• I Developers verificano e adattano, almeno giornalmente, il loro piano di sviluppo.
• lo scope dello Sprint può essere chiarito e rinegoziato con il Product Owner in modo “emergente” a mano a mano che la comprensione aumenta (l'obiettivo è raggiungere lo Sprint Goal NON tentare a tutti i costi di completare uno scope anche se ci accorgiamo che non ha più alcun senso).

⚠️ Ma, attenzione:

• non è ammessa alcuna modifica che possa invalidare lo Sprint Goal
• la qualità (Definition Of Done) non può essere compromessa e non è negoziabile

Il meccanismo degli Sprint ci aiuta ad aumentare il controllo e la predicibilità, garantendo che l’avanzamento rispetto al Product Goal venga valutato (Inspect & Adapt) almeno una volta al mese.

Un orizzonte temporale troppo lungo potrebbe rendere obsoleto lo Sprint Goal mentre Sprint più brevi ci permettono di accorciare il feedback loop, aumentando le opportunità di inspect & adapt, e circoscrivono a un periodo più breve rischi e costi.

SPRINT PLANNING

Lo SPRINT PLANNING è l’Evento che apre ogni Sprint.

E’ timeboxed: dura massimo 8 ore per uno Sprint di un mese (più breve per Sprint inferiori alle quattro settimane).

📌 Lo Sprint Planning ha lo scopo di pianificare cosa fare nello Sprint che sta iniziando e il piano che ne deriva è il risultato del lavoro collaborativo di tutto lo Scrum Team.

Tutto il lavoro fatto durante lo Sprint Planning converge in uno degli artefatti di Scrum, lo Sprint Backlog: i suoi 3 elementi costituenti ci aiutano a rispondere ad altrettante domande:

1. Lo SPRINT GOAL che sintetizza il motivo per cui lo Sprint corrente contribuirà ad aggiungere valore. ❓ Risponde alla domanda: WHY? Perché questo Sprint genera valore?
2. Gli ITEM del Product Backlog da completare nello lo Sprint per raggiungere lo Sprint Goal. ❓ Rispondono alla domanda: WHAT? Cosa possiamo fare in questo Sprint?
3. Il PIANO di tutte le attività necessarie per trasformare gli item selezionati per lo Sprint in un Increment di valore che soddisfi la Definition Of Done. ❓ Risponde alla domanda: HOW? Come svolgeremo il lavoro nello Sprint?

DAILY SCRUM

Il DAILY SCRUM è un breve meeting giornaliero della durata massima di 15 Minuti in cui i Developer:

• valutano l’avanzamento rispetto allo Sprint Goal
• se necessario, ripianificano il lavoro da svolgere (il piano presente nello Sprint Backlog)
• evidenziano in modo trasparente i problemi che bloccano o rallentano il loro lavoro.

📌 Il Daily Scrum è un meeting dei e per i Developer. Sono loro a pianificare il lavoro da effettuare e a verificarne l'avanzamento. NESSUNO, senza eccezioni, può violarne l'autonomia.

SPRINT REVIEW

La SPRINT REVIEW è il penultimo Evento dello Sprint.

E’ timeboxed: dura massimo 4 ore per uno Sprint di un mese (più breve per Sprint inferiori alle quattro settimane).

📌 L’obiettivo della Sprint Review è quello di stimolare i feedback degli stakeholders chiave per valutare (Inspect) l’Incremento (o gli Incrementi) appena completato e decidere come far evolvere (Adapt) il prodotto.

SPRINT RETROSPECTIVE

La SPRINT RETROSPECTIVE è l’Evento che chiude ogni Sprint.

E’ timeboxed: dura massimo 3 ore per uno Sprint di un mese (più breve per Sprint inferiori alle quattro settimane).

Se l’obiettivo della Sprint Review è l’Inspect & Adapt del Prodotto, l’obiettivo della Sprint Retrospective è l’Inspect & Adapt di noi stessi: valutiamo il nostro modo di lavorare, le nostre relazioni, gli strumenti che utilizziamo e i criteri rispetto ai quali valutiamo la qualità dei nostri prodotti con l’obiettivo di identificare possibili spunti di miglioramento da implementare al più presto.

📌 La Sprint Retrospective rende istituzionale il Continuous Learning & Improvement: l'apprendimento e il miglioramento continui diventano parte del processo.

🧩 3 ARTIFACTS + 3 COMMITTMENTS

Con il termine ARTEFATTO, intendiamo un prodotto del processo Scrum: qualcosa che Scrum crea, aggiorna e utilizza per il suo funzionamento.

Ogni Artefatto:

• garantisce la trasparenza delle informazioni contenute: chiunque lo analizzi (Inspect) avrà, in questo modo, una base comune per pianificarne l’adattamento (Adapt)
• ha associato un suo Commitment: un “impegno”, non ambiguo e trasparente, che ci indica la direzione e esplicita le informazioni chiave rispetto alle quali possiamo misurare il nostro avanzamento.

3 sono gli Artefatti di Scrum con i loro rispettivi Commitments:

1. il Product Backlog con il suo Commitment, il Product Goal
2. lo Sprint Backlog con il suo Commitment, lo Sprint Goal
3. l'Increment con il suo Commitment, la Definition Of Done (DOD)

PRODUCT BACKLOG

📌 Il PRODUCT BACKLOG rappresenta lo scope del prodotto: la sola e unica fonte di TUTTO il lavoro da effettuare (Work yet to be done), un elenco emergente e ordinato di tutto ciò che è necessario fare per far evolvere il prodotto.

Qualunque attività connessa allo sviluppo o all’evoluzione del prodotto è contenuta nel Product Backlog: non solo requisiti funzionali ma anche requisiti tecnici, prestazionali o relativi alla sicurezza, change, attività di improvement o di mitigazione dei rischi, sperimentazioni (Spike), bug fixing, etc.

Il contenuto del Product Backlog è:

• ordinato perché gli item che lo compongono (o PBIs, Product Backlog Items) sono ordinati in modo tale da consentire al team di decidere cosa va fatto prima, perché è una priorità per il business, e cosa può essere rimandato agli Sprint successivi
• emergente perché i dettagli di ogni PBI emergono a mano a mano che il lavoro procede, la conoscenza aumenta e le idee si fanno più chiare.

Compete al Product Owner la responsabilità di mantenerlo sempre aggiornato, ordinato, consistente e trasparente attraverso una costante attività di Refinement (l'atto di scomporre i PBIs in elementi più atomici e precisi, di definirli ulteriormente e di aggiungere dettagli via via che emergono).

Product Backlog Commitment: Product Goal

Il Product Backlog contiene il suo Commitment, il PRODUCT GOAL.

📌 Il Product Goal descrive uno stato futuro del prodotto e, per lo Scrum Team, rappresenta un faro guida, una bussola, un obiettivo a lungo termine per pianificare l’evoluzione del prodotto stesso.

Lo Scrum Team si impegna a raggiungere il Product Goal entro la fine del progetto.

SPRINT BACKLOG

Lo SPRINT BACKLOG è un piano tattico creato da e per i Developer, costituito da:

1. Lo SPRINT GOAL che sintetizza il motivo per cui lo Sprint corrente contribuirà ad aggiungere valore. ❓ Risponde alla domanda: WHY? Perché questo Sprint genera valore?
2. Gli ITEM del Product Backlog da completare nello lo Sprint per raggiungere lo Sprint Goal. ❓ Rispondono alla domanda: WHAT? Cosa possiamo fare in questo Sprint?
3. Il PIANO di tutte le attività necessarie per trasformare gli item selezionati per lo Sprint in un Increment di valore che soddisfi la Definition Of Done. ❓Risponde alla domanda: HOW? Come svolgeremo il lavoro nello Sprint?

📌 I Developer misurano (Inspect) costantemente il loro avanzamento rispetto al raggiungimento dello Sprint Goal e adattano (Adapt) di conseguenza il piano contenuto nello Sprint Backlog.

Sprint Backlog Commitment: Sprint Goal

Lo SPRINT GOAL fa parte dello Sprint Backlog e deve e essere finalizzato entro la fine dello Sprint Planning.

📌 E’ l'unico obiettivo dello Sprint: aiuta lo Scrum Team a mantenere coerenza e focus fornendo quella prospettiva olistica che lo incoraggia a lavorare insieme piuttosto che su attività distinte.

Rappresenta un impegno da parte dei Developer ma lascia un margine di flessibilità sufficiente per adattare, in modo emergente, la modalità con cui viene raggiunto (inclusa la soluzione tecnica).

INCREMENT

📌 L’INCREMENTO può essere considerato come uno step di avvicinamento progressivo verso il Product Goal.

E’ la componente del prodotto (o del servizio), realizzata durante lo Sprint, che costituisce per il cliente valore riconoscibile, potenzialmente rilasciabile e utilizzabile.

I Developer si impegnano a completare, entro la fine dello Sprint, almeno un Incremento di valore che soddisfi lo Sprint Goal e i criteri di qualità concordati nella Definition of Done.

Increment Commitment: Definition of Done

La DEFINITION OF DONE (DOD) è una descrizione formale dello stato dell’Incremento quando questo soddisfa le metriche di qualità concordate per il prodotto.

Creare in modo collaborativo la Definition of Done è un compito dello Scrum Team mentre attenersi a questa è una responsabilità dei Developer: è il loro impegno (Commitment) riguardo al lavoro necessario per completare un Incremento.

📌La Definition of Done fornisce il grado di trasparenza necessario a ridurre l’ambiguità creando una comprensione condivisa di quale lavoro sia necessario perché un Incremento possa essere ritenuto completo (“Done”).

QUANDO 10 PERSONE NON SONO ABBASTANZA...

Non voglio affrontare qui un argomento che, per la sua complessità, merita uno spazio ad hoc (mi riprometto di trattarlo in futuri post).

Tuttavia, per amore di completezza, dato che l’obiettivo di questo articolo è di “spogliare” Scrum di tutto ciò che non ne costituisce parte integrante, vale la pena quanto meno accennare agli spunti (pochi per la verità) che la Scrum Guide ci offre al riguardo (leggi qui per approfondire).

Delle dimensioni dello Scrum Team abbiamo parlato sottolineando come un team piccolo sia generalmente più produttivo e più agile.

❓ Ma che succede se un prodotto è talmente grande o complesso da richiedere il contributo di più di 10 persone?

Per non perdere agilità, Scrum non ci consente di aumentare il numero dei membri dello Scrum Team ma ci impone invece di “scalare” il framework consentendo a più team coesi di lavorare in parallelo sullo stesso prodotto.

📌 Scalare Scrum (e, più in generale, gli approcci agili) può senz’altro rappresentare una sfida, soprattutto per lo sforzo richiesto per la sincronizzazione di più team ma, fortunatamente, Scrum è stato progettato per scalare perché la sua struttura è, per costruzione, frattale: l’efficacia di Scrum a livello di singolo team non degrada se scalato su più team o a livello enterprise.

❓ Ma cosa ci suggerisce in pratica la Scrum Guide?

Non molto per la verità, solo l’indicazione che team multipli, che lavorano sullo stesso prodotto devono:

• condividere lo stesso Product Backlog, lo stesso Product Goal e lo stesso Product Owner
• definire e mutuamente aderire alla stessa Definition Of Done.

Ricordiamo che la Scrum Guide è “volutamente incompleta” e queste indicazioni, anche se piuttosto scarne, rappresentano una base di partenza necessaria per comprendere come il problema venga declinato e risolto dai diversi framework di scaling disponibili (Scrum Of Scrum, Nexus, LeSS, Scrum@Scale, SAFe, etc.) e per essere in grado di valutare quali di questi rispettano o violano la struttura portante di Scrum.

PER CONCLUDERE

📌 Affrontare la transizione a Scrum è un processo complesso, pervasivo e trasformativo, un vero e proprio processo di Change Management organizzativo.

Scrum è semplice (da comprendere) ma non è facile (da applicare):

• richiede un cambio di mindset, una trasformazione culturale, la disponibilità a mettere in discussione noi stessi e lo status quo. Uscire fuori dalla confort zone per vedere cosa c’è dall’altra parte può essere un processo lungo, doloroso e difficile
• vuole estremo rigore e una grande disciplina perché, come dicevamo, è “volutamente incompleto” e lo spazio che lascia libero richiede un grande senso di responsabilità e l’umiltà necessaria di accettare il fallimento per tentare di nuovo.

Ma, a patto di affrontare il cammino con rispetto, fiducia e umiltà, Scrum può davvero aiutarci a fare cose meravigliose.

📌 L’adozione di Scrum (o di qualsiasi altro framework) non deve essere frutto di una posizione ideologica o di una scelta guidata dalla moda del momento ma piuttosto da un sano “opportunismo” figlio della consapevolezza che non esistono approcci perfetti ma solo approcci utili in specifici contesti e per risolvere specifici problemi.

Se Scrum è stato concepito con le sue “regole del gioco” un motivo deve pur esserci: se decidiamo di adottarlo, facciamolo con il dovuto rispetto, con l’umiltà di chi si avvicina a qualcosa di nuovo, dandogli fiducia per il tempo necessario a capire se è adatto a noi.

Come ci ricorda la Scrum Guide, Scrum è immutabile: esiste e funziona bene solo nella sua interezza.  Siamo liberi di implementarne solo delle parti ma il risultato non può essere considerato Scrum e farlo ci priverà dell’opportunità di valutarne e apprezzarne il valore.

LE MIE FONTI

• Scrum.Org
• The Scrum Guide 2020
• The Scrum Guide 2020 Reordered (by Stefan Wolpers)

LASCIAMI UN COMMENTO

• Che ne pensi di Scrum?
• Hai già letto la Scrum Guide?
• Se hai già sperimentato Scrum come ti sei trovata/o? Cosa hai apprezzato? Quali difficoltà hai incontrato?
• Se ne hai solo sentito parlare quanto è distante l'idea che ne avevi rispetto a quello che hai letto qui?
• Pensi che Scrum potrebbe aiutarti oppure c'è qualcosa che non ti convince?

Insomma, qualsiasi sia la tua idea, fai qualcosa per me: non dimenticare di inviarmi i tuoi commenti, le tue domande o condividere con me i tuoi dubbi!

E, se hai voglia di approfondire, dai un'occhiata ai nostri corsi online o in aula/virtual-room.

Ti aspettiamo!

Stay agile! 🏄

La versione originale di questo post è stata pubblicato sul blog di AgilePlaza.