Blog

Innovare, il Servant Manager

Servant Manager e innovazione

Aggiornamento 10 luglio 2023

Il servant manager è una delle chiavi per stimolare l’innovazione in azienda. In questo articolo concentro le risorse che ti permetteranno di esplorare questo argomento.

Discutendo con dirigenti di società di qualsiasi dimensione, i problemi ricorrenti che espongono sono: qualità scarsa dei nostri prodotti, lentezza nel mettere in produzione nuovi prodotti, difficoltà a trattenere o attirare talenti, clienti insoddisfatti. Questi sono i sintomi di un’azienda che adotta una leadership che funzionava mezzo secolo fa.
Quando si parla di innovazione spesso il focus è fatto su nuove tecnologie, ma la vera prima innovazione consiste ad adottare una leadership che sia adatta all’epoca in cui viviamo, costituita da incertezze e cambiamenti rapidi.

Immagine riassunto della della sessione live

1 – Il problema

Secondo lo “State of the Global Workplace 2021 Report” di Gallup, solo il 5% delle persone in Italia sono “engaged” al lavoro.

Un vero problema quando si devono risolvere problemi complessi.

2 – Le conseguenze

Osservabili facilmente in qualsiasi azienda, in maniera più o meno evidente:

  • Personale infelice
  • Competitività aziendale in diminuzione
  • Burn-out
  • Turnover
  • ecc.

Il controllo eccessivo delle persone, la burocrazia ed i processi che si usano per limitare i rischi, scatenano i sintomi osservati sopra. Purtroppo la soluzione usata in molte aziende, quando le cose vanno male, consiste nell’incrementare burocrazia e processi. Questo nel tentativo di correggere la situazione.

Purtroppo si ottiene l’effetto contrario.

3 – Capire il contesto

Questa mancanza di impegno al lavoro può essere spiegata dal fatto che il management non si è ancora perfettamente adattato alla gestione di problemi complessi.

Per prima cosa, quindi, è necessario farsi le domande giuste, cioè capire se il contesto nel quale operiamo è ancora del tipo “industriale”, con processi di sviluppo lineari e predittivi. In questo caso procedure e processi per controllare il risultato del lavoro sono la buona soluzione.

Ma se il contesto è di tipo complesso, allora il management come l’abbiamo imparato all’università (ed il modo di pensare) non sono più adatti in quanto in questo tipo di situazioni il pensiero e la risoluzione dei problemi non sono più lineari e prevedibili. In questo caso, è necessario ridurre (eliminare il più possibile) burocrazia e procedure, liberare le persone e concentrarsi su obiettivi chiari e misurabili. Questa è la logica post-industriale, dove l’obiettivo è creare valore in modo creativo e innovante.

Nel video qui sotto sviluppo questo concetto.

4 – Adattare il proprio stile di management

Se si vuole più impegno al lavoro, da parte di tutti, allora è necessario capire cosa vuol dire mettersi al servizio degli altri, ovvero come diventare un buon servant leader.

In un contesto di complessità il management è sostituito dalla leadership.

Management tradizionaleServant Manager
Focus sulle personeFocus sul sistema (vincoli, regole semplici non imposte)
Impone soluzioniFa domande, le risposte e le soluzioni arrivano dalle persone che fanno il lavoro
Orientato ai task (cosa e come fare) Orientato obiettivi (perché fare)
Focalizzato sulle performance della personaFocalizzato sul risultato del team (utilizzatori contenti?)
Confronto fra management tradizionale e servant manager

Tanti altri esempi sono possibili, questi sono i primi che mi sono venuti in mente. L’importante è capire che le caratteristiche di un servant manager sono quelle di venire in supporto alle persone che fanno il lavoro per assecondarle e supportarle nelle loro decisioni.

Per sapere se le decisioni sono giuste o sbagliate, bisognerà concentrarsi sugli utenti del prodotto, andare in produzione il più spesso possibile per ottenere feedback e migliorarsi continuamente.

Per saperne di più, esplora il contenuto qui sotto per saperne di più sul Servant Manager! Esplora come, facendo evolvere il nostro modo di essere, stimoliamo l’innovazione, rendiamo i nostri prodotti migliori e i clienti più contenti.

Il servant manager
Cynefin, Scrum e Agile
Cynefin, Scrum e Agile
The Servant as a Leader
The Servant as a Leader
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.

Gestione del Product Backlog: Guida per Scrum Team

Gestione del Product Backlog: guida per Scrum Team [E17]

ℹ️ Gestione del Product Backlog 📅 Data: 18/04/2023 ⏱ Durata: 19 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 Product Backlog, uno degli artefatti di Scrum che rappresenta l’unica fonte di lavoro per lo Scrum Team. Scopriremo come questo “living artifact” evolve nel tempo e come contribuisce al successo del prodotto attraverso una gestione efficace e collaborativa.

🎧 Ascolta l’Episodio

🎯 Cos’è il Product Backlog

Il Product Backlog è un elenco emergente e ordinato di tutto ciò che è necessario per migliorare il prodotto. Rappresenta:

  • L’unica fonte di lavoro per lo Scrum Team
  • Un documento vivente che evolve con il prodotto
  • Il punto di riferimento per qualsiasi modifica o miglioramento

🔄 Caratteristiche Principali

Elementi Ready

  • Gli elementi nella parte alta del Product Backlog sono considerati “Ready”
  • Sufficientemente dettagliati per essere selezionati nello Sprint Planning
  • Raggiungono la trasparenza necessaria dopo il Refinement

Product Backlog Refinement

  • Attività continuativa di scomposizione degli elementi
  • Il Product Backlog refinement aggiunge dettagli come descrizione, ordine e dimensione
  • Collaborazione tra Product Owner e Developers
  • Stime effettuate esclusivamente dai Developers

💡 Product Goal

  • Descrive uno stato futuro del prodotto
  • Serve come obiettivo a lungo termine per lo Scrum Team
  • Deve essere raggiunto o abbandonato prima di definirne uno nuovo
  • È visibile nel Product Backlog

⚙️ Best Practices

Gestione Product Backlog

  • Elementi più piccoli e atomici possibile
  • Trasparenza nel movimento delle attività
  • Gestione efficace attraverso la collaborazione continua
  • Visibilità degli impegni del team

Responsabilità e Ruoli

  • Lo Scrum Product Owner gestisce il Product Backlog
  • Developers stimano la dimensione degli elementi
  • Tutto lo Scrum Team partecipa al Refinement
  • Product Owner definisce il Product Goal

Responsabilità e Ruoli

  • Product Owner gestisce il Product Backlog
  • Developers stimano la dimensione degli elementi
  • Tutto lo Scrum Team partecipa al Refinement
  • Product Owner definisce il Product Goal

📚 Approfondimenti Consigliati

  • La Scrum Guide: Product Backlog e Product Goal
  • Tecniche di Refinement efficace
  • Gestione degli elementi del Product Backlog
  • Pattern di collaborazione nel Refinement

🎓 Note del Trainer

“Il Product Backlog non è una semplice lista di requisiti, ma un artefatto vivente che riflette l’evoluzione del prodotto e le necessità degli stakeholder. La chiave del successo sta nella sua gestione dinamica e nella collaborazione continua tra Product Owner e Developers.”

🔜 Prossimo Episodio

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

Questo articolo è basato sull’episodio 17 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.

Sprint Retrospective Scrum: facilitazione e miglioramento continuo del team agile

Sprint Retrospective Scrum: guida Al Miglioramento [E15]

ℹ️ Sprint Retrospective Scrum 📅 Data: 04/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 la Sprint Retrospective agile, l’evento conclusivo dello Sprint dedicato al miglioramento continuo del team. Scopriremo come questa retrospettiva Scrum permette allo Scrum Team di evolvere e ottimizzare il proprio modo di lavorare, garantendo maggiore efficacia e qualità Sprint dopo Sprint.

🎧 Ascolta l’Episodio

🎯 Cos’è la Sprint Retrospective

La Sprint Retrospective Scrum è l’evento finale dello Sprint dove l’intero Scrum Team si riunisce per migliorare la Scrum Team effectiveness. Gli obiettivi principali sono:

  • Analizzare l’andamento dello Sprint concluso
  • Identificare punti di forza e aree di miglioramento
  • Pianificare azioni concrete per ottimizzare il lavoro futuro
  • Incrementare qualità ed efficacia del team

🔄 Caratteristiche Principali

Timeboxing e Partecipanti

  • Durata massima: 3 ore per Sprint mensili
  • Durata proporzionalmente minore per Sprint più brevi
  • Partecipanti: intero Scrum Team (Developers, Product Owner, Scrum Master)

Focus sull’Ispezione

Come parte fondamentale degli Scrum events, lo Scrum Team ispeziona:

  • Relazioni e interazioni tra i membri
  • Processi di sviluppo
  • Strumenti utilizzati
  • Definition of Done
  • Dinamiche con gli stakeholder

💡 Elementi Chiave per il Successo

Psychological Safety Scrum

  • Creazione di un ambiente sicuro per l’espressione
  • Importanza della trasparenza e del feedback onesto
  • Possibilità di comunicare liberamente preoccupazioni e proposte

Tecniche di Facilitazione della Retrospettiva

  • Utilizzo di post-it per coinvolgere anche i più introversi
  • Atmosfera informale ma produttiva
  • Esercizi di team building e discussione strutturata
  • Strumenti di facilitazione retrospettiva specifici per team distribuiti

Focus sulle Azioni

  • Identificazione di almeno un’azione di miglioramento concreta
  • Inserimento delle azioni nel Sprint Backlog successivo
  • Monitoraggio e verifica dei risultati nella Sprint Review

⚙️ Best Practices

Gestione Efficace

La facilitazione della retrospettiva richiede di:

  • Mantenere un equilibrio tra formalità e informalità
  • Coinvolgere attivamente tutti i membri del team
  • Documentare le decisioni e gli action item per il miglioramento continuo Scrum

Implementazione dei Miglioramenti

  • Prioritizzare le azioni in base all’impatto atteso
  • Allocare tempo specifico nello Sprint per le attività di miglioramento
  • Verificare l’efficacia delle azioni implementate

📚 Approfondimenti Consigliati

🎓 Note del Trainer

“La Sprint Retrospective non è solo un momento di riflessione, ma un’opportunità concreta per evolvere la Scrum Team effectiveness. Il segreto sta nel bilanciare la serietà dell’evento con un’atmosfera che favorisca l’apertura e la partecipazione attiva di tutti i membri del team.”

🔜 Prossimo Episodio

Non perdete il prossimo episodio dove approfondiremo gli artefatti di Scrum.

Questo articolo è basato sull’episodio 15 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.

Evento Sprint Review in Scrum

Evento Sprint Review: da presentazione a sessione di valore [E14]

ℹ️ Evento Sprint Review 📅 Data: 28/03/2023 ⏱ Durata: 25 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 la Sprint Review, un evento cruciale di Scrum che si concentra sull’ispezione dei risultati dello Sprint e sull’adattamento dei piani futuri. Scopriamo come i Team Scrum possono trasformare questo evento da una semplice presentazione a una sessione di lavoro collaborativa che aumenta il valore del prodotto e il coinvolgimento degli stakeholder.

🎧 Ascolta l’Episodio

🎯 Cos’è la Sprint Review

La Sprint Review è il penultimo evento dello Sprint, timeboxed a un massimo di 4 ore per uno Sprint di un mese. I suoi scopi principali sono:

  • Ispezionare il risultato dello Sprint
  • Determinare i futuri adattamenti
  • Verificare i progressi verso il Product Goal
  • Collaborare con gli stakeholder sui prossimi passi

🔄 Caratteristiche Principali

Timeboxing e Partecipanti

  • Durata massima: 4 ore per Sprint di un mese (generalmente più breve per Sprint più corti)
  • Coinvolge l’intero Scrum Team
  • Include gli stakeholder chiave
  • Focus sulla collaborazione invece che sulla presentazione

Struttura Efficace

  • Verifica del raggiungimento dello Sprint Goal
  • Utilizzo dell’Increment funzionante
  • Feedback e interazione con gli stakeholder
  • Discussione del Product Backlog e direzione futura
  • Previsione della timeline di consegna

💡 Benefici della Sprint Review

  • Feedback diretto degli stakeholder sul prodotto funzionante
  • Maggiore trasparenza dei progressi
  • Migliore collaborazione tra Scrum Team e stakeholder
  • Maggior allineamento con le esigenze degli utenti
  • Identificazione precoce delle necessità di adattamento

⚙️ Best Practices

Coinvolgimento degli Stakeholder

  • Invitare stakeholder rilevanti che useranno o saranno impattati dal prodotto
  • Spiegare lo scopo e l’importanza della loro partecipazione
  • Fornire interazione diretta con il prodotto
  • Raccogliere e organizzare il feedback sistematicamente

Gestione della Sessione

  • Mantenere la presentazione iniziale breve (20-30 minuti)
  • Concentrarsi sull’utilizzo del prodotto funzionante
  • Utilizzare strumenti come feedback board (Mi piace/Da migliorare/Nuove idee)
  • Riservare tempo per la discussione collaborativa
  • Condividere il potenziale Sprint Goal successivo e la direzione del Product Backlog

📚 Errori Comuni da Evitare

  • Trasformarla in una presentazione PowerPoint
  • Limitare la partecipazione al solo Scrum Team
  • Mostrare solo video o screenshot invece del prodotto funzionante
  • Presentare al Product Owner invece che agli stakeholder esterni
  • Non raccogliere feedback actionable

🎓 Note del Trainer

“La forza della Sprint Review sta nella sua natura collaborativa. Quando i team vanno oltre le semplici presentazioni e attivano un vero coinvolgimento degli stakeholder con il prodotto funzionante, sbloccano preziosi insight e creano un allineamento più forte con le esigenze degli utenti. Ricordate, non è una riunione di reporting – è una sessione di lavoro che guida il valore del prodotto.”

🔜 Prossimo Episodio

Non perdete il prossimo episodio dove esploreremo la Sprint Retrospective in Scrum.

Questo articolo è basato sull’episodio 14 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.

Daily Scrum in Scrum Framework

Evento Daily Scrum: Sincronizzazione Quotidiana [E13]

ℹ️ Evento Daily Scrum 📅 Data: 21/03/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 il Daily Scrum, noto anche come daily standup, l’evento quotidiano di 15 minuti che permette ai Developer di sincronizzarsi e pianificare il lavoro delle successive 24 ore. Scopriremo come questo evento del framework Scrum contribuisce al successo dello Sprint e del team.

🎧 Ascolta l’Episodio

🎯 Cos’è il Daily Scrum

Il Daily Scrum, spesso chiamato anche scrum daily meeting, è un evento di 15 minuti che coinvolge i Developer dello Scrum Team. Il suo scopo principale è:

  • Ispezionare l’avanzamento verso lo Sprint Goal
  • Adattare lo Sprint Backlog secondo le esigenze
  • Pianificare il lavoro delle prossime 24 ore

🔄 Caratteristiche Principali

Timeboxing e Partecipanti

  • Durata massima: 15 minuti
  • Si tiene ogni giorno, idealmente alla stessa ora e luogo
  • Partecipanti principali: Developer
  • Product Owner e Scrum Master possono assistere (se autorizzati dai developers) o partecipare come Developer (se contribuiscono alla creazione dell’Increment)

Focus sull’Autogestione

  • I Developer scelgono struttura e tecnica preferita per il daily standup
  • Concentrazione sullo Sprint Goal
  • Promozione dell’autogestione del team

💡 Benefici del Daily Scrum

  • Migliora la comunicazione nel team
  • Identifica rapidamente gli impedimenti
  • Promuove il processo decisionale veloce
  • Elimina la necessità di altri meeting
  • Aumenta la trasparenza del lavoro

⚙️ Best Practices

Gestione Efficace

  • Task dimensionati per essere completati in una giornata
  • Visibilità del movimento delle attività
  • Identificazione rapida dei problemi
  • Collaborazione invece di lavoro in silos

Gestione delle Discussioni

  • Separare rilevazione e risoluzione dei problemi
  • Utilizzare post-it per tracciare temi da approfondire
  • Pianificare discussioni separate per i dettagli tecnici dopo il daily scrum meeting

📚 Approfondimenti Consigliati

  • La Scrum Guide: Daily Scrum e altri eventi Scrum
  • Tecniche di facilitazione per Daily Scrum efficaci
  • Metriche e visualizzazione dell’avanzamento
  • Pattern di comunicazione efficace nei meeting agili

🎓 Note del Trainer

“Il Daily Scrum non è solo un momento di aggiornamento, ma una vera e propria occasione per i Developers di sincronizzarsi e mantenere il focus sullo Sprint Goal. La chiave del successo sta nella sua regolarità e nella capacità di mantenere l’evento conciso e focalizzato.”

🔜 Prossimo Episodio

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

Questo articolo è basato sull’episodio 13 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!]

Sprint Planning Scrum

Sprint Planning in Scrum: La Guida Definitiva [E12]

ℹ️ Sprint Planning in Scrum 📅 Data: 14/03/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 Planning secondo la Scrum Guide (versione Novembre 2020). Analizziamo come questo evento dà il via allo Sprint e stabilisce le basi per il successo del team.

🎧 Ascolta l’Episodio

🎯 I Tre Argomenti dello Sprint Planning

1. Perché questo Sprint è di valore?

  • Il Product Owner propone come incrementare valore nel prodotto
  • Lo Scrum Team collabora per definire lo Sprint Goal
  • Focus sugli outcome per gli stakeholder

2. Cosa si può fare in questo Sprint?

  • I Developer selezionano elementi dal Product Backlog
  • Selezione basata su:
    • Performance precedenti
    • Capacità futura
    • Definition of Done

3. Come si svolgerà il lavoro?

  • Decomposizione in task giornalieri
  • Pianificazione tecnica dettagliata
  • Autonomia dei Developer nelle decisioni

⏱️ Timeboxing e Struttura

  • 8 ore massimo per Sprint mensili
  • Proporzionalmente più breve per Sprint più corti
  • Concentrazione delle attività di pianificazione

🔄 Lo Sprint Backlog

  • Include:
    • Sprint Goal (commitment fisso)
    • Elementi del Product Backlog selezionati
    • Piano di consegna dettagliato

💡 Punti Chiave

  • Lavoro collaborativo dell’intero Scrum Team
  • Autonomia dei Developer nella selezione del lavoro
  • Flessibilità nella pianificazione dettagliata
  • Focus sulla trasparenza e comunicazione

📚 Approfondimenti Consigliati

  • Scrum Guide 2020
  • Sprint Goal e sua importanza
  • Tecniche di decomposizione del lavoro
  • Stima e previsione in Scrum

🎓 Note del Trainer

“Lo Sprint Planning è come un concentratore di riunioni. Tutto quello che c’è da fare per il prossimo mese è discusso durante queste ore, eliminando la necessità di ulteriori incontri di pianificazione.”

🔜 Prossimo Episodio

Non perdete il prossimo episodio dove approfondiremo il Daily Scrum e la loro importanza nell’ispezione e adattamento quotidiano.

Questo articolo è basato sull’episodio 12 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.

Eventi Scrum e Sprint

Gli Eventi Scrum: Il Cuore Pulsante del Framework [E11]

ℹ️ Gli eventi dello Scrum Framework e lo Sprint 📅 Data: 7/03/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 gli Eventi Scrum secondo la Guida Scrum (versione Novembre 2020), con particolare attenzione allo Sprint come contenitore di tutti gli altri eventi. Analizzeremo come questi eventi creano regolarità e supportano l’ispezione e l’adattamento continui.

🎧 Ascolta l’Episodio

🔄 Gli Eventi Scrum: Fondamenti

Gli eventi in Scrum nello Scrum Framework sono occasioni formali per ispezionare e adattare gli artefatti. Progettati per:

  • Garantire la trasparenza necessaria
  • Creare regolarità nel processo
  • Minimizzare riunioni non definite
  • Facilitare l’ispezione e l’adattamento

🎯 Lo Sprint: Il Cuore di Scrum

Lo Sprint è l’evento principale dove:

  • Le idee si trasformano in valore
  • Ha una durata fissa (massimo un mese)
  • Include tutti gli altri eventi Scrum
  • Mantiene costante la qualità
  • Permette la rinegoziazione dell’ambito (scope)

⏱️ Durata dello Sprint

La scelta della durata si basa su tre fattori:

  1. Livello di rischio e incertezza
  2. Sincronizzazione con eventi esterni
  3. Limite massimo di un mese

📊 Prevedibilità e Metriche

  • Utilizzo di burn-down, burn-up, flussi cumulativi
  • Importanza dei dati empirici
  • Focus sulla previsione basata sull’esperienza

🛑 Annullamento dello Sprint

  • Solo il Product Owner può annullare uno Sprint
  • L’unica ragione: Sprint Goal obsoleto
  • Processo post-annullamento

📚 Approfondimenti Consigliati

  • Teoria dell’empirismo nello Scrum Framework
  • Gestione degli eventi secondo la Scrum Guide
  • Ruolo del Product Owner
  • Metriche e visualizzazione dell’avanzamento

🎓 Note del Trainer

“Gli eventi in Scrum costituiscono l’opportunità di ispezionare e adattare l’incremento di prodotto. Lo Sprint è come il battito cardiaco che dà il ritmo al processo, permettendoci di lavorare in modo empirico e limitare i rischi.”

🔜 Prossimo Episodio

Non perdete il prossimo episodio dove approfondiremo lo Sprint Planning.

Questo articolo è basato sull’episodio 11 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.