Blog

group of people wearing shirts spelled team

Leadership – 5 cambiamenti fondamentali

Leadership – 5 cambiamenti fondamentali, analizza le origini dei problemi che bloccano l’innovazione impedendo a certe aziende di rimanere competitive.

Ho potuto osservare questi problemi nel corso degli ultimi 20 anni. In alcuni casi, ho contribuito a migliorare la situazione (qui un case study, in inglese, che potete scaricare).

Molto più spesso, purtroppo, ho assistito a battaglie politiche, di ego e desiderio di dominare che hanno ridotto le possibilità di migliorare la creazione di valore.

Perché cambiare?

Non perché lo dico io, può darsi che la mia esperienza non sia significativa.

Tuttavia, sembra che il rapporto del 2021 di Gallup, “State of the Global Workplace“, confermi le mie sensazioni.

L’impegno dei dipendenti al lavoro è globalmente sceso del 2%. È passato dal 22% nel 2019 al 20% nel 2020.

State of the Global Workplace - 2021 Report
State of the Global Workplace – Rapporto 2021

Effetto COVID? Può darsi, vedremo l’anno prossimo se la tendenza si invertirà.

La cosa che più spaventa, è la cifra a livello europeo (ovest) 11%, con un aspetto positivo però… nel 2020 abbiamo guadagnato 1% di impegno al lavoro rispetto al 2019! L’Europa occidentale è fanalino di coda di tutte le regioni mondiali.

Ancora più terrificante sono le cifre italiane… se l’Europa dell’ovest è ultima al mondo in termini di impegno dei dipendenti, l’Italia è ultima in Europa occidentale.

Solo 5%, 18ema posizione.

Interpreto queste cifre come un segnale che la leadership attuale non è adatta ai nostri tempi. Ciò ha ripercussioni pesanti, che non possono essere la “colpa” di dipendenti svogliati.

La maggior parte delle aziende con cui collaboro sono in difficoltà. O prevedono di esserlo a breve.

Fatturato in diminuzione, turnover, disimpegno dei dipendenti, penali per ritardi nei rilasci, scarsa qualità dei prodotti (con relativi costi).

Questo è un chiaro problema di leadership, dal mio punto di vista.

Per cosa cambiare?

Mi ricordo di un colloquio con un dirigente, che mi disse: “Fabio ho la convinzione che dobbiamo cambiare qualcosa. Così non si può più andare avanti. Ma non so per cosa cambiare!“.

Purtroppo la soluzione magica non esiste. L’esperienza ha mostrato che nuove tecnologie, nuovi processi, nuovo management, più burocrazia non migliorano i problemi identificati sopra.

Il problema non è tecnico, è umano. Viviamo in azienda, come al di fuori, un problema di valori e principi.

Fabio Panzavolta

Ecco perché le aziende che prosperano hanno leader che mettono l’umano al centro. Hanno capito che il cambiamento richiede tempo, lavoro e che non può essere in nessun caso delegato a consulenti o strumenti tecnici.

Si cambia paradigma, modo di pensare… col tempo, un pò alla volta!

group of people wearing shirts spelled team
Photo by RODNAE Productions on Pexels.com

Come cambiare?

Facile da dire, ma come cambiare? Con 5 cambiamenti nella vostra leadership!

I dirigenti devono essere i primi a capire quali cambiamenti nel loro modo di pensare, agire e prendere decisioni sono necessari quando si creano prodotti complessi.

Devono dare l’esempio, aiutare i dipendenti a capire a loro volta, ma vediamo quali sono questi 5 cambiamenti nella vostra leadership!

  • Valori – dimostrare che ogni decisione e comportamento sono basati prima di tutto sul rispetto dei valori Scrum. Questo è molto importante, in quanto nel risolvere problemi complessi abbiamo bisogno di un ambiente di lavoro nel quale la “Psychological Safety” è presente. Un ambiente di lavoro psicologicamente sicuro, permetterà ai dipendenti di sperimentare, eventualmente fallire, imparare in fretta e innovare.
  • Approccio descrittivo – al contrario dei classici approcci prescrittivi (metodologie), che si sono rivelati dannosi in certi mestieri come l’informatica, un approccio descrittivo (tipo Scrum) sono un’insieme di principi e regole da seguire per lavorare insieme. Un pò come il libretto delle regole del monopoli, o degli scacchi. Questo tipo di approccio, unito al precedente, permette alle persone di utilizzare la propria intelligenza e esperienza appieno, rendendoli molto più implicati nella risoluzione di problemi complessi.
  • Farne il meno possible – quante volte siamo stati congratulati perché abbiamo lavorato molto… ma quanto utili per l’utilizzatore del prodotto è stato il nostro lavoro? Un cambiamento importante nella vostra leadership consiste a realizzare poche funzionalità, ma a forte impatto per l’utente finale. Ciò implica che un prodotto non sia sviluppato a compartimenti stagni e parlando al cliente una volta l’anno. Stimolare una collaborazione continua fra i dipendenti e il cliente per far emergere la realtà del bisogno.
  • Pensare obiettivi – un leader sa dove va, ha obiettivi chiari ed è capace di comunicarli chiaramente. Quindi passare da una mentalità orientata ai task ad una orientata obiettivi è un cambiamento non banale e importantissimo. Se vogliamo delle persone implicate e motivate al lavoro, dobbiamo smettere di dire agli altri cosa fare e cominciare a spiegare perché devono farlo!
  • Controllare il prodotto – corollario a tutto quanto visto sopra, controllare le persone è facile, ma inefficace. Molto del disimpegno al lavoro viene da questo problema. Imparare a giudicare le performance del prodotto sul mercato è una leadership più consona ai nostri tempi. Sfidare il team ad avere un prodotto sempre migliore, in linea con gli obiettivi aziendali, è uno dei punti chiave per migliorare la vostra leadership!

Ovviamente i punti precedenti non sono un ordine preciso e neppure esaustivi.

Penso però che siano significativi e possano aiutare a valutare il lavoro che vi aspetta per adattare la vostra leadership ai tempi moderni.

Mi piacerebbe vedere, nel prossimo rapporto di Gallup, l’Italia almeno al penultimo posto!

Letture che potrebbero interessarti

Formazioni che potrebbero interessarti

Approccio empirico

Facilitazione

La facilitazione permette di guidare persone e team verso obiettivi concordati.

Traduzione dell’articolo originale in inglese sul sito scrum.org.

Facilitazione - Pillars of Empiricism
Pillars of Empiricism

Che cos’è la facilitazione?

La facilitazione può essere utilizzata per condurre le persone verso obiettivi concordati in modo da incoraggiare la partecipazione, l’appropriazione e la creatività di tutti i soggetti coinvolti. Una sessione ben facilitata può sbloccare l’intelligenza collettiva e svolgere un ruolo importante nel fornire opportunità di progresso e successo alle persone. Una buona facilitazione consente la trasparenza e la collaborazione, crea sinergie e porta al raggiungimento di un obiettivo collettivo.

Un facilitatore svolge un ruolo importante nell’aiutare le persone a comprendere e a raggiungere gli obiettivi condivisi. Lo fa rimanendo neutrale e imparziale. I facilitatori creano un ambiente partecipativo e propositivo in cui le persone si sentono sicure di impegnarsi, imparare e collaborare. Incoraggiano le persone a esplorare prospettive diverse, a sfruttare la diversità e a far leva sulla saggezza collettiva.

Principi di facilitazione

I Valori di Scrum sono il cuore di un Team Scrum professionale e lo guidano nel lavoro, nelle azioni e nel comportamento. I valori di Scrum sono complementari ai principi di facilitazione: partecipativo, sano, trasparente, processo e finalità. Il richiamo a questi principi fondamentali può aiutare i facilitatori a lavorare con i team per raggiungere gli obiettivi in modo collaborativo in diverse situazioni. Questi principi possono anche aiutare i facilitatori a decidere quali abilità e tecniche di facilitazione possono essere appropriate e utili. Questo vale non solo quando si crea un ambiente energico in cui tutto il team è impegnato e concentrato sul raggiungimento dell’obiettivo, ma anche quando le interazioni non vanno come previsto.

Partecipativo – Il fulcro di una facilitazione efficace è la piena partecipazione e l’impegno, che consente di condividere la responsabilità in un team.

Sano – Un ambiente sicuro significa creare uno spazio sano in cui le persone si sentano al sicuro nel sollevare differenze e persino prospettive contrastanti, imparando rispettosamente gli uni dagli altri.

Trasparente – La trasparenza esiste solo quando c’è una comprensione condivisa.

Processo – La facilitazione deve consentire a un team di progredire verso l’obiettivo desiderato dell’interazione in un modo che sia collaborativo, inclusivo e che faccia leva su prospettive diverse.

Finalità – Le sessioni ben gestite devono avere un obiettivo chiaro con il quale tutti sono allineati e per il quale lavorano.

Competenze e caratteristiche di un facilitatore

I facilitatori possono provenire da diversi contesti e avere diversi livelli di esperienza. I grandi facilitatori, tuttavia, dimostrano le seguenti abilità e caratteristiche:

Ascolto attivo: un facilitatore ha la capacità di ascoltare attivamente e di concentrarsi completamente su ciò che viene detto e su ciò che non viene detto. Dall’esempio, ispirando i partecipanti a esprimersi pienamente e ad impegnarsi nell’ascolto attivo quando gli altri parlano.

Incoraggiare la curiosità: un facilitatore incoraggia la curiosità e i diversi punti di vista. È abile nel porre “powerful questions”, spesso aperte, per stimolare la riflessione e la discussione.

Risolvere i problemi: un facilitatore è abile nell’applicare tecniche di problem solving di gruppo. Può aiutare il gruppo a definire un problema, a riformularlo in una chiara dichiarazione del problema e a incoraggiare il gruppo a considerare una serie di soluzioni al problema.

Risolvere i conflitti: un facilitatore riconosce che il conflitto tra i membri del gruppo è naturale e, purché espresso in modo appropriato, non deve essere soppresso. Il conflitto deve essere previsto e affrontato in modo costruttivo e rispettoso.

Utilizzo di uno stile partecipativo: un facilitatore incoraggia tutti i partecipanti a impegnarsi attivamente e a contribuire alle attività e alle discussioni, a seconda del loro livello di comfort individuale. Ciò comporta la creazione di un’atmosfera sicura e confortevole, in cui i membri del gruppo siano disposti a condividere i loro pensieri e le loro idee.

Incoraggiare l’apertura: il facilitatore incoraggia il gruppo ad aprirsi alle idee, ai suggerimenti e alle prospettive degli altri.

Empatia e compassione: il facilitatore è comprensivo, consapevole e rispettoso dei sentimenti, delle prospettive o delle azioni degli altri.

Dimostrare leadership: il facilitatore guida un gruppo di persone a raggiungere gli obiettivi collettivi.

Costruire il consenso: il facilitatore è abile nell’aiutare i gruppi a raggiungere un accordo generale.

Gestire il tempo in modo efficace: un facilitatore mantiene la rotta pur consentendo la flessibilità. Si concentra sul raggiungimento dei risultati in un arco di tempo piuttosto che su un’agenda rigida. Una gestione del tempo troppo restrittiva può soffocare conversazioni e riflessioni valide e mirate, mentre una mancanza di gestione del tempo può limitare la concentrazione e i progressi.

Definizione degli obiettivi: un facilitatore comunica lo scopo di una riunione in modo chiaro e conciso. Questo può avvenire definendo un obiettivo generale forte (spesso in collaborazione con il team) invece di concentrarsi su un ordine del giorno rigido.

Comunicare in modo adeguato: il facilitatore comunica in modo efficace, utilizzando un linguaggio chiaro e conciso.

Essere organizzato: la facilitazione non inizia o finisce con l’atto di facilitare un gruppo di persone. Comprende la preparazione e il follow-up delle decisioni prese.

Perché la facilitazione è utile ai team Scrum?

Una comunicazione aperta e rispettosa aiuterà uno Scrum Team a prosperare come team autogestito. Mentre i membri di un team Scrum dovrebbero parlarsi ogni volta che ne hanno bisogno, Scrum assicura punti di comunicazione per il team negli eventi Scrum. Ogni evento ha uno scopo specifico e il team trae vantaggio dall’avere questi eventi facilitati con il risultato desiderato in mente.

Qualsiasi persona del team Scrum può facilitare gli eventi Scrum. Ad esempio, lo Sprint Planning è più efficace ed esplorativo quando qualcuno del team, in qualità di facilitatore oggettivo, sa come inquadrare i problemi per capire in che modo gli elementi del Product Backlog possono essere utili per i clienti. Un Developer può essere la persona ideale per farlo, data la sua familiarità con il prodotto.

Spesso gli eventi Scrum non vanno come previsto. Una buona e leggera facilitazione può aiutare i team Scrum a rimettersi in carreggiata. Per esempio, se lo Scrum Master osserva che il team utilizza continuamente il Daily Scrum come uno status update (reporting al manager) invece che come un’ispezione dei progressi verso lo Sprint Goal, allora lo Scrum Master può aiutare i membri del team a concentrarsi ricordando loro lo scopo dell’evento. Questo incoraggerà i membri del team a spostare la loro attenzione dai task al modo in cui possono collaborare per raggiungere lo Sprint Goal.

Assumere un ruolo di facilitatore è prezioso anche per il Product Owner, soprattutto durante la Sprint Review, quando lo Scrum Team e gli stakeholder verificano i progressi verso il Product Goal, raccolgono il feedback degli stakeholder e adattano il Product Backlog di conseguenza. Se ben fatto, il Product Owner e i Developers possono imparare e ascoltare le diverse opinioni degli stakeholder. Se non lo si fa bene, il Product Owner rischia di ancorare o limitare le informazioni raccolte, riducendo l’efficacia della Sprint Review.

Per saperne di più sulle tecniche di facilitazione degli eventi Scrum

Imparare a facilitare prospettive diverse nei team Scrum

Esplora altri blog e risorse sulla facilitazione da Scrum.org

Altre risorse sulla facilitazione

Ecco altre risorse sulle tecniche di facilitazione e per aiutarvi a sviluppare l’abilità della facilitazione:

  • Associazione Internazionale dei Facilitatori – L’Associazione Internazionale dei Facilitatori (IAF) è un’organizzazione partecipativa internazionale che fornisce accreditamento, comunità e formazione sul potere della facilitazione.
  • The Grove – facilitazione e facilitazione grafica dal 1977
  • Digital Facilitation – il blog di Rachel Smith, eccellente prof di facilitazione grafica digitale
  • Liberating Structures – le Liberating Structures sono microstrutture che migliorano il coordinamento relazionale e favoriscono la partecipazione vivace nei gruppi, rendendo possibile l’inclusione di tutti.
  • Tasty Cupcakes – un sito web gestito dalla comunità con diversi giochi, tecniche e approcci per la facilitazione.
  • Training from the Back of the Room – Formazione basata sui principi della scienza del cervello
  • Bikablo – Visualizzare il dialogo e il pensiero
  • SeriousWork – Tecniche di facilitazione per l’apprendimento basato sulla pratica

Formazione professionale sulle competenze di facilitazione Scrum

Professional Scrum Facilitation Skills
Professional Scrum Facilitation Skills

In questo corso di formazione, i partecipanti impareranno a diventare migliori facilitatori per migliorare le interazioni nello Scrum Team, gli stakeholder e i clienti. Si concentreranno su come adottare la facilitazione come atteggiamento e come attivare i valori di Scrum. Gli studenti affronteranno una serie di scenari comuni legati a Scrum applicando diverse tecniche di facilitazione che potranno aggiungere alla loro collezione di pratiche agili. Creeranno e lasceranno il proprio “piano” di facilitazione per migliorare la prossima discussione di gruppo o il prossimo evento Scrum.

Community Collective Genius 🇮🇹

Community Collective Genius Italia

Leggendo questo articolo potrete farvi un’idea sulla Community Collective Genius Italia, creata per dare e ricevere aiuto sull’applicazione di Scrum al lavoro.

Community Collective Genius 🇮🇹
Community Collective Genius 🇮🇹

Perché esiste la Community Collective Genius Italia?

L’esperienza sul campo mi ha insegnato che applicare Scrum in azienda è una sfida. Appassionante, difficile, frustrante, entusiasmante, collaborativa, innovante… sono le prime parole che mi vengono in mente.

In certe situazioni, mi sono sentito solo. Mi sarebbe piaciuto avere dei colleghi con i quali discutere la mia situazione, confrontarmi, elaborare nuovi esperimenti insieme, condividere i miei successi, studiare insieme…

Ecco perché esiste la community, un luogo (riservato ai nostri ex-studenti) nel quale ci si ritrova per continuare ad imparare Scrum professionale, avere un muro del pianto 😊, ritrovare energia e senso nel lavoro quotidiano.

Home page della Community Collective Genius 🇮🇹
Home page della Community Collective Genius Italia

Un’altra ragione dell’esistenza della community è, spero, la qualità dei contenuti.

Avremmo potuto usare LinkedIn, ma l’esperienza mostra che i contenuti sono spesso creati per ottenere click.

Nella community garantiamo contenuto professionale, senza pubblicità, mirato a creare valore. Privilegiamo la qualità alla quantità.

Mighty Networks è la piattaforma che abbiamo scelto per supportare questa iniziativa.

Vediamo cosa siamo riusciti a fare insieme, dopo quasi un anno di esistenza!

Quanti siamo nella Community Collective Genius Italia?

Siamo 156 membri, ex-studenti, con crescita lenta ma costante 😊.

Membri della Community Collective Genius 🇮🇹
Membri della Community

Corsi di formazione

Una volta iscritto alla formazione, uno studente riceve l’invito a creare un account e accedere alla community.

Esempio di corso Professional Scrum Master nella Community Collective Genius 🇮🇹
Esempio di corso Professional Scrum Master

Il corso di formazione è attivato per lo studente e contiene le informazioni utili per prepararsi al corso e le informazioni logistiche.

È possibile cominciare ad interagire prima del corso, presentandosi, chiedendo supporto al vostro servitore, proponendo articoli o video da leggere e tanto altro!

Dopo la fine del corso, lo spazio formazione rimane accessibile ai partecipanti. In questo modo è possibile ritrovare i supporti e documenti scambiati durante la formazione, comunicare con le persone con le quali si è svolta la formazione, per esempio tramite chat.

Eventi della Community Collective Genius Italia

Gli eventi proposti agli ex-studenti hanno per obiettivo di continuare ad imparare Scrum professionale insieme.

In passato abbiamo proposto interviste a colleghi, workshop gratuiti ed altre iniziative. L’obiettivo è quello di sperimentare per capire ciò che ha più valore per aiutare ad applicare Scrum al lavoro.

Qualche esempio di eventi 👇🏻

Categorizzazione delle tematiche

È possibile accedere a diverse tematiche, usando i “topics”. Ciò permette di accedere a tutti i contenuti relativi a un argomento particolare.

Alcuni topics disponibili sulla Community Collective Genius 🇮🇹
Alcuni topics disponibili sulla Community Collective Genius Italia

Domande / Offerte di lavoro

Una cosa che è emersa durante il primo anno di esistenza della community è l’opportunità di mettere in contatto ex-studenti che assumono ed altri che cercano lavoro.

Ci limitiamo a mettere in contatto le persone, non abbiamo nessun interesse nel farlo se non connettere professionisti di Scrum.

Offerte di lavoro per Scrum Professionale sulla Community Collective Genius 🇮🇹
Offerte di lavoro per Scrum Professionale sulla Community Collective Genius Italia

Il vantaggio per le aziende che assumono è quello di avere persone già formate e motivate per applicare Scrum al lavoro.

Per i candidati il valore aggiunto è quello di trovare aziende motivate ad applicare Scrum come l’abbiamo visto in formazione.

Conclusioni

Dopo un anno di esistenza e diversi esperimenti, abbiamo dimostrato insieme che la community ha valore.

Come fare per migliorarsi? Bè, lo sapete bene, grazie al feedback 😊… allora la vostra community vi ascolta, lasciate un commento o contattateci per suggerire miglioramenti o tematiche che vi piacerebbe discutere!

Scrum on 💪

Queste formazioni potrebbero interessarvi

Intervista PST

Intervista sul mio percorso da PST

Intervista PST

Riporto l’intervista sul mio percorso da PST che mi ha fatto Dave West qualche tempo fa (in inglese).

Se conoscete Scrum.org, potreste associare l’organizzazione a Professional Scrum e/o ai corsi di formazione e alle certificazioni Professional Scrum.

Dietro a questi corsi di formazione pratici ci sono Professional Scrum Trainers (PST) altamente qualificati, che seguono un processo rigoroso per prendere la loro esperienza Scrum nel mondo reale e creare valore per gli studenti di Scrum.org.

In diversi episodi del Podcast della community di Scrum.org, il CEO di Scrum.org, Dave West, intervista i Professional Scrum Trainers sulle loro esperienze che li hanno portati a diventare PST e ad esplorare il significato di Professional Scrum per loro.

In questo episodio, riporto l’intervista sul mio percorso da PST nel quale Dave mi ha fatto domande sulla mia esperienza.

Articolo originale pubblicato sul sito scrum.org

Previsioni

Stime probabilistiche

Quando si cerca di prevedere il futuro, si è raramente nel giusto. Le stime probabilistiche aiutano a migliorare le previsioni di uno Scrum Team.

Previsioni
Foto di Brian McGowan su unsplash.com

Questo articolo da per scontato che il lettore conosce e pratica già Scrum, i concetti di velocità, story points e le problematiche legate alle stime.

Questa è la trascrizione (ndr. adattata da Fabio Panzavolta) dell’intervista di Michael Forni, nella quale ha condiviso la sua esperienza nell’uso di stime probabilistiche ed i vantaggi che ha potuto osservare. Grazie Michael!

Stimare e quantificare il lavoro da fare durante uno Sprint non è cosa facile. Cosa e come rispondere alla domanda del Product Owner: “quando sarà pronto?”.

Adottare stime probabilistiche, più efficaci delle classiche stime deterministiche basate su story points, può essere una soluzione.

Contesto

Il team che Michael ha aiutato, aveva raggiunto un livello di coesione, collaborazione e affidabilità nelle stime che li ha portati a voler andare oltre.

Questo è naturale perché Scrum è un framework che ci permette di adattarci in permanenza ai cambiamenti e diventare sempre migliori.

Se oggi il vostro team non è ancora capace di fare stime deterministiche, basate su story points e velocità, probabilmente allora non sarà ancora pronto per le stime probabilistiche.

Un consiglio: aiutate il team a maturare, facendo in modo di dare il gusto di migliorarsi continuamente e supportatelo nel viaggio unico che stanno intraprendendo, con pazienza e assiduità.

A quale problema si cerca di rispondere

Il Product Owner non trovava più soddisfacente, anche a livello personale, rispondere alla domanda: “ma il lavoro quando sarà pronto?”.

Usando il metodo tradizionale, con story point e velocità, se abbiamo 150 story points di lavoro e sappiamo che più o meno siamo in grado di fare 50 story points a Sprint, in tre Sprint avremo finito.

Questo però non ci aiuta a sapere quando una specifica “storia” sarà pronta oppure, in caso di cambiamento nell’ordine del Product Backlog, quando saranno pronti gli item che ora hanno più valore?

In questo caso la velocità e gli story points non sono così efficaci per rispondere a questa domanda.

Le stime probabilistiche, contrariamente a quelle deterministiche, indicheranno l’affidabilità dell’informazione che forniamo, indicando la probabilità di successo.

Professional Scrum With kanban

Questi concetti fanno parte di Kanban, che ci viene in aiuto e può essere un buon complemento a Scrum.

Kanban è un insieme di pratiche, abitudini e strumenti che aiutano a migliorare il flusso di lavoro e a rilasciare valore più rapidamente.

Per capire come utilizzare Scrum e Kanban insieme, Scrum.org propone il corso Professional Scrum With Kanban.

Esiste una guida, Kanban Guide for Scrum Teams, che può essere un buon complemento a questo articolo.

Michael ha seguito questa formazione che ha trovato utile per capire che Scrum con Kanban è ancora 100% Scrum ed ha ancora più valore.

Cycle Time

Il Cycle Time è una metrica probabilistica che si calcola misurando quando (con data tipicamente) un oggetto (ndr Product Backlog Item) entra nel sistema (ndr. Sprint) ed il giorno in cui esce. Usando la definizione di Ready e la definizione di Done per decidere cosa entra e cosa esce.

Questa metrica si calcola in giorni e corrisponde al “Cycle Time”. Questo è il calcolo che si è cominciato a fare nel team aiutato da Michael.

Item Age (éta)

Per vedere quanto manca a destinazione usiamo un’altra metrica di Kanban: l'”età dell’item”, o semplicemente “età”, che ci dice quanto sta invecchiando il nostro item nella Scrum board.

La Guida Kanban per Scrum Team - stime probabilistiche

Più l’età aumenta, più è probabile che ci sia un problema, un ostacolo o comunque una situazione da analizzare e capire.

L’item esce dal sistema dopo un certo numero di giorni rivelando quello che è il cycle time: 3, 5, x giorni.

La prima indicazione è che quando un item ha un cycle time più lungo di uno Sprint vuol dire che non è abbastanza piccolo e il team cerca una soluzione a questo problema.

Lead Time

A differenza del cycle time, il Lead Time Corrisponde al tempo trascorso da quando l’item è entrato nel Product Backlog a quando è in produzione e gli utenti ne traggono effettivo beneficio.

Il lead time è un tempo superiore al cycle time.

Lead & Cycle Time
Lead & Cycle Time

Throughput (portata)

Un altra metrica Kanban, lo Throughput (portata), è utile per le stime probabilistiche e corrisponde al numero di item che hanno “attraversato il sistema” in un certo periodo di tempo.

Questa metrica è ciò che ci permette di abbandonare gli story points, a condizione di essere capaci di avere Product Backlog Items di dimensioni simili.

È una delle ragioni per le quali lo Scrum Team deve essere abbastanza maturo per aver capito e saper lavorare su Product Backlog Items di piccole dimensioni.

Carte Planning Poker - stime deterministiche
Carte Planning Poker

Si può arrivare a questo risultato passo dopo passo, per esempio continuando ad utilizzare il Planning Poker per stimare gli story points di un Product Backlog Item sfidandosi, durante il Product Backlog Refinement, ad ottenere items piccoli ed il più possibile della stessa dimensione.

Senza cambiare le abitudini dello Scrum Team, il focus può passare dagli story points alla quantità di Product Backlog Items che sono state terminate alla fine dello Sprint.

Michael Forni

Quindi si possono continuare ad usare Story Points e velocità, che piano piano perderanno importanza, sostituendoli con il numero di items e la loro probabilità di essere effettivamente terminati alla fine dello Sprint sulla base dei throughput precedenti.

Allora, per esempio, il Product Owner potrà affermare con gli Stakeholder che, per la fine dello Sprint, 7 items saranno terminati con una probabilità del 90%; 10 items con una probabilità del 70%, ecc.

Questo aiuta molto il Product Owner professionista a gestire le aspettative con gli Stakeholder, perché non si attiva più il conflitto basato sulle sensazioni, in quanto si utilizzano dati probabilistici per le previsioni tanto più affidabili quanto il sistema è performante nel suo insieme.

Vantaggi di stime probabilistiche

Uno dei vantaggi delle stime probabilistiche, contrariamente a quelle deterministiche, consiste ad essere capaci di fare previsioni future anche su ipotesi di contenuto di Product Backlog. Quando finiremo se abbiamo un Product Backlog con 100 items?

Ovviamente fermo restando che nello sviluppo di un prodotto complesso l’imprevisto è sempre dietro l’angolo e potrebbe cambiare le nostre previsioni.

Più il livello di conoscenza e di padronanza del prodotto e del business saranno grandi, più precisi saranno le previsioni.

Quello che si è capaci di affermare è, per esempio: “con un livello di 85% di probabilità/certezza, sappiamo che un Product Backlog Item che entra nel sistema oggi ne uscirà in 6 giorni o meno”.

Possiamo affermare quando sopra perché questo Scrum Team è in grado di garantire questo livello di output probabilistico.

Conclusione

Studi interessanti di Vasco Duarte, dimostrano che, confrontando uno Scrum Team che per dieci Sprint ha fatto stime deterministiche con story points e velocity con uno che ha utilizzato lo throughput, la capacità di prevedere il futuro è invariata o addirittura migliorata grazie alle stime probabilistiche.

Se il vostro team ha dimostrato, con dati alla mano, di essere capaci di valutare la complessità del lavoro dopo aver ridotto le storie alla dimensione minime possibile, allora è probabile (non certo ovviamente) che possano cominciare a contare le storie perché non c’è più bisogno di considerarle con una stima comparativa.

Ciò permette anche di apprezzare la “potenza” di uno Scrum Team professionale, non solo in termini di capacità a creare valore, ma anche di prevedere in modo probabilistico il futuro.

Per approfondire le stime probabilistiche

Qui di seguito trovate i riferimenti utili per approfondire questi argomenti:

Volete proporre il tema del prossimo podcast, contattateci!

Perché Scrum non è una metodologia?

Spesso in formazione si discutono le differenze fra metodologia e framework. In questo articolo troverete la risposta alla domanda: “Perché Scrum non è una metodologia?”

Una metodologia di lavoro consiste ad applicare sempre lo stesso processo, con gli stessi input e output, per realizzare il lavoro. L’obiettivo è di ridurre i rischi e rendere il risultato del lavoro prevedibile.

L’apparizione delle metodologie di lavoro risale al periodo della rivoluzione industriale, l’esempio classico è la catena di montaggio che è pensata per assemblare diversi componenti il più rapidamente possibile ed ottenere come risultato finale il prodotto voluto. Una metodologia ottimizza l’output che si vuole creare, il risultato finale è conosciuto in anticipo.

Con l’avvento di nuovi mestieri, come l’informatica, profondamente differenti dal concetto di una catena di montaggio, si è applicato ciò che si conosceva, trascurando il fatto che la soluzione ad un problema non era conosciuta in anticipo. Ciò ha creato tensioni e problemi di vario tipo fra i lavoratori e il management.

Una metodologia è utile per risolvere un problema semplice, è un’approccio predittivo che presuppone la conoscenza anticipata dello stato finale che si vuole raggiungere.

Fabio Panzavolta

l’evoluzione del pensiero

Nel 1990 alcuni professionisti del mondo dell’informatica, fra i quali Ken Schwaber e Jeff Sutherland (creatori di Scrum) hanno capito che i ritardi, la scarsa qualità e le inefficienze nella creazione di software non erano dovute alle persone che non lavoravano abbastanza duramente, o che non applicavano correttamente la metodologia, bensì al paradigma adottato.

Prima con Extreme Programming poi con Scrum, le cose hanno cominciato a cambiare. L’accettazione del fatto che non si può prevedere in anticipo tutto il lavoro necessario alla creazione di un prodotto complesso ha lasciato lo spazio ad un cambiamento di paradigma.

L’empirismo a preso il posto del determinismo. Un processo empirico basa tutte le decisioni future sull’esperienza passata: la soluzione ad un problema, la creazione di un prodotto o servizio emergono dal feedback ricevuto dall’utilizzatore.

Ken Schwaber, co-creatore di Scrum, in questo articolo descrive le organizzazioni moderne prendendo come metafora il film “La tempesta perfetta” dove una serie di circostanze sfortunate e concomitanti creano una situazione praticamente incontrollabile per l’equipaggio del peschereccio. È evidente come, in questo contesto, nessun tipo di metodologia potrà aiutare l’equipaggio a sopravvivere. Al contrario, la sperimentazione di diverse manovre è necessaria per capire come la barca reagisce e trovare la via d’uscita.

LONDON, ENGLAND – MARCH 09: Federico Ruzza of Italy is tackled by Jamie George of England during the Guinness Six Nations match between England and Italy at Twickenham Stadium on March 09, 2019 in London, England. (Photo by Michael Steele/Getty Images)

Ecco perché Scrum non è una metodologia! Spesso descriviamo Scrum come un gioco di società, oppure come il Rugby, con le proprie regole, principi e valori. Se si vuole giocare a Scrum, bisogna avere il coraggio di affrontare l’incertezza e sperimentare diverse soluzioni fino a trovare quella più adatta al momento.

Scrum permette di navigare l’incertezza, esplorando diverse soluzioni adattative per risolvere problemi complessi.

Fabio Panzavolta

Conclusione

Perché Scrum non è una metodologia? Perché Scrum lascia le persone libere di prendere decisioni per adattarsi a qualsiasi situazione e seguendo poche regole semplici. Basti pensare che lo Scrum Guide in inglese è un libretto di 13 pagine!

Nella tabella qui sotto riassumo alcune differenze fra una metodologia ed un framework, con l’obiettivo di comprenderne la differenze ed aiutare nella scelta migliore per il problema che dovete risolvere.

MetodologiaFramework
Un processo predefinito e ripetitivo, con gli stessi step, input e output da applicare meccanicamenteDelle regole, principi e valori da seguire per creare un processo empirico adatto al problema da risolvere
DeterministicoEmpirico
La soluzione è immaginata all’inizioLa soluzione emerge grazie al feedback degli utilizzatori
Utile quando è tutto sotto controllo, pochi cambiamenti e si ha una conoscenza estesa del lavoroUtile in contesti complessi, con molti cambiamenti e incertezza sulla soluzione da fornire per un problema dato
Le persone seguono le istruzioni, poca comunicazione, divisione e specializzazione del lavoroLe persone seguono le stesse regole, principi e valori. Comunicano e collaborano nella ricerca della soluzione attraverso la sperimentazione.
Ottimizza l’efficaciaOttimizza la resilienza
Differenze fra metodologia e framework
Le Basi di Scrum - Elementi associati a Scrum

12 – Elementi associati a Scrum

Gli elementi associati a Scrum sono strumenti, pratiche e più in generale “tattiche di gioco”, che non sono obbligatorie in Scrum e che si sono rivelate utili nel tempo.

Tuttavia, in un contesto di complessità e imprevedibilità, non è automatico che questi elementi associati a Scrum vi siano utili.

Suggeriamo di sperimentarli e, eventualmente, adattarli al proprio contesto in maniera empirica.

Gli elementi associati a Scrum non dovrebbero essere imposti ad uno Scrum Team, eccone un elenco non esaustivo.

  • Product Backlog Refinement: si tratta di un’attività ricorrente, durante la quale lo Scrum Team aggiunge dettaglio agli elementi del Product Backlog. Questa attività è molto utile quando diversi Scrum Team lavorano insieme per creare un prodotto o servizio. La durata e la frequenza di questa sessione di lavoro è definita dallo Scrum Team.
Esempio di Burndown chart
Esempio di Burndown chart
  • Burndown chart: un modo per rappresentare visivamente il lavoro svolto e ancora da fare. Può essere applicato sia al Product Backlog che allo Sprint Backlog. Fornisce trasparenza sullo stato di raggiungimento dello Sprint Goal. Spesso assume la forma di un grafico che mostra sull’asse verticale la quantità di lavoro e sull’asse
Carte Poker Planning
Carte Poker Planning
  • Poker Planning: tecnica per stimare la complessità del lavoro da svolgere. Un gioco divertente che permette ai Developers di allinearsi su un determinato argomento e comprenderne la complessità. Planning Poker si basa sulla sequenza di Fibonacci, presentata sotto forma di carte da gioco (un esempio delle carte Collective Genius fornite ai partecipanti durante una formazione). Ciascun partecipante, una volta discussa l’elemento del Product Backlog, sceglie una carta corrispondente al livello di complessità di realizzazione che percepisce (0 poco complesso, 55 molto complesso). I Developers girano le proprie carte contemporaneamente, rivelando così la propria percezione della complessità, senza esserne influenzati. Potrebbero esserci differenze nelle stime, nel qual caso gli estremi motivano la loro scelta e, dopo aver discusso le differenze i partecipanti rivotano. Alla fine otterremo una stima dei Developers, non di una singola persona.
  • Business Model Canvas: è un modo per creare un business case agile in modo collaborativo e guidato. Usiamo questo Canvas nei nostri corsi di formazione Professional Scrum Product Owner per esplorare le diverse strategie business riconducibili alla visione aziendale.

E tu, quali altri elementi associ a Scrum?

Le Basi di Scrum - Elementi associati a Scrum
Le Basi di Scrum – Elementi associati a Scrum

Scarica e stampa (in A4 o A3) il poster relativo a questo articolo, può essere utile per te in ufficio, i codici QR consentono di approfondire la conoscenza del framework Scrum!

Questo articolo fa parte di una serie di dodici pubblicazioni, ognuna delle quali spiega le basi di Scrum, secondo lo Scrum Guide.  Potrebbe essere utile per te come presentazione alla direzione o per chiunque sia curioso di approfondire l’argomento.

Tradotto dal francese da Denise Monreale, grazie!

Le Basi di Scrum - Artefatti Scrum: Increment

11 – Artefatti Scrum: Increment

Incremento Scrum
Clicca l’immagine per ascoltare l’episodio del Podcast

Un Increment è un primo passo concreto verso il Product Goal ed è l’ultima versione del prodotto. È utilizzabile e potenzialmente pubblicabile in produzione.

Un Increment fornisce valore agli utilizzatori del prodotto.

Durante uno Sprint è possibile creare più Incrementi e potenzialmente rilasciarli durante lo Sprint, la somma degli incrementi viene ispezionata durante la Sprint Review. Il lavoro può essere considerato parte di un incremento solo se soddisfa la definizione di Done.

Le Basi di Scrum - Artefatti Scrum: Increment
Le Basi di Scrum – Artefatti Scrum: Increment

Commitment: Definizione di Done

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

La definizione di Done crea trasparenza consentendo a tutti di comprendere il lavoro svolto nel contesto dell’Increment.

Se la definizione di fatto fa parte degli standard dell’organizzazione, tutti gli Scrum Team devono seguirla, eventualmente arricchendola. In caso contrario, lo Scrum Team deve creare una definizione appropriata di Done per il prodotto.

I Developers sono tenuti a rispettare la definizione di Done. Se più team Scrum lavorano insieme su un prodotto, devono definire una definizione di Done unica che prenda in considerazione le problematiche di integrazione.

Scarica e stampa (in A4 o A3) il poster relativo a questo articolo, può essere utile per te in ufficio, i codici QR consentono di approfondire gli argomenti proposti!

Questo articolo fa parte di una serie di dodici pubblicazioni, ognuna delle quali spiega le basi di Scrum, secondo lo Scrum Guide.  Potrebbe essere utile per te come presentazione alla direzione o per chiunque sia curioso di approfondire l’argomento.

Tradotto dal francese da Denise Monreale, grazie!

Le Basi di Scrum - Artefatti Scrum: Sprint Backlog

10 – Artefatti Scrum: Sprint Backlog

Lo Sprint Backlog è un artefatto costituito dallo Sprint Goal  (perché fare lo Sprint?), da tutti gli elementi del Product Backlog scelto per lo Sprint (cosa fare in questo Sprint?), nonché da un piano d’azione per la realizzazione dell’Incremento (come fare a creare valore in questo Sprint?).

Lo Sprint Backlog è un piano sviluppato dalle persone che faranno il lavoro, i Developers. Fornisce informazioni trasparenti, in ogni momento, sul lavoro svolto e ancora da fare per raggiungere lo Sprint Goal.

Pianificazione Sprint in Scrum
Clicca l’immagine per ascoltare il Podcast

Di conseguenza, lo Sprint Backlog viene aggiornato durante lo Sprint in base a ciò che lo Scrum Team impara.

Lo Sprint Backlog è un artefatto che viene creato durante lo Sprint Planning. Il suo contenuto tecnico, definito dai Developers, emerge durante lo Sprint grazie all’esperienza e alle nuove informazioni acquisite. L’emergere di nuove informazioni può avere un impatto sulle previsioni iniziali fatte dai Developers, che si impegnano a realizzare lo Sprint Goal.  Si accetterà che la quantità di lavoro sia più o meno importante secondo gli Sprint perché in un mondo complesso e imprevedibile, le informazioni e le contingenze non sono mai congelate e conosciute in anticipo.

Le Basi di Scrum - Artefatti Scrum: Sprint Backlog
Le Basi di Scrum – Artefatti Scrum: Sprint Backlog

ENGAGEMENT: Sprint Goal

Lo Sprint Goal è l’unico obiettivo dello Sprint. Offre una certa flessibilità in termini di lavoro necessario per raggiungere questo obiettivo.

Lo Sprint Goal viene creato durante lo Sprint Planning e visibile nello Sprint Backlog, è immutabile per tutta la durata dello Sprint.

Se, a seguito dell’emergere di nuove informazioni, il contenuto dello Sprint deve essere modificato, gli sviluppatori lavorano con Product Owner per modificare il perimetro dello Sprint Backlog senza che questo modifichi lo Sprint Goal.

Nella tabella qui sotto ho riportato due esempi di Sprint Goal, abbastanza frequenti sul lato non accettabile

Sprint Goal AccettabileSprint Goal non accettabile
Essere in grado di autenticarsi sul sito WebCorreggere l’anomalia #34, #356-implementare l’accesso con Google – Se c’è tempo per correggere l’anomalia #234 (troppo dettagliato e rigido, lo Sprint Goal corrisponde a una quantità di lavoro da fare)
Mostrare i migliori prodotti nella home pageMostrare i nostri migliori prodotti e fare in modo che la campagna marketing XY possa partire in tempo (due Sprint Goal distinti invece di uno unico)
Esempi di Sprint Goal

Scarica e stampa (in A4 o A3) il poster relativo a questo articolo, può essere utile per te in ufficio, i codici QR consentono di approfondire gli argomenti proposti!

Questo articolo fa parte di una serie di dodici pubblicazioni, ognuna delle quali spiega le basi di Scrum, secondo lo Scrum Guide.  Potrebbe essere utile per te come presentazione alla direzione o per chiunque sia curioso di approfondire l’argomento.

Tradotto dal francese da Denise Monreale, grazie!

Le Basi di Scrum - Artefatti Scrum: il Product Backlog

9 – Artefatti scrum: il Product Backlog

Il Product Backlog è un elenco ordinato e evolutivo di tutto il lavoro ritenuto necessario dal Product Owner per creare, pubblicare, mantenere e migliorare un prodotto.

artefatti Scrum e loro impegni
Clicca l’immagine per ascoltare l’episodio del Podcast

Ogni prodotto ha un solo Product Backlog, è in continua evoluzione grazie al feedback constante degli stakeholder e alle Sprint Review, gestito da un solo Product Owner.  

Per rendere trasparente il Product Backlog, il Product Owner garantirà, tra le altre cose:

  • Un ordine e una priorità nel contenuto: in modo tale da rispecchiare la sua visione
  • Accessibilità al contenuto a tutto lo Scrum Team (e alle persone che lo richiedono in azienda)
  • La comprensione condivisa del suo contenuto. Spesso, ad esempio, ogni elemento del Product Backlog avrà le seguenti informazioni: un titolo, una descrizione, criteri di accettazione, un valore aziendale, una stima della complessità.
Le Basi di Scrum - Artefatti Scrum: il Product Backlog
Le Basi di Scrum – Artefatti Scrum: il Product Backlog

commitment: PRODUCT GOAL

Il Product Goal descrive uno stato futuro del prodotto che può servire come destinazione per lo Scrum Team durante la pianificazione. Il Product Goal è visibile nel Product Backlog, è un obiettivo a lungo termine dello Scrum Team. Esiste un solo Product Goal in Scrum. Una volta raggiunto questo obiettivo ne verrà creato uno nuovo.

Gestione del Product Backlog: Guida per Scrum Team
Clicca l’immagine per ascoltare l’episodio del Podcast

ADATTAMENTO DEL PRODUCT BACKLOG

Questo è fondamentale per massimizzare il valore del prodotto, ma cos’è esattamente questo adattamento?

  • Ridare un ordine e una priorità ai contenuti, a seguito del feedback degli stakeholder in Sprint Review e di continuo
  • Aggiunta di nuove idee
  • Rimozione di idee obsolete che non si adattano più al Product Goal (e quindi non hanno più valore)
  • Qualsiasi altra azione che renda il Product Backlog ordinato correttamente

IL VALORE È L’UNICO CRITERIO PER ORDINARE IL BACKLOG DEL PRODOTTO?

No. In effetti, il valore è un concetto soggettivo. Il Product Owner ordina il Product Backlog interagendo con gli Stakeholder. Altri parametri da considerare per ordinare il Product Backlog sono:

  • Valore aziendale: il problema più urgente per gli utenti, un vincolo normativo, una funzionalità che nessun concorrente possiede, ecc.
  • Il rischio: in Scrum il rischio non viene gestito, viene trattato per primo. Ciò ha un impatto sulla pianificazione
  • La dimensione degli elementi del Product Backlog: gli elementi importanti e di valore superiore avranno una dimensione giudicata dai Developers realizzabile in uno Sprint

In nessun caso l’ordine è dettato dalla difficoltà di realizzazione. Il Product Owner tiene conto dell’opinione dei Developers, senza concentrarsi prima sul “facile da fare”, perché questo non corrisponde a massimizzare il valore.

QUALE LIVELLO DI DETTAGLIO DOVREBBE AVERE UN ELEMENTO DEL Product BACKLOG

Un livello sufficiente per consentire a tutti di comprendere e ricordare l’argomento da discutere, quando sarà il momento.

Agile Estimating and Planning
Lettura consigliata: Agile Estimating and Planning

Ricorda uno dei quattro principi del Manifesto Agile: “gli individui e le interazioni più che i processi e gli strumenti”. Un elemento del Product Backlog, inizialmente, serve per contrassegnare l’idea non appena arriva e poi svilupparla quando diventa una “priorità”.

Non c’è bisogno di passare ore a scrivere specifiche dettagliate, in quanto si tratterebbe di una perdita di tempo ed energia che potrebbe essere dedicata ad argomenti di immediato valore per gli utenti.

L’attenzione si concentrerà sulla cooperazione di tutte le persone pertinenti sull’argomento al momento opportuno.

Vuoi andare oltre nella stima e nella pianificazione Agile? Il libro di Mike Cohn “Agile Estimating and Planning” è un buon inizio.

Scarica e stampa (in A4 o A3) il poster relativo a questo articolo, può essere utile per te in ufficio, i codici QR consentono di approfondire gli argomenti proposti!

Questo articolo fa parte di una serie di dodici pubblicazioni, ognuna delle quali spiega le basi di Scrum, secondo lo Scrum Guide.  Potrebbe essere utile per te come presentazione alla direzione o per chiunque sia curioso di approfondire l’argomento.

Tradotto dal francese da Denise Monreale, grazie!