Scrum Team Transformation - Scrum e la torta di mele

Intervista: Scrum e torta di mele [E25]

ℹ️ Intervista – Scrum e torta di mele 📅 Data: 13/06/2023 ⚙️ Durata: 35 minuti

🎙️ Introduzione

“Ciao, io sono Fabio Panzavolta, Professional Scrum Trainer alla scrum.org e questi sono i podcast di Collective Genius, dedicati a tutti coloro i quali vogliono approfondire o imparare Scrum Professionale.”

📑 Sommario

In questo episodio speciale, intervistiamo Emanuele Vecchio, sviluppatore software e appassionato di Scrum. Scopriamo il suo percorso di adozione di Scrum, i benefici ottenuti nel suo team e le sfide affrontate. Un’intervista ricca di spunti e riflessioni sul valore dell’empirismo e dell’approccio Scrum non solo nel lavoro ma anche nella vita.

🎧 Ascolta l’Episodio

🎯 Chi è Emanuele Vecchio

  • Sviluppatore software dal 2007
  • Autore di una saga fantasy Midda’s Chronicles pubblicata tramite blog dal 2008
  • Disegnatore di fumetti “Fra Bernardo – Uno di Noi” su Instagram dal 2020
  • Volontario presso Emergency e i musei di Torino
  • Appassionato di Clean Code e dei principi di Uncle Bob

🔄 Il Percorso con Scrum

L’Inizio del Viaggio

  • Prima esperienza con Scrum nel 2015
  • Partecipazione allo Scrum Breakfast Club di Milano
  • Inizialmente limitato da vincoli aziendali tradizionali
  • Svolta dopo il cambio di gruppo di lavoro

Impatto sul Team

  • Trasformazione da conflittualità a collaborazione
  • Adozione del framework Nexus per scalare Scrum
  • Formazione di tre team Scrum coordinati
  • Miglioramento della comunicazione e della qualità del prodotto

💡 Le Sfide Attuali

  • Resistenza organizzativa al cambiamento culturale
  • Uso improprio dei termini e pratiche Scrum
  • Mancanza di un vero Product Owner
  • Gestione tradizionale mascherata da Agile

⚙️ Best Practices Condivise

  • Importanza dei valori Scrum: impegno, focus, apertura, rispetto e coraggio
  • Necessità di seguire fedelmente la Scrum Guide
  • Valore delle retrospettive regolari
  • Focus sull’empirismo e sull’adattamento continuo

📚 Approfondimenti Consigliati

🎓 Note Chiave

La prima regola per fare Scrum è fare Scrum. Come per cucinare una torta di mele servono ingredienti specifici e una ricetta da seguire, allo stesso modo per Scrum servono impegno, focus, apertura, rispetto e coraggio – i valori Scrum – miscelati in un continuo reiterarsi di trasparenza, ispezione e adattamento.

Emanuele Vecchio

🔜 Prossimo Episodio

Non perdere il prossimo episodio del podcast Scrum Italia, un’altra intervista dove parleremo di come l’agilità sia una caratteristica naturale che perdiamo col tempo.


Questo articolo è basato sull’episodio 25 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.


Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.

Iniziare con Scrum

Intervista: Adottare Scrum nei Prodotti Hardware [E24]

ℹ️ Intervista Scrum e Hardware 📅 Data: 06/06/2023 ⏱️ Durata: 24 minuti

🎙️ Introduzione

“Ciao, io sono Fabio Panzavolta, Professional Scrum Trainer alla scrum.org e questi sono i podcast di Collective Genius, dedicati a tutti coloro i quali vogliono approfondire o imparare Scrum Professionale.”

📑 Sommario

In questo episodio, intervistiamo Luca Giancristofaro, ingegnere dell’automazione con esperienza nello sviluppo hardware e firmware. Scopriremo il suo percorso di adozione di Scrum in un contesto di prodotti fisici, le sfide affrontate e i benefici ottenuti nel passaggio da un approccio waterfall a Scrum.

🎧 Ascolta l’Episodio

🎯 Chi è Luca Giancristofaro

Luca è un ingegnere dell’automazione laureato nel 2008, con esperienza nel campo dell’elettronica, hardware e firmware. Ha lavorato inizialmente con metodologie waterfall per poi abbracciare Scrum negli ultimi anni. Attualmente si occupa dello sviluppo di prodotti che combinano hardware e software nel settore degli elettrodomestici.

🔄 Principali Punti Discussi

Il Passaggio a Scrum

  • Transizione da waterfall a Scrum per gestire meglio le richieste multiple
  • Miglioramento nella prioritizzazione delle attività
  • Maggiore chiarezza e consenso sulle direzioni di sviluppo
  • Aumento della trasparenza nel team

Benefici Riscontrati

  • Riduzione degli sprechi
  • Maggiore trasparenza attraverso le Sprint Review
  • Migliore allineamento tra stakeholder
  • Facilitazione della comunicazione tra team interni ed esterni

Sfide Attuali

  • Gestione di team ibridi (personale interno ed esterno)
  • Applicazione di Scrum su prodotti fisici
  • Implementazione efficace della Definition of Done
  • Mantenimento della coesione del team

💡 Consigli per Chi Inizia con Scrum

  1. Comprendere le fondamenta di Scrum prima di applicarlo
  2. Non vedere Scrum come un semplice insieme di regole da seguire
  3. Cercare di capire il “perché” dietro ogni elemento del framework
  4. Iniziare con piccoli cambiamenti se non si ha supporto completo
  5. Vivere l’adozione di Scrum positivamente a livello personale e di team

📚 Approfondimenti Consigliati

🎓 Note del Trainer

L’esperienza di Luca dimostra come Scrum possa essere applicato con successo anche in contesti non puramente software. La chiave del successo sta nella comprensione profonda dei principi e dei valori di Scrum, oltre che nella capacità di adattarli al proprio contesto specifico.

Fabio Panzavolta, Professional Scrum Trainer

🔜 Prossimo Episodio

Non perdete il prossimo episodio del podcast Scrum Italia, parleremo di Scrum e le torte di mele.

Questo articolo è basato sull’episodio 24 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.


Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.

Project Management e Professional Scrum

Project Manager e Scrum Master, due mestieri diversi

Project Manager e Scrum Master sono due mestieri diversi. Se sei un project manager, senti parlare sempre di più di Scrum e vorresti capire cosa c’è di così diverso fra questi due ruoli? Perché dovresti scegliere fra l’uno o l’altro e non si può fare un pò dei due?

In questo articolo provo a condividere le risposte a queste domande, con i principi e le ragioni che differenziano Scrum Professionale dal Project Management.

L’obiettivo non è quello di convincere che Scrum è la soluzione miracolo a tutto, al contrario. La mia esperienza come project manager mi porta ad apprezzare tutto quello che ho imparato durante gli anni spesi a gestire progetti in modo tradizionale.

Aggiornamento del 6 luglio 2023 – aggiunta del video dell’evento in diretta relativo a questa tematica.

Premessa

Ho avuto tre esperienze principali di lavoro:

  1. Sviluppatore software per sistemi industriali complessi (essenzialmente C, C++ e SQL) dal 2001 al 2006 (6 anni)
  2. Team leader, project e program manager nel settore bancario, trasporto e logistica, finanza dal 2007 al 2014 (8 anni)
  3. Scrum Master e Professional Scrum Trainer dal 2015 ad oggi (9 anni)

Conosco bene cosa pensa (e cosa vive) uno sviluppatore, un project manager o uno Scrum Master. In particolare, per averli vissuti personalmente, conosco le sfide che un project manager deve affrontare se vuole diventare un buon Scrum Master.

Esploriamole insieme!

Project Manager e Scrum Master

Sono due mestieri diversi. È importante capirlo, perché il focus e le responsabilità di questi due ruoli sono diametralmente opposti.

Project Manager
Il Project Management funziona bene in contesti complicati o semplici (clicca sull’immagine per accedere all’articolo del blog “Cynefin, Scrum e Agile”)

Project Manager: ha per missione di tenere sotto controllo costi, time e scope del progetto. Garantisce all’azienda che gli investimenti strategici sono correttamente gestiti. Spesso è un esperto tecnico o funzionale e dice ai colleghi cosa fare, assegna i task e controlla che siano eseguiti secondo i piani. Ne parlo in questo articolo.

Un project manager lavora per soddisfare il management interno, ovvero controllare che il lavoro sia eseguito secondo i piani.

Fabio Panzavolta
Scrum Master
Scrum funziona bene in contesti complessi (clicca sull’immagine per accedere all’articolo del blog “Cynefin, Scrum e Agile”)

Scrum Master: ha per missione di assicurarsi che Scrum è correttamente capito ed utilizzato. Contrariamente al project manager, i risultati del team “non gli interessano”. Se i membri dello Scrum Team hanno capito cosa vuol dire creare prodotti complessi in modo empirico, i risultati arriveranno.

Lo Scrum Master è un servant leader, aiuta a rimuovere gli ostacoli che impediscono il raggiungimento degli obiettivi del team (ne parlo in questo articolo).

Uno Scrum Master (con tutto lo Scrum Team) lavora per soddisfare gli utilizzatori del prodotto il più rapidamente possibile.

Fabio Panzavolta

Project Manager e Scrum Master, focus interno o esterno all’azienda?

La ragione di esistere di un project manager è quella di limitare i rischi aziendali garantendo il controllo degli investimenti.

Questo funziona principalmente per progetti altamente prevedibili, per i quali non sono previsti cambiamenti sostanziali durante lo sviluppo.

Quando lavoravo come project manager i primi cambiamenti al piano del progetto arrivavano molto rapidamente. Questo portava inevitabilmente a ginnastiche improbabili per non stravolgere il piano.

Project Manager – Focus interno

Per un Project Manager il focus è interno all’azienda, si passa più tempo a negoziare un paio d’ore di lavoro a destra e sinistra con gli sviluppatori che a sviluppare effettivamente il prodotto.

Questo focus interno porta a perdere di vista il perché si fa un progetto concentrandosi principalmente su budget, time e scope.

Ho personalmente conosciuto sviluppatori software che lavoravano da due anni su un progetto e non avevano mai visto il prodotto finito… immaginate la motivazione e l’impegno che potevano mettere al lavoro.

Scrum Master – Focus esterno

Uno Scrum Master, aiuta lo Scrum Team e gli stakeholders a fare un focus sui problemi da risolvere agli utilizzatori, ad ottimizzare il lavoro non fatto per concentrarsi solo su ciò che è veramente importante: il valore creato per gli utilizzatori del prodotto.

Questo non vuol dire che i limiti aziendali sono ignorati, perché il Product Owner fa attenzione a massimizzare il valore del prodotto. Quindi, per esempio, il budget a disposizione è speso in maniera opportunistica e non pianificata su un anno o due, ma con cicli di un mese al massimo.

Massimizzare il valore del prodotto vuol dire, fra l’altro, che la strategia del Product Owner implica la creazione di un prodotto che si auto-finanzierà il prima possibile.

Project Manager e Scrum Master, Scope fisso o variabile!

Altro cambiamento fondamentale, uno Scrum Master aiuta ad acquisire un modo di lavorare orientato sugli obiettivi, i requirements ci interessano, ma fino ad un certo punto.

Il project manager raccoglie tutti i requisiti, che molto spesso fanno parte del contratto. Per ottimizzare (sigh, sob 😊) si cerca di elencare tutte le funzionalità, con il cliente, nelle prime fasi del progetto. In modo tale da non doversi più vedere per un annetto o due (ri-sigh, ri-sob).

Ovviamente questo modo di lavorare funziona, come dicevo prima, se ciò che state facendo non ha incertezze sostanziali.

Purtroppo (in particolare per l’informatica), molto spesso il cliente non sa nemmeno cosa vuole. Oppure (che è anche peggio) è assolutamente convinto di sapere cosa vorrebbe avere (poi si scopre che gli utenti e i loro problemi quotidiani non li conosce veramente).

Quindi il povero project manager (esperienza vissuta) fa dei piani nel momento in cui il team, il cliente e lui stesso hanno meno esperienza e meno informazione possibile… conoscete i risultati… altrimenti non sareste arrivati fino qui a leggere 😊.

Da Project Manager a Scum Master

Questo problema è risolto in Scrum, perché invece di lavorare a scope fisso, si lavora con obiettivi fissi, concedendo una certa “liquidità” nelle funzionalità da implementare grazie all’ordinamento del Product Backlog.

Lo Scrum Master insegnerà a tutti (anche al cliente) come fondare il lavoro su obiettivi, generare risultati concreti per gli utilizzatori e farà in modo che le esigenze emergano con l’esperienza, grazie al feedback degli utilizzatori ed alla collaborazione regolare con il cliente.

In un mondo complesso ed incerto, quando non si sa veramente cosa si vuole, un prodotto non si pianifica, emerge dall’esperienza.

Fabio Panzavolta

Scegliere di fissare un obiettivo ed avere funzionalità variabili avrà come conseguenza una migliore qualità, più implicazione da parte di tutti, più innovazione nella ricerca di soluzioni e più rilasci in produzione.

Project Manager e Scrum Master, dalle esigenze agli obiettivi

Parlavo di contratto prima… quante volte, da project manager, mi sono trovato a dover discutere con il cliente per giorni, settimane per cambiare una virgola in una particolare esigenza… con il risultato che dopo la discussione ci volevano altre settimane per avere il GO per implementare il cambiamento (che nel frattempo, a volte, era già stato fatto).

Purtroppo, in certi casi, ci siamo anche trovati ad implementare delle cose che sapevamo sbagliate, o incoerenti, per non dover subire il processo descritto sopra.

Il focus sulle esigenze è un focus malato in un contesto complesso e mutevole.

Fabio Panzavolta

Il giusto focus è negli obiettivi… in Scrum ce ne sono due:

  • Product Goal: definito dal Product Owner, è un obiettivo a medio termine, un passo in più verso la visione del prodotto
  • Sprint Goal: definito dallo Scrum Team, è un obiettivo a corto termine (un mese massimo), un passo in più verso il Product Goal

In un contratto si possono fissare i Product Goal, facendo attenzione a non renderli troppo stringenti, bensì sufficientemente vaghi per dare una direzione e lasciare libertà nel decidere cosa e come sperimentare nuove soluzioni.

Segui questo link se vuoi saperne di più sui contratti agili.

Riuscire a fare un focus sul goal (Scrum Professionale) e non sui requirements (Project Management), vuol dire concentrarsi sul perché si vuole fare qualcosa, non sul come. Le discussioni sul cosa e come raggiungere l’obiettivo saranno legate al perché si vogliono fare, con un focus maggiore, più o meno funzionalità a seconda del contesto e degli esperimenti che si faranno collaborando.

Conclusioni

Project Manager e Scrum Master sono due mestieri diversi, con focus diverso. Non si può pensare di accettare un ruolo di Scrum Master senza aver capito Scrum Professionale o le responsabilità di uno Scrum Master (ne parlo in un episodio del podcast Scrum 🇮🇹).

La difficoltà non è Scrum, bensì il cambiamento nel modo di pensare, agire e prendere decisioni.

Uno Scrum Master si accontenta di rivelare ciò che non funziona secondo Scrum, non dà soluzioni o dice agli altri cosa fare. Piuttosto, aiuta le persone a trovare e sperimentare le soluzioni grazie alle idee che emergono discutendo.

Se sei un Project Manager e desideri cominciare o continuare il tuo percorso di professionalizzazione, puoi cominciare da autodidatta.

Personalmente ho letto tanto, questi sono i libri, ho praticato in condizioni differenti (prima in contesti al di fuori del lavoro, poi al lavoro) e non smetto mai di pensare che sto ancora imparando.

Un’altra fonte inesauribile di conoscenza è ovviamente il sito scrum.org, ma anche i blog di Ken Schwaber e Gunther Verheyen, i miei due punti di riferimento.

Se vuoi imparare o migliorare la tua conoscenza di Scrum Professionale, facendoti accompagnare, puoi anche scegliere di partecipare ad una delle nostre formazioni.

Scrum On!

Empirismo e Scrum

Empirismo in Scrum [E23]

ℹ️ Empirismo in Scrum 📅 Data: 30/05/2023 ⏱️ Durata: 17 minuti

🎙️ Introduzione

“Ciao, io sono Fabio Panzavolta, Professional Scrum Trainer alla scrum.org e questi sono i podcast di Collective Genius, dedicati a tutti coloro i quali vogliono approfondire o imparare Scrum Professionale.”

📑 Sommario

In questo episodio esploriamo l’empirismo, uno dei pilastri fondamentali di Scrum. Scopriremo perché l’approccio empirico è essenziale nella risoluzione di problemi complessi e come si differenzia dall’approccio predittivo tradizionale. Vedremo anche come questo pilastro si integra con i tre elementi chiave: trasparenza, ispezione e adattamento.

🎧 Ascolta l’Episodio

🎯 Cos’è l’Empirismo in Scrum

L’empirismo in Scrum rappresenta un approccio fondamentalmente diverso dalla gestione tradizionale predittiva. Si basa sul principio che:

  • La conoscenza deriva dall’esperienza diretta
  • Le decisioni si basano su ciò che si è osservato
  • Il futuro non è completamente prevedibile

🔄 Caratteristiche Principali

Approccio Iterativo e Incrementale

  • Permette l’emergere di soluzioni non previste inizialmente
  • Aiuta a controllare vari tipi di rischi (investimenti, direzione, tecnici)
  • Costruisce fiducia gradualmente nel team

I Tre Pilastri dell’Empirismo

  • Trasparenza: sullo stato del prodotto e elementi decisionali chiave
  • Ispezione: verifica regolare dei risultati e progressi
  • Adattamento: modifiche basate su ciò che si è appreso

💡 Benefici dell’Approccio Empirico

  • Migliore gestione dei rischi
  • Ottimizzazione del lavoro non fatto
  • Maggiore collaborazione nel team
  • Decisioni basate su dati reali
  • Previsioni più accurate nel lungo termine

⚙️ Best Practices

Gestione Efficace

  • Focus sugli obiettivi invece che sui metodi
  • Implementazione incrementale delle funzionalità
  • Verifica costante con gli utilizzatori
  • Adattamento continuo del processo

Raccolta e Utilizzo dei Dati

  • Misurazione regolare dei progressi
  • Analisi dei pattern emergenti
  • Utilizzo dei dati per previsioni future
  • Mantenimento della trasparenza

📚 Approfondimenti Consigliati

🎓 Note del Trainer

L’empirismo non significa rinunciare a fare previsioni o piani, ma cambiare il modo in cui li facciamo. Si tratta di basare le decisioni su dati reali e osservazioni concrete, costruendo gradualmente la fiducia attraverso risultati tangibili.

Fabio Panzavolta, Professional Scrum Trainer

🔜 Prossimo Episodio

Non perdete il prossimo episodio, la prima intervista ad un praticante di Scrum.

Questo articolo è basato sull’episodio 23 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.


Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.

Lean Thinking e Scrum

Lean Thinking e Scrum [E22]

ℹ️ Lean Thinking e Scrum 📅 Data: 26/05/2023 ⏱️ Durata: 21 minuti

🎙️ Introduzione

“Ciao, io sono Fabio Panzavolta, Professional Scrum Trainer alla scrum.org e questi sono i podcast di Collective Genius, dedicati a tutti coloro i quali vogliono approfondire o imparare Scrum Professionale.”

📑 Sommario

In questo episodio esploriamo il Lean Thinking e la sua profonda connessione con Scrum. Scopriremo come questi due approcci si completano a vicenda e come il Lean Thinking influenza la cultura aziendale, l’eliminazione degli sprechi e la creazione di valore per il cliente.

🎧 Ascolta l’Episodio

🎯 Cos’è il Lean Thinking

Il Lean Thinking, termine coniato da John Krafcik nel 1988, è un approccio che mira a:

  • Creare valore il più rapidamente possibile
  • Eliminare qualsiasi tipo di spreco
  • Ottimizzare i processi aziendali
  • Allineare la soddisfazione del cliente con quella dei dipendenti

🔄 I 5 Principi del Lean Thinking

1. Valore

  • Focus sull’utilizzatore finale
  • Creazione di valore concreto e misurabile
  • Comprensione delle esigenze del cliente

2. Value Stream

  • Mappatura del flusso di creazione del valore
  • Identificazione di tutti gli step necessari
  • Ottimizzazione del percorso dalla richiesta alla consegna

3. Flow (Flusso)

  • Eliminazione dei colli di bottiglia
  • Ottimizzazione del flusso di lavoro
  • Rilascio costante di valore

4. Pull

  • Responsabilizzazione del team
  • Auto-assegnazione del lavoro
  • Stimolazione dell’auto-organizzazione

5. Perfezione

  • Qualità impeccabile del prodotto
  • Rifiuto di compromessi sulla qualità
  • Miglioramento continuo

💡 Connessione tra Lean e Scrum

Origini Comuni di Lean thinking e Scrum

Impatto sulle Accountability

  • Product Owner: ottimizzazione del valore attraverso il Product Backlog
  • Developers: focus sulla qualità e soluzioni tecniche efficienti
  • Scrum Master: facilitazione del pensiero lean nel team

⚙ Benefici dell’Approccio Lean in Scrum

  • Riduzione dei costi di sviluppo
  • Maggiore soddisfazione degli utenti
  • Incremento della qualità del prodotto
  • Miglioramento del coinvolgimento del team
  • Ottimizzazione dei processi aziendali

📚 Approfondimenti Consigliati

  • Storia del Lean Thinking in Toyota
  • Implementazione dei principi Lean nel software development
  • Tecniche di eliminazione degli sprechi
  • Metriche di misurazione del valore

🎓 Note del Trainer

“Il Lean Thinking non è solo una metodologia, ma una vera e propria filosofia che, combinata con Scrum, permette alle organizzazioni di creare prodotti di valore superiore con meno sprechi. La chiave del successo sta nell’adozione di questa mentalità a tutti i livelli dell’organizzazione.”

Fabio Panzavolta

🔜 Prossimo Episodio

Non perdete il prossimo episodio dove approfondiremo l’empirismo in Scrum.

Questo articolo è basato sull’episodio 22 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.


Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.

Incremento Scrum

L’Incremento in Scrum: Pietra Miliare del Valore [E19]

ℹ️ Incremento in Scrum 📅 Data: 02/05/2023 ⏱️ Durata: 22 minuti

🎙️ Introduzione

“Ciao, io sono Fabio Panzavolta, Professional Scrum Trainer alla scrum.org e questi sono i podcast di Collective Genius, dedicati a tutti coloro i quali vogliono approfondire o imparare Scrum Professionale.”

📑 Sommario

In questo episodio approfondiamo il concetto dell’Incremento in Scrum, uno degli artefatti fondamentali del framework. Esploriamo come rappresenti una pietra miliare verso il Product Goal, le sue caratteristiche essenziali e il ruolo cruciale della Definition of Done nel garantire la qualità del prodotto.

🎧 Ascolta l’Episodio

🎯 Cos’è l’Incremento

L’Incremento rappresenta una versione utilizzabile del prodotto che:

  • Si aggiunge in modo cumulativo agli increment precedenti
  • È verificato accuratamente per garantire l’integrazione con gli increment precedenti
  • Deve essere usabile per fornire valore
  • Può essere rilasciato prima della fine dello Sprint
  • Viene presentato durante la Sprint Review per supportare l’empirismo

🔄 Caratteristiche Principali

Definition of Done

  • Descrizione formale dello stato dell’incremento
  • Definisce le metriche di qualità richieste
  • Crea trasparenza nel team
  • Fornisce una comprensione condivisa del lavoro completato

Gestione dell’Incremento

  • Può essere rilasciato prima della Sprint Review
  • La Sprint Review non è un gate obbligatorio
  • Deve soddisfare la Definition of Done per essere considerato un Incremento
  • Richiede integrazione quando più team lavorano sullo stesso prodotto

💡 Benefici dell’Incremento

  • Garantisce trasparenza del lavoro svolto
  • Permette ispezione e adattamento efficaci
  • Facilita il feedback degli stakeholder
  • Supporta il processo decisionale
  • Mantiene alta la qualità del prodotto

⚙️ Best Practices

Per la Definition of Done

  • Includere criteri di qualità tecnici
  • Considerare aspetti di documentazione
  • Adattare ai requisiti organizzativi
  • Evolvere con il prodotto

Per la Gestione

  • Scomporre in funzionalità atomiche
  • Integrare frequentemente
  • Mantenere alta la qualità
  • Collaborare tra team quando necessario

📚 Approfondimenti Consigliati

  • La Scrum Guide: capitolo sull’Incremento
  • Tecniche di integrazione continua
  • Pattern di Definition of Done efficaci
  • Metriche di qualità del software

🎓 Note del Trainer

“L’Incremento è il cuore pulsante di Scrum: rappresenta il valore tangibile che consegniamo ai nostri stakeholder. La chiave del successo sta nel mantenere alta la qualità attraverso una Definition of Done chiara e condivisa, evitando scorciatoie che potrebbero compromettere la trasparenza dell’empirismo.”

🔜 Prossimo Episodio

Non perdete il prossimo episodio dove approfondiremo altri aspetti fondamentali di Scrum.

Questo articolo è basato sull’episodio 19 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.


Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.

Pianificazione Sprint in Scrum

Lo Sprint Backlog: Guida alla Pianificazione Sprint [E18]

ℹ️ Pianificazione Sprint Backlog 📅 Data: 25/04/2023 ⏱ Durata: 13 minuti

🎙️ Introduzione

“Ciao, io sono Fabio Panzavolta, Professional Scrum Trainer alla scrum.org e questi sono i podcast di Collective Genius, dedicati a tutti coloro i quali vogliono approfondire o imparare Scrum Professionale.”

📑 Sommario

In questo episodio esploriamo lo Sprint Backlog, un artefatto di Scrum che comprende lo Sprint Goal, gli elementi del Product Backlog selezionati per lo Sprint e il piano per la realizzazione dell’Incremento. Scopriremo come questo strumento supporta l’autogestione del team e contribuisce al successo dello Sprint.

🎧 Ascolta l’Episodio

🎯 Cos’è lo Sprint Backlog

Lo Sprint Backlog è un artefatto gestito dai Developer, contiene la pianificazione dello Sprint che si compone di tre elementi essenziali:

  • Lo Sprint Goal (il perché)
  • Gli elementi selezionati dal Product Backlog (il cosa)
  • Il piano attuabile per la consegna dell’Incremento (il come)

🔄 Caratteristiche Principali

Gestione e Responsabilità

  • Gestito esclusivamente dai Developer
  • Aggiornato costantemente durante lo Sprint
  • Riflette l’apprendimento e l’adattamento del team

Focus sull’Autogestione

  • Nessuna interferenza esterna nella gestione
  • Developers collaborano alla pari senza gerarchie
  • Flessibilità nel raggiungimento dello Sprint Goal

💡 Benefici dello Sprint Backlog

  • Fornisce trasparenza sul lavoro pianificato
  • Supporta l’ispezione dei progressi durante il Daily Scrum
  • Promuove la collaborazione del team
  • Mantiene il focus sullo Sprint Goal

⚙ Best Practices

Gestione Efficace

  • Mantenere lo Sprint Goal visibile e accessibile
  • Aggiornare regolarmente il backlog
  • Collaborare con il Product Owner per eventuali modifiche

Negoziazione dei Cambiamenti

  • Discutere le modifiche necessarie con il Product Owner
  • Mantenere la coerenza con lo Sprint Goal
  • Assicurare che i cambiamenti non compromettano l’obiettivo

📚 Approfondimenti Consigliati

  • La Scrum Guide: Sprint Backlog e Sprint Goal
  • Tecniche di visualizzazione del backlog
  • Gestione efficace dei cambiamenti durante lo Sprint
  • Pratiche di autogestione del team

🎓 Note del Trainer

“Lo Sprint Backlog non è solo un elenco di attività, ma uno strumento che promuove l’autogestione e la collaborazione del team. La chiave del successo sta nella sua trasparenza e nella capacità di adattarsi alle scoperte fatte durante lo Sprint, mantenendo sempre il focus sullo Sprint Goal.”

🔜 Prossimo Episodio

Non perdete il prossimo episodio dove approfondiremo la Sprint Review in Scrum.

Questo articolo è basato sull’episodio 18 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.


Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.

artefatti Scrum e loro impegni

Gli Artefatti Scrum: Trasparenza e Impegno nel Framework Agile [E16]

ℹ️ Artefatti Scrum 📅 Data: 11/04/2023 ⏱ Durata: 15 minuti

🎙️ Introduzione

“Ciao, io sono Fabio Panzavolta, Professional Scrum Trainer alla scrum.org e questi sono i podcast di Collective Genius, dedicati a tutti coloro i quali vogliono approfondire o imparare Scrum Professionale.”

📑 Sommario

In questo episodio esploriamo gli artefatti di Scrum: Product Backlog, Sprint Backlog e Increment. Scopriremo come questi elementi fondamentali del framework rappresentano il lavoro e il valore, e come sono collegati ai rispettivi impegni (commitment) che ne garantiscono l’efficacia.

🎧 Ascolta l’Episodio

🎯 Cos’è un Artefatto in Scrum

Un artefatto in Scrum è un elemento creato dall’intelligenza umana che rappresenta informazione, lavoro o valore. Gli artefatti sono progettati per:

  • Massimizzare la trasparenza delle informazioni chiave
  • Fornire una base comune per l’ispezione e l’adattamento
  • Garantire la visibilità dell’avanzamento del lavoro

🔄 I Tre Artefatti Principali

Product Backlog

  • Contiene tutto il lavoro da realizzare per il prodotto
  • È associato al Product Goal come impegno
  • Rappresenta la visione a medio-lungo termine

Sprint Backlog

  • Contiene il lavoro pianificato per lo Sprint corrente
  • È legato allo Sprint Goal come impegno
  • Ha una durata massima di un mese

Increment

  • Rappresenta l’ultima versione del prodotto
  • È associato alla Definition of Done come impegno
  • Riflette l’approccio iterativo e incrementale di Scrum

💡 Gli Impegni (Commitment)

Ogni artefatto è associato a un impegno specifico:

  • Product Goal: Impegno a medio termine visibile nel Product Backlog
  • Sprint Goal: Impegno a breve termine (massimo un mese) visibile nello Sprint Backlog
  • Definition of Done: Impegno sulla qualità dell’Increment

⚙️ Importanza degli Impegni

Gli impegni in Scrum:

  • Rinforzano l’empirismo e i valori Scrum
  • Garantiscono la trasparenza per il team e gli stakeholder
  • Supportano il processo decisionale
  • Mantengono alta la qualità del prodotto

📚 Approfondimenti Consigliati

  • La Scrum Guide: Artefatti e loro impegni
  • Pattern di trasparenza in Scrum
  • Gestione efficace degli artefatti
  • Metriche per misurare l’avanzamento

🎓 Note del Trainer

“Gli artefatti in Scrum non sono semplici documenti o deliverable, ma rappresentano impegni concreti che il team prende verso la qualità e il valore. La loro corretta gestione è fondamentale per mantenere la trasparenza e permettere un’efficace ispezione e adattamento.”

🔜 Prossimo Episodio

Non perdete il prossimo episodio dove approfondiremo il Product Backlog e il Product Goal in dettaglio.

Questo articolo è basato sull’episodio 16 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.


Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.

Cynefin, Scrum e Agile

Cynefin, Scrum e Agile

In questo articolo, Cynefin, Scrum e Agile, condivido parte della trascrizione di una conferenza di Dave Snowden del 2017. Mi ha permesso di capire che cos’è un sistema complesso e perché Scrum e Agile sono, al momento, gli approcci più efficaci per risolvere problemi complessi.

Consultare l’ultima versione di Cynefin.

Introduzione – Cynefin, Scrum e Agile

Per capire, trascrivere prima in inglese e poi tradurre in italiano questo video ho impiegato circa 12 ore. Spero che apprezzerai lo sforzo. L’articolo ti è stato utile e vuoi ricompensarmi? Allora condividi l’articolo o parlane con i colleghi, grazie!

Importante: l’articolo è la traduzione in italiano, pura e semplice, di parti del video qui sopra. Non ho nessun merito se non quello di aver tradotto le parole di Dave Snowden, che vi invito a seguire.

[ndr. I miei commenti, osservazioni, aggiunte alle parole di Dave sono fra parentesi quadre, precedute dalla menzione ndr. e in italico]. Buona lettura!

In natura esistono tre tipi di sistemi: ordinati, complessi e caotici.

Sistema ordinato

Un sistema ordinato è un sistema altamente vincolato, rigido. Si conoscono tutti gli elementi che lo compongono.

I collegamenti e le interazioni all’interno del sistema sono rigidi e definiti. In un sistema ordinato tutto è prevedibile, c’è una relazione lineare tra causa ed effetto.

Una sala operatoria è un esempio di sistema ordinato, posso sempre dire: “se faccio questa azione, ho sempre questo risultato”.

Nelle sale operatorie, si contano quanti strumenti chirurgici ci sono prima dell’operazione e quanti ce ne sono alla fine. Questo per evitare di dimenticarne all’interno del corpo del paziente e doverlo “riaprire” per fare pulizia.

Per arrivare a questo risultato, le persone hanno fra i 10 e 15 anni di formazione. Quando il chirurgo mette le mani in aria, l’infermiere sa quale strumento deve dargli.

Un sistema prevedibile richiede un investimento importante.

Non è possibile replicare questo tipo di interazioni senza formazioni intense e questo è l’errore che le persone fanno [ndr. che spesso si commette in azienda]. Si vede qualcosa che funziona bene in un contesto e lo si vuole riprodurre velocemente.

[ndr. Solo che non funziona, proprio perché] c’è un alto costo per ottenere ordine e un’enorme ricompensa quando si è capaci di raggiungerlo.

Purtroppo questo ordine può essere portato all’eccesso, con relative conseguenze negative.

[ndr. Le aziende che definiscono processi rigidi per lo sviluppo dei loro prodotti sono ottimi esempi. Ho lavorato in aziende dove i progetti seguivano fasi ben specifiche. Sequenziali. Analisi dei requisiti, concezione, sviluppo, ecc.

Era vietato cominciare la fase successiva se quella precedente non era terminata. Per terminarla dovevamo avere l’autorizzazione di un comitato appositamente creato per autorizzare la fine di una fase e l’inizio della successiva.

Visto che questi tipi di comitati si riunivano in modo non regolare, era pratica comune cominciare in anticipo la fase successiva ben prima della validazione. A volte si facevano addirittura le cose in parallelo (di nascosto) perché non aveva senso aspettare.

In altre parole, avevamo trovato un rimedio al sistema iper-vincolante.]

Se si vincola eccessivamente un sistema che non può essere naturalmente vincolato le persone troveranno delle alternative [ndr. più o meno “legali”].

[ndr. La conseguenza è una perdita importante di energia: la burocrazia ne è un esempio.] Fornisce un’apparenza di ordine, che in realtà richiede un enorme quantità di persone di buona volontà per far funzionare il sistema, nonostante tutto.

Vincolare eccessivamente un sistema può essere pericoloso. Un sistema ordinato ha valore in circostanze molto particolari.

Sistema caotico

Un sistema caotico non ha vincoli. Il sistema è casuale (random). Se un sistema diventa caotico accidentalmente (sistema eccessivamente vincolato, nessuno rispetta più le regole, contornare le regole è diventato normale), allora il sistema si disfa catastroficamente, diventando caotico. È un disastro.

D’altro canto, se si entra deliberatamente in un sistema caotico, allora si apre la strada all’innovazione o la capacità delle persone a interpretare in tempo reale determinate situazioni (la saggezza delle folle).

Quindi il caos è molto utile, se si capisce quando può essere utilizzato e quando deve essere evitato.

La completa casualità, se si raggiunge, ha vantaggi ma deve essere vincolata.

Sistemi complessi adattativi

In un sistema complesso adattativo ci sono talmente tanti impatti esterni che i pattern ripetitivi non esistono o, se esistono, è per puro caso ed in rare eccezioni.

[ndr. Ora introduciamo] il concetto di “coerenza retrospettiva”: [ndr. un fenomeno che ci porta a] vedere solo le cose che sembrano ripetersi.

Può essere pericoloso analizzare le cose in questo senso. [ndr. In un sistema complesso] ci sono talmente tanti fattori che interagiscono fra di loro continuamente che non c’è nessun modo di introdurre una relazione classica di causa ed effetto. Ed il modo in cui ciò è espresso normalmente, in un sistema complesso adattativo, non è causale bensì disposizionale.

Praticamente, si può affermare che il sistema è disposto ad evolvere in un certo modo ed è poco probabile che evolverà in un’altra direzione. Ma non si possono mai avere affermazioni accurate [ndr. e certe].

Ed è per questa ragione che in un contesto complesso si può modellizzazione il presente e vedere cosa si può fare nel presente per cambiare le cose. Non si definisce uno stato futuro.

Questa è una differenza fondamentale e profonda fra “complexity thinking” e “system thinking”.

Nel “system thinking” si fa il modello di uno stato futuro, la cultura aziendale, si definiscono gli obiettivi business e si comunica dove si vuole essere in futuro.

Nel modo di pensare complesso ci si concentra nel mappare il presente, si identifica cosa si può cambiare e, mentre si cambia, si controlla velocemente il cambiamento per rinforzare ciò che funziona bene e abbandonare il resto.

Tipo di sistema e stile di management

Il principio di base è comprendere in quale sistema ci si trova per gestirlo in modo appropriato.

Negli ultimi decenni, è stata praticata la politica dell’approccio standardizzato. Esiste questo metodo, è universale.

La realtà è che questo tipo di soluzioni sono applicabili solo in contesti ben particolari. [ndr. Si capisce meglio perché, in certe aziende, si cambia regolarmente metodo di lavoro. Il precedente non ha dato i risultati sperati. Allora applichiamo un nuovo approccio, ha un sacco di aspetti positivi, avrà sicuramente successo… e si riparte nelle stesse dinamiche. I dipendenti diventano allergici a qualsiasi tipo di nuovo metodo di lavoro e questo è una catastrofe per le persone e per l’azienda.

Se si capisce che si è in un sistema complesso, allora si deve accettare che i metodi o approcci universali non esistono.]

L’esempio della festa di compleanno per bambini di 9 anni.

Immagina di dover organizzare una festa per dei bambini di 9 anni. Immagina come potresti fare.

Foto di Katherine McAdoo su Unsplash

Per prima cosa bisogna decidere che tipo di sistema è. Caotico? Ordinato? Complesso?

Se è caotico vuol dire che i bambini sono liberi di fare tutto ciò che vogliono, in modo completamente casuale. Probabilmente la tua casa sarà distrutta alla fine della festa, ma è qualcosa che ci si aspettava fin dall’inizio, quando si è scelto il sistema caotico.

Quindi probabilmente trattare la festa di compleanno come un sistema caotico non è una buona idea.

Proviamo con un approccio ordinato allora…

Si definiscono gli obiettivi di apprendimento per la festa, prima che la festa cominci.

Gli obiettivi di apprendimento sono allineati con la mission statement per l’educazione dei bambini del tuo quartiere. Sono chiaramente espressi e visibili in poster motivazionali con belle immagini ispiranti.

Incolli questi poster un pò ovunque in casa e particolarmente nel luogo dove si terrà la festa.

Non chiedi ai bambini di giocare, invece distribuisci delle carte da gioco che spiegano come ogni bambino deve comportarsi.

Ovviamente hai anche preparato un project plan. Il project plan ha delle milestones chiare per tutta la festa, utilizzabili per valutare l’avanzamento della festa secondo gli obiettivi ideali prefissati.

Un adulto senior dà inizio alla festa con un video motivazionale.

Non vuoi che i bambini perdano tempo a giocare, perché non è previsto dagli obiettivi di apprendimento. Invece di giocare usano Power Point per dimostrare il loro commitment personale agli obiettivi della festa.

Dimostri come la loro ricompensa è direttamente legata al raggiungimento dei risultati attesi.

In seguito al grande successo del completamento della festa, proponi una post mortem review e promuovi nuove best practices per tutto il tuo quartiere.

Se, a questo punto, per una qualsiasi ragione improbabile, i bambini non sono felici, allora avrai bisogno di un professionista che racconterà storie divertenti per avere modelli mentali più felici e bambini meglio indottrinati a cui piacerà qualsiasi cosa gli presenterai la prossima volta. Oppure chiami un happiness consultant, o una variante delle due.

Forse anche il sistema ordinato non funziona poi così bene…

L’approccio complesso, in un certo modo, è molto più semplice.

Foto di Lance Asper su Unsplash

Si comincia con il tracciare una riga per terra. Questo è un limite (constraint) o vincolo in termini di complessità.

Guardi i bambini dritto negli occhi e dici: “se qualcuno osa superare quella riga torna a casa immediatamente, festa finita”. [ndr. in realtà nel video l’espressione è più divertente e colorita]

In seguito si introducono delle sonde caotiche catalitiche: calcio, barbecue, videogame. Con la speranza che si formerà una dinamica di gioco interessante per i bambini.

Questi sono anche chiamati “attractor”, se risultano benefici, si danno più risorse.

Quello che si cerca di fare è di favorire l’emergere di una coerenza benefica nei limiti dei vincoli imposti.

Creazione di prodotti complessi

Se si pensa alla creazione di prodotti complessi, probabilmente ora comincerai a pensare ad approcciarlo in modo diverso.

Non ci penseresti neppure un secondo di gestire una festa in modo ordinato o caotico. Perché allora lo facciamo al lavoro?

La realtà è che si userà molto meno energia per gestire vincoli, sonde catalitiche (barbecue, videogiochi) e strategie di amplificazione piuttosto che decidere in anticipo esattamente come le cose dovrebbero essere. Questo potrebbe dare un sentimento di controllo, ma non un obiettivo.

Cynefin

Cynefin è una parola irlandese, non traducibile in inglese [ndr. e nemmeno in italiano, clicca qui per la pronuncia corretta]. Significa il luogo di molteplici appartenenze. È la sensazione di essere in un continuo flusso di significato nel tempo, non è mai statico.

C’è una sensazione di flusso, di continuità. È un nome perfetto per un modello di complessità, perché nella complessità puoi sapere dove sei e da dove vieni, ma non capisci esattamente la causa e l’effetto.

In pratica è intrinsecamente comprensibile, ma bisogna gestire il flusso. È un pò come andare in canoa in una rapida, piuttosto che seguire una strada precisa e decisa in anticipo, devi costantemente prendere decisioni rapide perché nulla rimane sempre uguale.

Questo è il disegno di Cynefin.

Cynefin – Dave Snowden

Cynefin – Il disordine

La zona centrale è quella del disordine, lo stato di non sapere in quale degli altri sottosistemi ci si trova. Un posto infelice dove trovarsi, perché non si sa se il sistema è ordinato, complesso o caotico, quindi si tenta di fare ciò che è più facile.

Cynefin divide l’ordine in due. Lo divide in uno spazio dove la causa in una relazione è ovvia ed un’altro dove la causa in una relazione è complicata. Questa differenza è ovvia, perché se la relazione fra causa ed effetto è evidente, non bisogna preoccuparsi di spiegare le cose. Le persone faranno ciò che devono fare [ndr. Se piove apro l’ombrello].

Cynefin – Chiaro

In Inghilterra si guida a sinistra, se vai in Inghilterra e guidi a destra devi aspettarti conseguenze negative.

Il modello decisionale è molto semplice: percepire, categorizzare, rispondere e applichiamo le best practices. Abbiamo vincoli rigidi o fissi.

È una buona zona in cui stare, è bella e prevedibile, tutto è meraviglioso, ha un costo energetico molto basso, ma è una base molto pericolosa perché, se la si limita troppo, si ha un collasso nel caos.

Cynefin – Caos

Quindi, la parte inferiore di Cynefin è in realtà disegnata così, perché rappresenta un precipizio che porta nel caos. Se cado in quest’area, qui c’è una zona di compiacimento, penso che tutto funzioni.

Se hai guidato la macchina a Sorrento, e credi che il traffico segua la legge normale, allora aspettati un disastro. La prima volta che ho guidato a Napoli ho causato un tamponamento di massa perché il semaforo iniziava a diventare rosso, quindi ho rallentato. L’auto dietro di me ha reagito in tempo, ma dietro c’è stata un’ammucchiata perché a Napoli si va più veloci e ci sono due minuti di tempo per passare con il rosso prima che arrivi il traffico dall’altra parte. Quindi, si può sbagliare.

Nella pratica, non voglio che si verifichi un guasto catastrofico di questo tipo. Se succede, devo uscirne in fretta. Quello che faccio qui [ndr. nel caos] è agire, percepire, rispondere. La buona notizia è che non ci sono vincoli e la pratica è sempre nuova [ndr. novel practice]. È completamente diverso.

Non abbiamo un’occasione migliore per fare qualcosa di diverso di quando c’è una grave crisi [ndr. pensa al COVID]. Anzi, la crisi è la migliore opportunità che abbiamo per innovare. Perché in quel momento le persone sono aperte alle novità. Non si può innovare durante i periodi di stabilità, si può innovare solo durante i periodi di crisi [ndr. pensa allo smart working prima e dopo il COVID!].

Cynefin – Complicato

Nel sistema complicato le relazioni tra causa ed effetto non sono evidenti, ma possono essere scoperte attraverso l’analisi o l’applicazione di competenze.

Il modello qui è percepire, analizzare, rispondere. La pratica, naturalmente, è buona non migliore, [ndr. good practice al posto della best practice che troviamo nel dominio del semplice] e i vincoli sono chiamati vincoli di governo. In sostanza, all’interno di un limite posso variare ciò che faccio.

Un grande errore nella consulenza di queste iniziative è quello di costringere le persone a un unico approccio.

Le persone che hanno un’esperienza approfondita, dovrebbero avere la possibilità di variare il loro approccio. Agile tende a favorire un unico approccio [ndr. Complesso o complicato]. Tende a metodi che sono stati progettati per essere insegnati, piuttosto che per essere praticati, e naturalmente se si ha bisogno di insegnare si ha bisogno di processi rigidi, perché è più facile insegnare.

Quindi, come si capisce, è un problema generale dei metodi in tutto il mondo.

[ndr. Non sono d’accordo con i due paragrafi precedenti… Scrum Professionale e, più generalmente le formazioni di Scrum.org, insegnano a ragionare in modo adatto al contesto complesso. Ovviamente si passa un pò di tempo a spiegare le 11 (!!) regole di Scrum, che sono i famosi vincoli di cui Dave parla nell’ambito di un sistema complesso.]

Naturalmente, da questo si passa al dominio complesso.

Cynefin – Complesso

Il dominio complesso si gestisce con esperimenti paralleli, che possono fallire. Si sonda, percepisce e si risponde, ma in parallelo, non in sequenza.

Quindi, se ho quindici o sedici idee coerenti su quale sia la cosa giusta da fare, non cerco di risolverle. Ciascuna di queste idee riceve una piccola quantità di risorse per condurre un esperimento di durata limitata in parallelo con le altre idee. Perché l’unico modo per capire cosa è possibile fare è agire all’interno del sistema.

È qui che l’agilità fallisce, ci torniamo fra poco.

La pratica qui è emergente [ndr. emergent practice], con vincoli abilitanti, non vincoli governativi. È una distinzione molto importante. È una differenza tra regole ed euristiche.

Prendiamo alcuni esempi militari, come la famosa innovazione di Napoleone nella guerra. I generali marciavano al suono del cannone. È stata una rivoluzione perché, prima di allora, tutti seguivano gli ordini o agivano in modo autonomo. Ora esiste un principio di governo, il che significa che sanno più o meno cosa fare e sanno cosa faranno gli altri generali intorno a loro. Quindi, c’è un grado di cognizione distribuita o di intelligenza distribuita nel sistema.

I Marines degli Stati Uniti hanno tre regole: conquistare il punto più alto, rimanere in contatto, continuare a muoversi. Si noti che queste regole sono empiricamente misurabili. Non sono principi astratti, come mettere i clienti al primo posto, che possono essere reinterpretati. Sono concreti e tangibili.

Se si guarda in termini militari, sono un modo migliore di esprimere le intenzioni del comandante rispetto a piani precisi. Quindi, la complessità consiste nel gestire l’ambiguità necessaria.

Cynefin, Scrum e Agile

Applichiamo Cynefin ad Agile. Si possono usare gli stessi concetti, nella stessa immagine, aggiungendo un’altro vincolo al sistema. Si tratta della cosiddetta versione liminale [ndr liminal version] di Cynefin, che si presenta più o meno come nell’immagine qui sotto. Anche in questo caso, si tratta di una singola linea che crea di fatto due aree liminari.

Cynefin Liminare – Dave Snowden

La liminalità è un concetto chiave in antropologia. Nelle comunità indigene, quando qualcuno indossa una maschera, diventa uno stregone. C’è uno stato di transizione tra l’essere chi è e il ruolo assunto dalla maschera. E questo si chiama liminalità. Quindi, una condizione liminare è uno stato di transizione che lascia aperte le possibilità di tornare indietro o di andare avanti. La liminalità qui è fondamentale.

Facciamo delle categorie, per ogni sistema. Waterfall corrisponde al dominio del semplice. Non c’è niente di male nel Waterfall se si sa esattamente cosa si deve ottenere; si sa quali risorse, cosa si vuole fare: creare un progetto tradizionale. Tecniche come Prince2 funzionano bene. Non ci sono problemi. Cercare di rendere tutto agile è un errore.

Nel dominio del complicato si osservano tecniche come il timebox, che tendiamo a dimenticare. Solo perché uno Sprint è di due settimane non significa che il timebox non possa essere di tre mesi. [ndr. Qui non ho capito bene il concetto… in effetti uno Sprint può avere un timebox di 2 settimane, ma nulla vieta di avere un Product Goal di più Sprint, quindi con un timebox composto dalla somma dei timebox dei diversi Sprint… forse qui c’è un’incomprensione dei principi di Scrum]

Negli anni ’80 e ’90 si usavano molto queste tecniche. Garantiamo una data di consegna, ma variamo le risorse o la consegna per raggiungerla. E ci sono altre tecniche in questo campo.

Un framework dovrebbe aprire delle possibilità piuttosto che costringere a un solo modo di lavorare. Non c’è niente di sbagliato nell’usare il timebox. [ndr. Che è proprio il principio di Scrum, un framework descrittivo e non prescrittivo]

La forza dell’uso di Scrum, e Scrum è stato assolutamente vitale per tutto questo, è che Scrum sta nella parte blu dell’immagine.

La grande forza di Scrum è quella di mantenere le cose in uno stato liminale di trasmissione, in modo che non escano troppo velocemente dal dominio della complessità.

Questo si chiama convergenza prematura, si trova in quel dominio liminale, perché è un esperimento lineare basato su un requisito parzialmente noto.

Ecco tre esempi di tecniche che stiamo sperimentando [ndr. Riprese da Extreme Programming]:

  • Pair Programming, con l’aggiunta di un utilizzatore, formato a comunicare efficacemente con gli sviluppatori
  • Metodo Triple-Eight, si uniscono persone competenti nella concezione di prototipi con persone capace di svilupparli. Lavorano insieme agli utilizzatori per 8 ore e passano il prototipo ad un altro team che lavora sul prototipo per altre 8 ore (senza conoscere i requisiti utilizzatore e senza sapere perché il prototipo è stato creato, devono solo migliorarlo). Poi lo passano ad un terzo team, che esegue lo stesso lavoro per 8 ore. Alla fine il prototipo torna al punto di partenza. In questo modo si rinforza attivamente la mutazione per gestire l’incertezza. Ogni volta che abbiamo provato questo metodo gli utilizzatori erano molto soddisfatti. Si gestisce l’incertezza con metodi che costruiscono a loro volta incertezza.
  • Esigenze impreviste, richiediamo agli utilizzatori di catturare di continuo le loro frustrazioni quotidiane con l’IT. Si ottengono dati statistici su quali sono i problemi o le esigenze più pressanti e si lavora per risolverle

Se vogliamo che Agile sopravviva, dobbiamo renderlo un quadro flessibile e fluido di strumenti multipli provenienti da contesti diversi. Kanban funziona molto bene nel dominio complicato, ma non molto utile per quello complesso.

Anche l’idea del work-in-progress è buona, ma il modo in cui si rappresenta il work-in-progress nel dominio del complesso non è una serie di carte in colonne, ma una mappa paesaggistica delle potenzialità [ndr. Come le mappe del metro].

Quindi, dobbiamo iniziare a riconoscere la necessità di una diversità essenziale per variare e mescolare efficacemente i vari metodi e dobbiamo spostare l’attenzione di Agile dall’accreditamento [ndr. certificazioni] alla consegna.

L’esperienza conta più dei certificati e dobbiamo riconoscerlo.

Conclusioni

[ndr. Sembra chiaro che il mondo in cui viviamo richiede un modo di affrontare i problemi e le situazioni in modo molto diverso da quello che abbiamo imparato a scuola e negli anni di lavoro. Il determinismo non possibile in un mondo in costante movimento, il futuro non si può prevedere. Ciò che mi è piaciuto in questo video, nel discorso di Dave Snowden, è la coerenza dei propositi, il punto di vista spiegato in modo assolutamente brillante. Quando ho cominciato a praticare Scrum, venivo da anni di Project Management nel dominio dell’informatica. Ero solito scherzare, quando i capi mi chiedevano se il project plan era pronto. Rispondevo certo è pronto, sbrigatevi a leggerlo perché domani sarà già da aggiornare! Ma non capivo perché… ora capisco. E sono felice, perché sono intimamente convinto che grazie alle formazioni, workshop e coaching Scrum che offro sto un pochino cambiando il mondo in meglio!]

SpaceX Explosion

Creare prodotti complessi – L’esempio Spacex

Creare prodotti complessi impone una strategia di sviluppo centrata sull’esplorazione di soluzioni incrementali. SpaceX è un’ottimo esempio di come un prodotto evolve nel tempo, facendo tesoro dell’esperienza.

Spesso, in formazione o in clientela, mi sento dire che è impossibile sviluppare prodotti fisici in modo iterativo e incrementale. “Sai Fabio, questo non è software, noi facciamo prodotti fisici complessi”. Ok ok, capisco 😊.

Purtroppo queste affermazioni, ancora più spesso, sono fatte senza che si sia mai provato nulla di diverso. Strategie marketing e di vendita basate su processi predefiniti e rigidi non permettono di innovare. In questi contesti innovare significa far evolvere anche le funzioni a supporto del prodotto. Vediamo come, grazie all’esempio di SpaceX che, penso siamo d’accordo, crea prodotti piuttosto complessi 😊.

Nel seguito dell’articolo trovate le mie interpretazioni e supposizioni, frutto dell’osservazione dei video e altre informazioni trovate su internet. Non ho nessun tipo di contatto diretto con SpaceX. Se tu che leggi e conosci meglio SpaceX, sarò felicissimo di correggere gli eventuali errori di interpretazione!

Creare prodotti complessi: la storia dei vettori riutilizzabili

Quando SpaceX ha cominciato a sviluppare i vettori orbitali, ha dovuto far fronte ad un sacco di problemi. Alcuni di questi piuttosto visibili e spettacolari 💥.

I primi vettori erano di piccole dimensioni, studiati per inviare nell’atmosfera terrestre dei carichi di una certa massa, come piccoli satelliti.

Creare prodotti complessi – Le esplosioni che hanno insegnato tanto al team SpaceX

La domanda da farsi è: “come possiamo risolvere il problema che stiamo affrontando con il prodotto più piccolo ma utile possibile?“. Utile per noi in azienda per imparare e per i nostri clienti per poter fare cose che prima non potevano realizzare.

La serie di problemi ed esplosioni durante la fase di sviluppo ha dato l’idea al team SpaceX dei vettori riutilizzabili, quindi della “funzionalità” di rientro e atterraggio automatica.

Questo era qualcosa che non si era immaginato prima, che è emersa grazie ai diversi esperimenti fatti nello sviluppo. Si capisce quindi che l’innovazione non si pianifica, ma emerge durante lo sviluppo del prodotto.

Falcon 9 – il primo razzo di classe orbitale riutilizzabile (fonte sito SpaceX) è il risultato di tutte queste esplosioni (controllate o meno), e tante altre cose meno visibili ovviamente.

Al momento in cui scrivo questo articolo, il Falcon 9 ha fatto 195 lanci, 153 atterraggi, 132 voli di ritorno (fonte sito SpaceX) e ne fanno uno dei vettori meno cari del mercato per inviare satelliti in orbita.

Creare prodotti complessi – IL Falcon Heavy

Il Falcon Heavy è stato creato mettendo insieme 3 Falcon 9, anche qui si capisce quanto si pensi a riutilizzare ed integrare quello che già si sa.

Creare prodotti complessi – Falcon Heavy et Starman

Con il Falcon Heavy si ottiene una spinta al decollo equivalente a 18 aerei 747 (secondo il sito SpaceX) permettendo l’invio in orbita di masse più importanti e riducendo i costi di trasporto.

Ovviamente, grazie all’esperienza fatta con Falcon 9, questo modello ha subito molto meno esplosioni.

Secondo il sito SpaceX, al momento della scrittura di questo articolo, il Falcon Heavy ha fatto 5 lanci, 11 atterraggi, 6 voli di ritorno.

Andiamo avanti? 😊

Creare prodotti complessi – Starship

Questa è una navetta per trasporto merci e persone. Con questo mezzo si vuole raggiungere Marte.

Starship è il veicolo di lancio più potente al mondo mai sviluppato, con la capacità di portare in orbita terrestre oltre 100 tonnellate metriche (fonte sito SpaceX).

In qualche modo Starship è qualcosa di nuovo, l’esperienza passata con i Falcon 9 e Heavy è sicuramente servita. Ma qui si doveva imparare a far scendere a terra un bestione enorme. Ovviamente c’è stato qualche “piccolo” problema. Anche in questo caso utile per imparare e fare esperienza.

Creare prodotti complessi – I “piccoli” problemi durante lo sviluppo di Starship

Ciò che più mi ha affascinato, seguendo lo sviluppo di questo prodotto, è stato il modo in cui lo sviluppo iterativo e incrementale è evidente.

Dopo i test statici dei motori, Startship è stato fatto decollare a 100m da terra, poi sempre più in alto ed ogni volta per imparare qualcosa di preciso.

Anche le esplosioni avvenivano, a volte, di proposito. Proprio per capire cosa sarebbe successo in certe situazioni.

Si capisce come questo approccio “empirico” aiuti ad imparare in fretta, accumulare dati e risolvere problemi in un contesto di innovazione.

Il video qui sotto ha ispirato l’articolo che sto scrivendo. Si tratta del lancio di Falcon Heavy del 15 gennaio 2023. Si vedono i due booster tornare a terra, senza problemi. Francamente mi ha impressionato.

Al della prodezza tecnica, si capisce bene la logica di sviluppo dei prodotti che contraddistingue SpaceX e gli permette di essere il leader del loro settore.

Altra cosa che mi ha impressionato, è il tweet qui sotto di Musk, che mostra come sia stato fatto un passettino in più verso il raggiungimento della sua visione: andare su Marte.

Questo è quello che ci si aspetta da un Product Owner. Avere una visione, saperla comunicare e avere una strategia per raggiungerla.

Creare prodotti complessi - E così è come atterreremo su Marte.
Creare prodotti complessi – E così è come atterreremo su Marte.

Qua c’è una logica impressionante, brillante. Almeno per me. Applicare la stessa logica allo sviluppo di Software o Hardware non è poi così impossibile, cosa ne pensate?

Conclusioni

Quali problemi osservo nelle aziende che ho frequentato, che impediscono lo sviluppo agile di un prodotto?

  • Non c’è una sola persona responsabile dello sviluppo di un prodotto
  • Questa persona, se esiste, non ha l’autorità per prendere decisioni, o scende a compromessi per far contenti un pò tutti
  • Questa persona, se esiste, non è capace di concentrarsi sul perché e sul cosa, ma spesso interferisce su come fare le cose
  • Silos. Sales, Marketing, IT: spesso hanno la loro visione delle cose, solo che non si parlano, non la condividono, oppure lo fanno, ma troppo in fretta o troppo poco spesso.
  • Sicurezza psicologica: la creazione di prodotti complessi richiede un ambiente di lavoro nel quale ci si senta al sicuro per poter sperimentare, sbagliare e quindi imparare. Purtroppo l’ambiente di lavoro classico richiede persone che dimostrino di essere infallibili, di avere la risposta giusta al primo colpo. Il risultato è il teatro dell’opera, dove si fa finta di sapere le cosa anche quando non si sanno.

Non è un mistero quindi che, per creare prodotti complessi, un approccio agile e quindi empirico è il migliore. Volete innovare, volete battere la concorrenza? Allora prendete il gusto alla sfida, osate qualche bella esplosione 😊.

Aumenterete le vostre chances di essere vincenti!

Per approfondire

Validazione del Prodotto
Leadership - 5 cambiamenti fondamentali
Leadership – 5 cambiamenti fondamentali
Piccole vittorie: e se la trasformazione cominciasse da voi?
Piccole vittorie: e se la trasformazione cominciasse da voi?