Scrum Academy - Mastering Scrum

Mastering Scrum: guida essenziale al framework agile

Sei pronto/a a rivoluzionare il tuo approccio alla gestione dei prodotti? Il nostro mini-corso “Mastering Scrum: guida essenziale al Framework Agile” per Leader e Product Manager è un primo passo importante per sbloccare il pieno potenziale del team per la creazione di prodotti complessi.

Perché Scrum è fondamentale per i leader moderni?

Nel panorama aziendale in rapida evoluzione di oggi, la capacità di adattarsi rapidamente e consegnare valore in modo consistente è più cruciale che mai. Mastering Scrum, un framework Agile leader nel settore, offre una soluzione collaudata per:

  • Accelerare il time-to-market dei prodotti
  • Migliorare la qualità e la soddisfazione del cliente
  • Aumentare la produttività e l’engagement del team
  • Ridurre i rischi e i costi di sviluppo

Cosa imparerai in questo mini-corso

Il nostro corso conciso ma completo ti guiderà attraverso i fondamenti di Scrum, fornendoti una breve introduzione per una corretta comprensione. Ecco cosa copriamo:

  1. Fondamenti di Scrum e valori agile
  • Comprendere i principi chiave del framework Scrum
  • Allineare i valori Agile con la leadership moderna
  1. Ruoli e Responsabilità in Scrum
  1. Eventi e artefatti Scrum

Chi dovrebbe iscriversi al corso Mastering Scrum: guida essenziale?

Scrum Academy - Mastering Scrum

Il corso Mastering Scrum è ideale per:

  • Product/Project Manager o leader aziendali che desiderano migliorare la comprensione di Scrum
  • Professionisti IT interessati a esplorare e comprendere la leadership Agile
  • Chiunque voglia comprendere ed utilizzare Scrum nella propria organizzazione

Perché Scegliere il Nostro Mini-Corso Mastering Scrum: guida essenziale?

Conciso e pratico: concentrato sulle competenze essenziali per una rapida comprensione.
👨‍💻 Esperti del settore: contenuti curati da professionisti Scrum certificati con anni di esperienza sul campo.
📚 Flessibile: studialo al tuo ritmo, adattandolo ai tuoi impegni di lavoro.

Testimonianze

Non ne abbiamo ancora per questo corso, ma puoi vedere quelle degli altri corsi… vuoi essere il primo a dirci cosa ne pensi di questa mini-formazione, scrivici una mail, ci farà piacere!

Pronto a Trasformare la Tua Leadership con Scrum?

Non perdere l’opportunità di elevare le tue competenze di leadership Agile e migliorare la gestione dei tuoi prodotti iniziando con il mini corso Mastering Scrum.

Investi nel tuo futuro professionale e nel successo della tua organizzazione. Diventa un leader Scrum oggi stesso!


Hai domande? Contattaci. Siamo qui per aiutarti a iniziare il tuo viaggio Scrum!

output outcomes impatto scrum

Output, Outcomes e Impatto in Scrum [E46]

ℹ️ Output, Outcomes e Impatto in Scrum 📅 Data: 20/08/2024 ⏱️ Durata: 17 minuti

🎙️ Introduzione

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

📑 Sommario

In questo episodio esploriamo la differenza tra output, outcomes e impatto in Scrum, elementi fondamentali per comprendere il valore generato dal lavoro del team. Scopriremo come questi tre livelli di risultati si collegano tra loro e quale ruolo gioca il Product Owner nel massimizzare il valore per l’organizzazione. Leggi l’articolo originale qui!

🎧 Ascolta l’Episodio

🎯 Output: Il Risultato Tangibile

L’output rappresenta il prodotto immediato del lavoro dello Scrum Team:

  • Funzionalità software
  • Documentazione e guide utente
  • Codice applicativo
  • Report e analisi di mercato

🔄 Outcomes: Il Cambiamento Desiderato

Gli outcomes sono i risultati del cambiamento generato dagli output:

  • Aumento della soddisfazione dei clienti
  • Maggiore engagement degli utenti
  • Riduzione dei tempi di completamento delle attività
  • Miglioramento della retention degli utenti

💡 Impatto: Il Valore per l’Azienda

L’impatto rappresenta il valore complessivo per l’organizzazione:

  • Aumento dei ricavi e della redditività
  • Espansione delle quote di mercato
  • Miglioramento della reputazione aziendale
  • Incremento della fedeltà dei clienti

⚙️ Come Collegare Output, Outcomes e Impatto

Definire gli Output

  • Identificare chiaramente le funzionalità nel Product Backlog
  • Garantire la trasparenza della strategia
  • Allineare gli output con il Product Goal

Stabilire gli Outcomes Desiderati

Valutare l’Impatto

  • Collegare gli outcomes agli obiettivi strategici
  • Analizzare le metriche di business post-rilascio
  • Misurare il contributo agli obiettivi aziendali

📚 Caso Studio: Applicazione Mobile

Output

  • Implementazione di una nuova funzionalità di messaggistica istantanea
  • Sviluppo dell’interfaccia utente
  • Integrazione con i server di messaggistica

Outcome

  • Aumento del 30% nel numero di sessioni per utente
  • Incremento del 50% nei messaggi inviati quotidianamente
  • Maggiore engagement degli utenti

Impatto

  • Crescita del 15% nei ricavi da abbonamenti Premium
  • Aumento della base utenti premium
  • Miglioramento della posizione competitiva

🎓 Note del Trainer

La connessione tra output, outcomes e impatto è fondamentale nella gestione del prodotto. Il Product Owner gioca un ruolo cruciale nel garantire che il lavoro quotidiano del team si traduca in valore tangibile per l’organizzazione. Non si tratta solo di consegnare funzionalità, ma di creare un impatto misurabile sul business

Fabio Panzavolta, Professional Scrum Trainer

🔜 Prossimo Episodio

Non perdete il prossimo episodio dove approfondiremo 5 esempi di prodotti falliti!

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

Scrum Master come agente del cambiamento

Scrum Master come agente di cambiamento

Uno Scrum Master come agente di cambiamento stimola ed aiuta tutti, in azienda, a migliorarsi continuamente.

Facendolo, gli ostacoli che si presenteranno nel percorso di creazione del prodotto, saranno rimossi.

Questa rimozione porterà più business agility: prodotti di migliore qualità, clienti e dipendenti più contenti, più rapidità per andare dall’idea alla produzione.

Scrum Master come agente di cambiamento – Scrum Team

Avere un impatto a livello di team è importante, spesso il punto iniziale dei miei interventi di Scrum coaching. Senza entrare nel dettaglio, facilitazione, insegnamento, coaching, richiamo delle regole decise dal team in situazioni difficili sono tutti esempi di impatto indiretto che uno Scrum Master ha sul team.

Scrum Master Agente del Cambiamento
Clicca sull’immagine per ascoltare l’episodio del podcast

Ma uno.a Scrum Master non dovrebbe limitarsi ad avere un impatto a livello di team. Uno Scrum Master come agente di cambiamento lavora anche a livello aziendale, influenzandone il cambiamento.

Infatti, molto spesso, il team rivelerà ostacoli organizzativi che ne limitano l’agilità. Qui lo Scrum Master deve intervenire per rimuoverli. Questo è un esempio di Scrum Master come agente di cambiamento.

Limitarsi a dire « ma qui funziona così da sempre » oppure « tanto a me non mi ascoltano » è spesso quello che mi sento dire. Ed io rispondo sempre che si può fare di più, vediamo come.

Scrum Master come agente del cambiamento – L’azienda

Qui le cose si complicano, ma non sono impossibili. Ecco qualche « trucco » che puoi usare per farti sentire.

1 – Fai domande

Le domande sono un mezzo efficace per far riflettere le persone. Preparati domande potenti (« powerful questions » dicono gli inglesi) che permetteranno di sfidare i colleghi (di qualsiasi livello). Fare domande non ti impegna a nulla.

Esempio: ho notato che lo Scrum Team dipende fortemente dal team di deployment per i rilasci in produzione. Questo crea dei momenti di attesa che limita il nostro time to market e le nostre capacità di autonomia. Come potremmo risolvere questo problema?

2 – Dati per sostenere le tue domande

Le domande migliori sono supportate da dati.

Esempio: se fossimo autonomi nel deployment in produzione, potremmo guadagnare facilmente 4 giorni (il tempo medio di attesa fra la richiesta di rilascio e l’effettivo rilascio) ed anche rilasciare più di una volta durante uno Sprint. Questo ridurrebbe il ciclo di feedback e aumenterebbe la nostra agilità.

3 – Piccoli passi

Cambiare tutto subito non è un approccio efficace. Cerca di capire qual’è il problema più grande da risolvere. Voler risolvere mille cose in parallelo ti sfinirà e non otterrai grandi risultati. Fai focus su una o due cose che possono avere un impatto concreto sul team e l’azienda.

Esempio: durante uno Sprint, ti rendi conto che lo Scrum Team ha molte cose che può migliorare. Sono tutte elencate nei tuoi appunti. Rileggendoli, capisci che l’incapacità di ottenere un Incremento Done e di rilasciare in produzione autonomamente sono due punti sui quali lavorare in priorità. Condividi questo punto di vista con il team e cominci a lavorare per risolverli.

Conclusioni

In conclusione, uno Scrum Master come agente del cambiamento è responsabile di alzare sempre l’asticella. Interviene a livello di team e aziendale. L’obiettivo è quello di ottenere ciò che aiuterà il team a rilasciare più valore più rapidamente.

La conseguenza sarà una capacità dell’azienda a soddisfare meglio e più rapidamente i propri clienti con prodotti più pertinenti e di maggiore qualità.

Queste formazioni potrebbero interessarti

Misurare gli obiettivi in Scrum

Misurare gli obiettivi in Scrum

Misurare gli obiettivi in Scrum è necessario per capire se stiamo realmente massimizzando il valore del prodotto.

Nell’articolo precedente, gli obiettivi in Scrum, abbiamo esplorato perché e come Product Goal e Sprint Goal forniscono focus e autonomia allo Scrum Team. Aiutandoci a concentrarci sul risultato voluto per l’utilizzatore, piuttosto che sulle funzionalità da implementare.

In questo articolo vediamo perché è importante che questi obiettivi trasparenti siano ispezionati ed adattati a frequenze regolari… empirismo all’opera con gli obiettivi!

L’effetto Cobra

Misurare gli obiettivi in Scrum - L'effetto cobra

Quando l’India era ancora una colonia inglese, Delhi e altre grandi città erano infestate di serpenti a sonagli, con problemi ovvi per la popolazione. Il governo allora decise di offrire una ricompensa a tutti coloro che uccidevano e consegnavano i serpenti alle autorità.

Questa strategia è stata molto efficace, in quanto i cobra in poco tempo sono spariti. La ricompensa però è rimasta… la popolazione ha cominciato ad allevare serpenti a sonagli, per poi ucciderli e continuare ad ottenere la ricompensa.

Questa storia è un aneddoto che puoi trovare su wikipedia.

Ci insegna tante cose e che un obiettivo, se rimane fisso, ad un certo punto può avere un effetto perverso ed diventare controproducente. Abbiamo quindi bisogno di una misura che ci permetta ispezionare ed adattare a frequenze regolari il risultato ottenuto per capire se e quando l’obiettivo è raggiunto e passare al prossimo magari aggiornando le misure di valore.

Misurare gli obiettivi in Scrum con Evidence Based Management

Evidence Based Management è un framework di misura del valore proposto da Scrum.org. Ci aiuta ad ottenere la prova della creazione di valore in modo empirico.

Il concetto usa lo stesso approccio del mondo medico, nel quale il dottore cerca la prova della malattia (attraverso gli esami clinici) per poi proporre un protocollo di cura.

Nel caso di Scrum vogliamo la prova (feedback) che il prodotto ha effettivamente creato valore per l’utente contribuendo al raggiungimento dell’obiettivo.

Evidence Based Management utilizza quattro aree di valore, ognuna con un insieme di indicatori che ci aiutano a capire come stiamo performando:

  • Current Value: il valore attualmente generato dal prodotto
  • Unrealized Value: il valore atteso dagli utilizzatori del prodotto ma non ancora disponibile
  • Capacity to Innovate: la capacità dell’azienda a creare risultati innovanti
  • Time to Market: la rapidità del passaggio dall’idea alla produzione

Quindi, attraverso le misure, otteniamo la prova che il nostro prodotto sta creando valore e siamo capaci di affermare se l’obiettivo che avevamo è stato raggiunto o meno.

Mi spiego con un esempio.

Esempio di utilizzo di Evidence Based Management

La visione di Collective Genius (e Scrum.org) è di aiutare le persone ed i team a risolvere problemi complessi.

Con Collective Genius, cerchiamo di raggiungere questa visione attraverso una strategia che si focalizza su segmenti di clientela come, ad esempio: le persone che scoprono Scrum, quelle che già praticano ma vogliono perfezionarsi, persone che vogliono auto-formarsi, manager che vogliono formare il loro team, ecc…

Le proposte di valore sono diverse come, ad esempio: coaching Scrum, formazioni di qualità con Scrum.org, creazione di contenuto gratuito e a pagamento, ecc.

Visto che le idee sono tante, ma le risorse poche, siamo costretti a fare delle scelte in termini di segmenti di clientela, proposte di valore ed esperimenti.

Trattiamo questo sito web come un prodotto, il cui focus in termini di proposta di valore è la creazione di contenuto gratuito per le persone che scoprono e praticano Scrum Professionale.

Ogni mese abbiamo un Product Goal definito e le misure dell’impatto dell’obiettivo in termini di Evidence Based Management sono fatte sul prodotto (il sito). Se l’impatto supera le soglie che ci siamo prefissati, allora vuol dire che il Product Goal è stato raggiunto. Altrimenti usiamo i dati per capire per quale ragione non abbiamo superato queste soglie. Miglioramento/adattamento continuo.

Riprendendo Evidence Based Management, per il nostro sito (prodotto), la situazione (approssimativa) è la seguente:

  • Current Value (medio): articoli e risorse scaricabili gratuite che permettono di capire e sperimentare Scrum Professionale. Possiamo fare meglio. Ce lo dicono gli indicatori in termini di visite e lettura degli articoli.
  • Unrealized Value (alto): tanti esperimenti nel cassetto che non sviluppiamo. Ce lo dicono le richieste delle persone che formiamo, i manager con cui discutiamo, ecc… Qui si possono creare business plans per ottenere finanziamenti o investitori e far crescere il prodotto.
  • Capacity to Innovate (basso): siamo molto focalizzati sul delivery di formazioni e coaching. L’innovazione è poca ed è uno dei nostri punti deboli. Qui puoi avere un’idea degli investimenti necessari per ricerca e sviluppo per il prodotto.
  • Time to Market (basso): siamo bravi ad andare dall’idea alla produzione. Un nuovo articolo del blog in tre giorni è pensato, scritto e pubblicato. Abbiamo altri indicatori di questo tipo per podcast e video che ci aiutano a capire che sotto questo aspetto non abbiamo bisogno di miglioramento. Fra le altre cose, qui si capisce quanto focus c’è in nello sviluppo del prodotto.

Essendo coscienti delle aree meno performanti, abbiamo deciso di investire nell’Unrealized Value.

Forse hai notato che ultimamente stiamo facendo qualche piccola modifica al sito. Per esempio la possibilità di registrarsi per accedere a contenuto scaricabile, oppure nuove proposte di valore come Scrum in Pratica – Team (re)startup. Questi sono tutti esperimenti che fanno parte di una strategia e ci permettono di capire meglio ciò che i visitatori considerano come valore.

Misurare gli obiettivi in Scrum
Misurare gli obiettivi

Per esempio, il mese scorso, solamente 3 persone si sono iscritte al sito per scaricare il modello per definire gli obiettivi, presente nell’articolo Gli obiettivi in Scrum. La nostra soglia era 10 download in un mese. Il prodotto ci dice che l’obiettivo non è stato raggiunto. Perché? Lo capiremo (forse) con altri esperimenti… oppure puoi dirmelo nei commenti 😚…

Altro esempio… la nuova proposta di valore Scrum in Pratica – Team (re)startup ci ha permesso di acquisire un nuovo cliente, per il quale la proposta è semplicemente perfetta. E questo dopo nemmeno un mese dalla pubblicazione dell’idea. In questo caso l’obiettivo è stato raggiunto molto prima di quello che ci aspettavamo ed è un ottimo esempio di interazione fra prodotti (sito web e formazioni).

Così abbiamo confermato la nostra idea di Unrealized Value, sperimentando. L’intuizione c’era, non la certezza. Questa è stata acquisita grazie al fatto che l’acquisto della proposta di valore è effettivamente avvenuta.

Fra qualche settimana, quindi, questa proposta passerà dall’unrealized value al current value e potremmo dire di aver migliorato entrambi perché l’unrealized value diminuisce e il current value aumenta. E qui capiamo quanto le cose sono sempre in movimento, non c’è nulla di statico.

Tutto molto logico, ma bisogna pensarci e distaccarsi dalla mania che abbiamo di concentrarsi maggiormente sull’esecuzione. Non è finita, tutto questo non lo facciamo esclusivamente per creare valore… qualcun altro ci deve guadagnare. A meno che non ti piaccia lavorare per la gloria 🏆.

Misurare gli obiettivi in Scrum e L’impatto per l’azienda

Ragionare in termini di obiettivi, da raggiungere attraverso un prodotto, permette da un lato di creare valore per l’utilizzatore e dall’altro ha un impatto per l’azienda. Questo impatto può prendere diverse forme: aumento dei guadagni, maggiore notorietà, ecc.

Prendiamo l’esempio del sito web Collective Genius: sappiamo che creiamo valore perché il numero di abbonati aumenta costantemente, certo contenuto è scaricato, il numero di visite su certe pagine ci fa capire gli argomenti da trattare in priorità, ecc. La conseguenza per noi, è un aumento della notorietà nell’arena dell’agile, più partecipanti in formazione e quindi ricavi costanti (o in aumento).

Qui si capisce quanto importante sia collaborare per capire quali sono gli obiettivi aziendali, per poterli raggiungere grazie ai nostri prodotti. Per questo dirigenza e Product Owners dovrebbero lavorare insieme per ottimizzare l’impatto che i prodotti hanno sull’azienda… ma questo è un altro discorso, che magari farò in un futuro articolo.

Conclusioni

L’agilità non vuol dire fare tutto subito e velocemente, bensì strategia e validazione costante tramite feedback quantificabile. Misurare gli obiettivi in Scrum permette di imparare e capire se le energie ed il denaro spesi stanno effettivamente creando valore o meno.

Attenzione quindi all’effetto cobra, perché avere obiettivi fissi potrebbe portarti a non massimizzare il valore creato e, nel peggiore dei casi, al disastro.

Per continuare ad imparare

Unlocking Business Agility with Evidence Based Management
Professional Agile Leadership - EBM
Il management in scrum

Management in Scrum [E43]

ℹ️ Management in Scrum 📅 Data: 28/03/2024 ⏱️ Durata: 54 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 management in Scrum, qui l’articolo del blog, dalle sue origini storiche alla sua evoluzione nel contesto moderno. Scopriremo come questo approccio si differenzia dal management tradizionale e come può portare benefici concreti nelle organizzazioni che producono valore intellettuale. Nella seconda parte, ascolteremo le esperienze dirette di professionisti che stanno implementando Scrum in diversi contesti aziendali.

🎧 Ascolta l’Episodio

🎯 Le Origini del Management

Il termine “management” ha radici storiche interessanti:

  • Deriva dall’italiano “maneggio” (in riferimento ai cavalli)
  • Passa attraverso il francese “ménage” (governare la casa)
  • Evolve nell’inglese “to manage” (gestire)

🔄 Il Management nella Rivoluzione Industriale

  • Basato sul modello Command & Control
  • Necessario per la produzione di massa
  • Focalizzato sulla gestione di piani e persone
  • Ottimizzato per contesti di certezza e ripetibilità

💡 Il Management in Scrum

Principi Fondamentali

  • Focus su obiettivi e artefatti, non sulle persone
  • Trasparenza del lavoro svolto
  • Responsabilità chiaramente definite

Caratteristiche Distintive

Il management in Scrum si fa sugli elementi fondamentali del framework:

  • Gestione basata su obiettivi misurabili (Product Goal, Sprint Goal)
  • Approccio empirico all’adattamento
  • Valorizzazione delle competenze professionali
  • Decisioni prese da chi ha l’informazione più aggiornata

⚙️ Differenze col Management Tradizionale

  • Eliminazione della gerarchia rigida
  • Focus sulla creazione di valore
  • Promozione dell’auto-organizzazione
  • Valorizzazione dell’apprendimento attraverso la sperimentazione

📚 Applicazioni Pratiche

Il management in Scrum favorisce l’esperienza, sulla base della quale prenderemo decisioni informate.

  • Adatto per lavori complessi e cognitivi
  • Efficace nella produzione intellettuale
  • Supporta l’innovazione e l’adattamento
  • Promuove un ambiente di lavoro stimolante

🎓 Note del Trainer

Il management in Scrum rappresenta un cambio di paradigma fondamentale rispetto al management tradizionale. Non si tratta di gestire persone, ma di creare le condizioni ottimali affinché professionisti competenti possano dare il meglio di sé nel perseguire obiettivi chiari e significativi

Fabio Panzavolta, Professional Scrum Trainer

🔜 Prossimo Episodio

Non perdete il prossimo episodio dove approfondiremo un altro aspetto fondamentale di Scrum: guidare con i valori.

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

Il management in Scrum

Il management in Scrum

Il management in Scrum è qualcosa di radicalmente differente dal management “classico”. In questo articolo esploriamo quali sono le caratteristiche del management tradizionale per capirne le differenze rispetto al management in Scrum.

Il management in scrum
Clicca l’immagine per ascoltare il podcast

Clicca qui a fianco per ascoltare l’episodio del podcast dove leggo questo articolo e discuto la tematica con una decina di persone che condividono le loro idee ed esperienze!

Origini della parola management

La parola management deriva dall’italiano maneggio (di cavalli) e prima ancora dal latino ovviamente. In seguito in Francia si associa questa parola a “ménage” (governare *la casa*) e in inglese si è trasformata in “to manage” (gestire). Fonte Wikipedia (e la mia memoria).

Ma ciò che è importante, è che questa parola si usava inizialmente in relazione all’interazione con il mondo fisico. Maneggio degli utensili per custodire o montare i cavalli, per esempio.

La rivoluzione industriale ed il management

Durante la rivoluzione industriale, questa parola si è affermata per designare la gestione di piani e di persone (attraverso il “command e control“).

Il management in Scrum - The Principles of Scientific Management

Questo si spiega dalla necessità di dover produrre grandi quantità dello stesso prodotto (elaborazione di piani) da parte di persone, spesso analfabeti, (esecutori dei piani in “command e control“).

Qualche tempo fa ho letto il libro, The Principles of Scientific Management, scritto da Frederick Winslow Taylor, che fa capire bene le ragioni per le quali era necessario dire alle persone cosa e come fare il lavoro. Tutte le mie letture sono disponibili in questa pagina.

Il contesto (la certezza di ciò che si doveva produrre) si portava particolarmente bene a questo tipo di management, che ha permesso di ottimizzare la cadenza di produzione e quindi i benefici per le aziende (ma anche per i lavoratori che spesso erano pagati a cottimo).

Questo successo ha modellato le nostre aziende, ma anche il nostro sistema educativo e quindi il nostro modo di pensare e agire all’interno delle aziende. Anche se queste non producono più in serie, bensì idee, concetti, esperimenti, ecc… Ed è proprio questo il problema. Tentare di risolverlo con un happiness manager è come dire che si può correre più veloce con il buon paio di scarpe…

Il Management in Scrum

Con il passare dei decenni, il progresso ha portato diversi cambiamenti (non entro nel merito del giusto o sbagliato).

  • Persone sempre più istruite, l’analfabetismo non esiste praticamente più nei paesi industrializzati, anzi molti sono laureati.
  • La robotizzazione, che ha ridotto o addirittura eliminato gli operai nelle fabbriche
  • Il trasferimento della produzione industriale in altri continenti (Cina per esempio)

Ciò che rimane, in tante aziende che non hanno più produzione industriale ma produzione intellettuale, è però lo stile di management (attualmente ancora insegnato in tanti master, come dicevo prima) che si concentra sulla gestione delle persone (o del personale).

Il management in Scrum - Cynefin, Scrum e Agile
Cynefin, Scrum e Agile

È evidente che questo stile di management, applicato alla “produzione intellettuale”, è un errore e un costo enorme per l’azienda. Per capire meglio questa affermazione puoi leggere l’articolo qui a fianco (clicca l’immagine).

Il management in Scrum è qualcosa di completamente diverso, che l’esperienza mostra essere adatto a lavori complessi o di tipo cognitivo come, ad esempio, la creazione di software, hardware, il marketing, sales, ecc.

Il management in Scrum si basa sui seguenti principi fondamentali:

1 – Il management si attua su obiettivi o artefatti, non sulle persone che devono essere sempre considerate competenti e professionali, o comunque messe in condizioni favorevoli per richiedere ciò di cui hanno bisogno per esserelo.

2 – La trasparenza del lavoro fatto aiuta a capire le eventuali correzioni necessarie per raggiungere gli obiettivi prefissati. L’unica misura di avanzamento possibile è qualcosa che funziona e dimostra ciò che è stato fatto, non un documento o una presentazione power point.

3 – Delle responsabilità chiaramente definite, che permettono di creare valore più rapidamente in quanto le decisioni sono prese dalle persone che hanno l’informazione più “fresca” possibile.

Il Management si attua su obiettivi o artefatti

Ritorniamo alle origini. In un contesto di produzione intellettuale, le persone non si gestiscono, in quanto erudite, adulte e responsabili.

Pertanto si gestiscono gli obiettivi (che bisogna saper fissare e mantenere anche in momenti difficili) attraverso indicatori di valore (se non lo conosci puoi esplorare Evidence Based Management). Un obiettivo permette di dare una direzione alle persone che, insieme, cercano di raggiungerlo.

Si possono gestire gli artefatti, in Scrum sono il Product Backlog, lo Sprint Backlog e l’Increment, ovvero fonti di informazione trasparente che permettono di capire a chiunque in azienda il futuro, il presente ed il risultato del lavoro.

Management secondo Scrum
Clicca sull’immagine per ascoltare l’episodio del podcast

Trasparenza del lavoro fatto

Altra caratteristica del management in Scrum è la trasparenza del lavoro fatto. Un obiettivo può essere raggiunto in diversi modi (non con funzionalità predefinite e fisse). Ciò che interessa è farlo il più velocemente possibile, in modo opportunistico. Le persone devono sentirsi in sicurezza psicologica per sperimentare, imparare velocemente.

L’errore, considerato catastrofico in una catena di montaggio, è qualcosa di benvenuto nel contesto della produzione intellettuale perché permette di capire cosa manca per raggiungere l’obiettivo e, soprattutto, innovare.

La trasparenza è la base per poter poi capire come adattarsi per ridurre il divario tra ciò che si credeva realizzabile e la realtà.

Responsabilità chiaramente definite

Per raggiungere obiettivi ambiziosi, abbiamo bisogno di responsabilità chiaramente definite. Gerarchie o organigrammi sono assolutamente inefficaci quando si cerca di risolvere problemi complessi.

Il management in Scrum definisce chiaramente tre responsabilità: Product Owner, Developers, Scrum Master. Ovvero, un proprietario del prodotto che ne massimizza il valore, delle persone che lavorano alla creazione del prodotto (auto-organizzandosi per farlo) ed una persona che aiuta tutti quanti a capire come farlo in modo efficace.

Ogni responsabilità è concentrata sulla gestione di qualcosa, ma non di persone. Questo garantisce un ambiente di lavoro valorizzante, stimolante e produttivo al quale le persone sono entusiaste di contribuire!

Management in Scrum – Conclusioni

Il management della produzione intellettuale è molto diverso da quello applicato per la produzione industriale.

La nostra educazione e la maggior parte delle aziende, applicano un management “industriale” al lavoro intellettuale, portando a tensioni e fallimenti che costano molto caro. Basti pensare al caso estremo di Boeing.

Scrum ha il merito di essersi rivelato molto utile per la gestione della produzione intellettuale, le nostre formazioni ed il contenuto di questo sito hanno per obiettivo di aiutarti a capire il cambiamento personale necessario per adeguarsi.

Management in Scrum – Risorse utili per continuare

Management in Scrum. Drive - Dan Pink
5 Livelli di feedback in Scrum

5 livelli di feedback in Scrum

5 Livelli di feedback in Scrum

5 livelli di feedback in Scrum aiuta a capire uno dei problemi principali che osservo nei team che praticano Scrum, cioè la qualità del feedback ricevuto sul lavoro fatto durante lo Sprint. In questo articolo ti invito ad esplorare 5 livelli di feedback in Scrum, dal meno efficace al più efficace per uno sviluppo empirico di prodotto.

Nel seguito dell’articolo parlo spesso di Sprint Review, segui il link se non sai cos’è o vuoi rinfrescarti la memoria!

1 – Persone disinformate

Feedback in Scrum
Clicca l’immagine per ascoltare il podcast

Al livello meno efficace di feedback posiziono i team che invitano in Sprint Review delle persone interne all’azienda. Queste persone, quando si presentano all’evento, non sanno cos’è Scrum e perché partecipano (sigh). Ma visto che in azienda non è visto di buon occhio rifiutare una riunione, vengono con il computer e lavorano invece di partecipare.

lo Scrum Team, in generale, non riesce a coinvolgere i presenti e non capisce perché la magnifica presentazione power point non sta avendo successo.

La conclusione è tanta frustrazione per il team che non ottiene feedback di qualità e per i partecipanti, che continuano a non capire perché sono stati invitati ed hanno la sensazione di aver perso del tempo.

Rimaniamo su una nota positiva: spesso questo capita ai team che sono agli inizi con Scrum. Quindi anche il livello 1 di feedback è un buon inizio, da migliorare rapidamente!

2 – Stakeholders Feedback

Il team ha capito che i partecipanti alla Sprint Review devono sapere quale contributo possono dare. I partecipanti rimangono esclusivamente dipendenti dell’azienda, in generale manager ai quali il team deve rendere dei conti.

Sprint Review
5 livelli di feedback in Scrum – Sprint Review Checklist

Un miglioramento che puoi sperimentare, è quello di introdurre la Sprint Review spiegando ai partecipanti perché sono stati invitati. Idealmente iniziando dall’invito calendario, fino ad occupare i primi dieci minuti dell’evento, l’aspetto pedagogico è importante.

Le aspettative ed i vincoli per partecipare devono essere chiari. Le persone presenti sono invitate a prestare massima attenzione, oppure autorizzate a non partecipare. Se il computer non è indispensabile, specifico che non è necessario portarlo con sé 😙… se l’evento si svolge a distanza, telecamera accesa per tutti e facilitazione inclusiva dell’evento.

Se hai bisogno di migliorare la tua capacità a facilitare gli eventi Scrum (in presenza o a distanza), puoi dare un’occhiata a questo corso.

Lo Scrum Team, invece di preparare una presentazione Power Point, fornisce a tutti i partecipanti l’ultima versione del prodotto, che sarà utilizzata dai partecipanti per fornire feedback.

Fra lo step 1 e 2 possono passare diversi Sprint, è importante fare questo miglioramento il più rapidamente possibile.

3 – User Feedback

Per Scrum uno Stakeholder è qualsiasi persona esterna alla Scrum Team. L’utilizzatore del prodotto è un tipo di Stakeholder particolare. La persona che ci interessa di più dal punto di vista del feedback. Dobbiamo capire rapidamente se il lavoro fatto ha creato valore come l’avevamo ipotizzato.

Questo è uno step importante e molto spesso mancante in uno Scrum Team. Non avere utilizzatori in Sprint Review limita in maniera considerevole lo sviluppo empirico del prodotto e, di conseguenza, l’efficacia di Scrum.

Sento una vocina alzarsi e dire: “si ma, Fabio, per noi è impossibile avere degli utilizzatori in Sprint Review”… ok allora lo Scrum Team deve chiedersi come poter ottenere un feedback di qualità in modo asincrono.

Di conseguenza, dovete trovare il modo di arrivare in Sprint Review con gli utilizzatori del vostro prodotto, oppure con i dati generati durante lo Sprint che parlano per i vostri utilizzatori.

Il feedback utilizzatore è alla base dello sviluppo empirico dei prodotti e quindi di Scrum. Lo ripeto, perché è importante.

4 – Osservazione dell’utilizzatore

Ma si può fare meglio… osservare l’utilizzatore, capire come usa il prodotto. O come vorrebbe utilizzarlo.

Non c’è niente di peggio per un utilizzatore di doversi adattare ad un prodotto mal pensato, che non tiene conto delle necessità dell’utilizzatore.

Un’altra esperienza: nello sviluppo di uno smartphone per agenti pubblici (polizia, pompieri, ecc.), abbiamo fatto tutti i test dell’altoparlante in laboratorio. Il volume dell’altoparlante era alto, il team e gli stakeholders in Sprint Review erano soddisfatti.

Alla prima utilizzazione in un incrocio pieno di traffico, con il volume al massimo, si faceva fatica a capire cosa dicesse il nostro interlocutore!

Dall’esperienza raccontata in precedenza, con il team, abbiamo capito quanto importante fosse avere feedback, ma non solo, essere anche in condizioni reali ed osservare l’utilizzatore per poter confermare la creazione di valore!

5 – La prova del mercato

Il livello più avanzato di feedback, lo si ottiene grazie ai dati relativi all’utilizzo del prodotto ed alle sue funzionalità, alle vendite e relativi guadagni generati.

La prova del mercato è assolutamente indispensabile nello sviluppo empirico di un prodotto. Purtroppo, in certe aziende nelle quali c’è la cultura del prodotto finito (!!!), ho spesso assistito a battaglie interne per impedire la vendita di prodotti considerati non finiti. Senza che nessuno sapesse darmi la definizione di prodotto finito (sigh).

In questo caso l’azienda si espone agli stessi rischi di uno sviluppo waterfall: si usa Scrum per sviluppare tante ipotesi, mai confermate dal mercato e si rilascia in produzione dopo un anno o due di sviluppo. È chiaro che questo modo di fare elimina i benefici di Scrum e dello sviluppo empirico di un prodotto.

Empirismo e Scrum
Clicca l’immagine per ascoltare il podcast

Per esempio, nemmeno noi da Collective Genius, nelle Sprint Review del podcast Scrum Italia, abbiamo gli ascoltatori presenti. Però abbiamo i dati degli ascolti passati, facciamo esperimenti per capire in quali episodi abbiamo più ascolti. Abbiamo più ascolti sulle interviste? Oppure quando leggo gli articoli del blog? Quale durata è migliore? Ecc.

Non aspettiamo di aver registrato 1000 episodi per poi cominciare a pubblicarli, ne abbiamo 2/3 in stock (quando va bene) e per il resto ci affidiamo agli ascolti per decidere cosa fare.

Quindi, per ricollegarmi al punto precedente, anche questo è un caso di osservazione che può avvenire attraverso dati generati dal prodotto, non necessariamente da interviste dell’utilizzatore o una sua partecipazione in Sprint Review.

Ma bisogna pensarci, capirlo ed implementare le sonde corrette nel prodotto.

5 livelli di feedback in Scrum – Conclusione

In conclusione, ti suggerisco di riflettere (magari con il team nella prossima Retro) a quale livello di feedback siete in questo momento e capire come potete passare dal livello attuale al livello successivo. Specialmente se sei Scrum Master, questo articolo dovrebbe permetterti di aiutare il team ad aumentare il livello di qualità del feedback ottenuto!

Fammi sapere, mi farà piacere… Scrum On!

5 livelli di feedback in Scrum – Risorse utili relative all’argomento

Scrum funziona veramente?

Ma Scrum funziona veramente? [E40]

ℹ️ Scrum funziona veramente? 📅 Data: 23/01/2024 ⏱️ Durata: 57 minuti

🎙️ Introduzione

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

📑 Sommario

In questo episodio speciale, Fabio Panzavolta insieme a quattro ospiti esperti – Silvia, Alessandro, Michael ed Emanuele – esplorano le critiche attuali verso il framework Scrum. Attraverso le loro esperienze dirette, discutono se Scrum funziona per davvero e di come spesso non sia il framework ad essere problematico, ma la sua errata implementazione. Condividono strategie pratiche e storie di successo per superare gli ostacoli comuni nell’adozione di Scrum.

🎧 Ascolta l’Episodio

🎯 Punti Chiave della Discussione

Le Critiche a Scrum

  • Le critiche sui social media spesso derivano da implementazioni errate del framework
  • Molti attacchi sono basati su incomprensioni o applicazioni superficiali
  • Il problema non è Scrum, ma la capacità dell’organizzazione di rimuovere gli impedimenti

🔄 Sfide Comuni nell’Implementazione

Cultura Organizzativa

  • Mancanza di comprensione del mindset agile
  • Resistenza al cambiamento da parte del management tradizionale
  • Difficoltà nel passaggio da command & control all’auto-organizzazione

Trasformazione Agile

  • Importanza di iniziare con progetti pilota
  • Necessità di formazione adeguata per tutti i livelli
  • Focus sul cambio di mindset prima che sulle pratiche

💡 Scrum funziona! Storie di Successo

  • Creazione di team auto-organizzati
  • Abbattimento delle barriere tra sviluppatori e tester
  • Miglioramento della comunicazione e collaborazione
  • Delivery più rapidi e di maggiore qualità

⚙️ Best Practices Emerse

Per il Successo di Scrum

  • Partire dal “perché” si vuole adottare Scrum
  • Costruire una solida base di comprensione agile
  • Permettere al team di sperimentare e adattare le pratiche
  • Concentrarsi sul prodotto invece che sul progetto

Per il Cambiamento Organizzativo

  • Iniziare con piccoli cambiamenti significativi
  • Mostrare risultati tangibili
  • Costruire fiducia attraverso la trasparenza
  • Supportare l’auto-organizzazione del team

🎓 Note del Trainer

Le critiche a Scrum spesso nascono da implementazioni superficiali o incomplete. Il successo richiede un vero cambio di mindset organizzativo e la capacità di rimuovere gli impedimenti. Scrum funziona, quando interpretato e applicato correttamente, come qualsiasi strumento!

Fabio Panzavolta, Professional Scrum Trainer

🔜 Prossimo Episodio

Non perdere il prossimo episodio del podcast Scrum Italia, parleremo di 5 livelli di feedback diversi.

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

comprensione teorica e pratica di Scrum, come colmare il divario?

In questo articolo, Stefano Milanesi e Fabio Panzavolta, attraverso la loro esperienza da Scrum Master, offrono spunti di riflessione su come colmare il divario tra comprensione teorica e pratica di Scrum e qualche esperimento da provare al lavoro!

Introduzione

Discutiamo un tema che è abbastanza sentito, che abbiamo vissuto personalmente e che ci sta a cuore. Cioè quello di uno Scrum Master che si sente frustrato perché vede che Scrum non sta funzionando all’interno della propria azienda, si rende conto che non sta facendo le cose nella maniera corretta ed ha la volontà di migliorare, di capire, di trovare una soluzione sia all’interno del team che nell’organizzazione.

Questo articolo è la trascrizione adattata del video qui sopra

Comprensione teoricA e pratica di Scrum – Come capire quando Scrum è Scrum?

Come fa uno Scrum Master a capire se quello che si sta applicando in azienda è Scrum Professionale, oppure Scrum meccanico (applicato come una metodologia)?

Prima di tutto partire dalle basi di Scrum, cominciando a capire se quello che si è praticato fino ad ora è Scrum. Questo lo si riesce a capire con una buona conoscenza di base, teorica, da fonti affidabili, corrette. Un po’ tutti abbiamo fatto il fai da te, sicuramente avere delle fonti attendibili, un supporto attendibile, è importante.

Avere un mentore con cui parlare, confrontarsi, che abbia già avuto un’esperienza reale è un altro ottimo passo per maturare una certa coscienza.

Come far capire Scrum all’azienda?

Il passo successivo consiste a far capire Scrum Professionale agli altri, colleghi e azienda, necessario per abbattere certi ostacoli organizzativi e burocratici per praticare Scrum correttamente.

Inizialmente è utile e naturale aggrapparsi ai principi fondamentali di Scrum, non perché siano scritti nella Scrum Guide, ma perché Scrum è uno strumento per rivelare quello che non funziona in azienda. Se si vuole diventare più agili, quindi, ci vuole coraggio.

Prima di tutto bisogna capire che cosa è Scrum e che tipo di problemi aiuta a risolvere, perché se hai un martello e cerchi di usarlo per tagliarti le unghie arriverai alla conclusione che il martello non funziona. Quindi il primo passo è capire che strumento è Scrum e come lo puoi usare.

Comprensione teoricA e pratica di Scrum – Non concedere distorsioni a Scrum

Inoltre è importante non concedere troppe distorsioni a Scrum, perché altrimenti non funziona più. Non eliminare elementi da Scrum, al limite aggiungerne. In questo modo si creeranno dei piccoli conflitti, situazioni nel quale la gente ti chiederà ma perché ti comporti così? Perché ci dici di fare così, eccetera eccetera.

Si creano opportunità per aiutare i colleghi e l’azienda a capire come ci si può migliorare.

La nostra esperienza coincide nel fatto che, in certi contesti, bisogna passare attraverso dei momenti, a volte, difficili. È per questo che non bisogna rimanere soli, è molto importante non rimanere soli.

E incassare il supporto del team e dell’organizzazione.

Scrum è fattibile veramente?

Il messaggio che passiamo in formazione è positivo, è difficile, bisogna avere personalità per stimolare il cambiamento. Si può cominciare formulando domande, perché far domande non costa niente, non ci si mette in pericolo e si stimola la riflessione negli altri.

Un esempio di domanda potrebbe essere : “pensate veramente che siamo agili al 100%?” Sì, no, ma allora cosa possiamo fare per diventarlo? Cominciare a far domande è un buon inizio per cambiare le cose.

Comprensione teoricA e pratica di Scrum – Applicazione meccanica di Scrum, corretto?

Un’altra esperienza vissuta con diversi team è stata quella di trovare persone che erano fin troppo ligie nell’applicazione di Scrum, nel senso che lo applicavano in maniera meccanica. Rispetto stretto di sequenza e durata degli eventi, responsabilità che si trasformano in belle etichette piazzate su ogni persona all’interno del team. Peccato che poi si perde la ragione per la quale si sta facendo tutto questo e ritornare alle basi per capire il perché lo sto facendo è sicuramente il punto chiave.

Come dicevamo prima, fare domande a chi ci sta attorno, ma fare domande anche a Scrum, che può indicarci la direzione da prendere in qualsiasi situazione.

Perché sto facendo questa cosa? Perché questa cosa non funziona? Molto spesso la risposta la troviamo consultando la Scrum Guide, a volte lo troviamo con l’esperienza, quindi provando, facendo esperimenti e ottenendo feedback e risposte che poi ci guidano in qualche modo su quello che è il prosieguo della nostra esperienza.

Ep. 3 - Scrum Guide Scopo della Guida Scrum
Clicca l’immagine per ascoltare il podcast

L’applicazione stessa del framework è decisamente qualcosa di complesso. Un’applicazione meccanica non è corretta e non aiuta se non si capisce il perché si fanno le cose!

Acquisire sicurezza come Scrum Master

Acquisire sicurezza come Scrum Master è una cosa fondamentale per capire come comportarsi. Se io sono sicuro di quello che posso dire (o fare) per stimolare l’uso di Scrum poi posso anche esprimermi in un certo modo e sperimentare, ottenere feedback da questi esperimenti. Gli esperimenti servono per rivelare ciò che non funziona per correggerlo e progredire.

Questo è fondamentale.

Comprensione teorica e pratica di Scrum – Come si applica Scrum?

A volte si cerca di fare tutto subito, per tante ragioni. Procedere in questo modo non aiuta a capire realmente i feedback, perché vengono mescolati. Ho fatto quattro, cinque esperimenti tutti in una volta, per accelerare l’adozione, ma le persone non mi capiscono.

Il segreto (!!) è avere pazienza, la pazienza del giusto o di chi comunque conosce ed applica. Una certa logica iterativa ed incrementale, come ci insegna Scrum.

Rendere trasparente un backlog di impedimenti che impediscono Scrum Professionale, renderlo visibile a chiunque è un primo passo che si può sperimentare.

Molto spesso l’esperienza ci ha mostrato che primi ostacoli sono i più facili da eliminare, poi, man mano che si va avanti i successivi sono sempre più difficili. Capire come come si può progredire è effettivamente l’approccio più proficuo.

Errori tipici nell’applicazione di Scrum

Un errore tipico, osservato sul campo, di chi applica Scrum in modo meccanico è quella delle scorciatoie, per comodità o facilità.

Fare un buon coaching come Scrum Master, rispetto all’organizzazione ed al team, significa fare leva sui valori di Scrum, che ci aiutano ad ottenere tante risposte.

Trovare un “accordo” per lavorare con fiducia, che emerge grazie alla comprensione dei valori di Scrum, facilita tantissimo buona parte del processo di adozione di Scrum.

Evitare l’errore di “dimenticare” i valori Scrum è sicuramente necessario, in qualsiasi contesto.

I cinque valori fondamentali di Scrum illustrati
Clicca l’immagine per ascoltare il podcast

Spesso usiamo il parallelo con un team sportivo. Se si vuole progredire bisogna farlo in un ambiente di lavoro in cui ci si sente al sicuro. Gli anglofoni parlano di Psychological Safety.

Quando arriviamo in aziende nuove, ci comportiamo in accordo con i valori Scrum e, per questo, siamo percepiti come “diversi”, un pò strani 😊. Un Professional Scrum Master usa i valori Scrum costantemente, questi guidano il suo comportamento in modo tale che sia adatto alla risoluzione di problemi complessi. Leggi il nostro articolo Leading with Values.

È importante essere i primi ad essere strani, stimolare la curiosità per rispondere alle domande e mettere in moto il cambiamento.

Un altro errore classico è quello di fermarsi allo Scrum Team. Invece far capire all’organizzazione, in primis, che non siamo un corpo estraneo ma che lo Scrum Master esiste per una ragione ben precisa (che è quello di generare valore e farlo nella maniera migliore possibile) è importantissimo.

Qualcosa che è basilare per lavorare bene è essere felici. Persone felici, soddisfatte e motivate a raggiungere obiettivi saranno più produttive. Questa è anche la nostra funzione di Scrum Master. Perché questo accada, bisogna che effettivamente le cose siano molto chiare per tutti.

Chiarire, tramite un accordo generale (aziendale) su quelli che sono gli obiettivi del “come facciamo le cose” dovrebbe essere esplicitato, non può essere qualcosa che serpeggia. È molto importante che l’uso di Scrum per lo sviluppo di un particolare prodotto sia dichiarato, perché ci dà la legittimità per praticare correttamente in seno all’azienda.

A volte questa legittimità bisogna prendersela, senza aspettare di essere incoronati!

Questo fa parte della sicurezza che si è acquisita come Scrum Master. Se siete sicuri di voi, allora spingerete di più per ottenere quello che sapete sia giusto fare!

È un po come un allenatore di calcio che sa che se ci si allena in un certo modo con questo tipo di squadra allora puoi vincere. Se hai questa sicurezza poi la trasmetti anche agli altri.

Tutto quello che avviene all’interno di un’organizzazione dovrebbe essere umano centrico quindi, se attendiamo sempre difficilmente riusciremo a cambiare qualcosa.

Agire dando l’esempio e iniziare a fare quello che ci stiamo proponendo di fare perché abbiamo deciso di farlo è probabilmente la mossa migliore che che puoi fare per attuare in maniera effettiva un cambiamento.

Lo Scrum Master aiuta l’azienda, non solo il team.

È importante sottolineare che uno Scrum Master Professionale non aiuta solo lo Scrum Team. Necessariamente deve aiutare anche il resto dell’azienda a capire Scrum.

Direi che aiuta anche i clienti, fornitori, i manager e tutte le persone interessate a capire meglio un approccio diverso alla risoluzione di problemi complessi.

È abbastanza normale, all’inizio, concentrarsi sul team però bisogna anche avere questa forza di volontà di andare a eliminare gli impedimenti che rapidamente emergono al di fuori del team e che bisogna trattare in qualche modo.

Come fare quando ci sono più Scrum Team?

A volte, ci si trova a dover aiutare più team. L’esperienza ci ha mostrato Scrum Master molto scollati fra di loro, quindi poca anche unità di intenti nel nell’andare a fare coaching a livello organizzativo. Quindi, sicuramente, se la tua organizzazione ha più Scrum Team e siete più Scrum Master, parlarsi e cercare di fare emergere successi e difficoltà comuni e sperimentare soluzioni insieme può essere di grande valore.

Come dimostrare che stiamo facendo un buon lavoro come Scrum Master?

Dimostrare che uno Scrum Master ha valore per un team e un’azienda è possibile. Anche se l’apporto è spesso indiretto e non molto visibile.

I fatti devono parlare per noi.

Una cosa molto semplice, evidente a tutti, è quella di dimostrare che ad ogni Sprint lo Scrum Team realizza incrementi “Done”, regolarmente. Secondo Ken Schwaber questo è il miglior indicatore possibile.

Altro indicatore è un team felice, che si diverte al lavoro.

Un buon modo per colmare quel gap fra la teoria e la pratica è quindi quello di misurare quello che stiamo producendo.

Senza voler andare nel dettaglio, ci sono metriche specifiche, grazie ad Evidence Based Management, che possono dare indicazioni precise su quale sia il valore del nostro prodotto.

Quindi fare Scrum bene vuol dire anche innescare un circolo virtuoso che migliora il prodotto e migliora anche noi stessi, come persone, come individui e come team.

Questo approccio empirico non solo sul prodotto ma anche su noi stessi ci permette di adattarci in continuazione a qualsiasi situazione.

Non c’è niente da fare, bisogna lavorare per capire come usare questo strumento che si chiama Scrum. Un pò come quando si vede un martello per la prima volta. A quelli che dicono che il martello non funziona, bisogna chiedere per quale obiettivo lo vogliono usare. Se lo usi per tagliare le unghie, ovviamente il risultato sarà deludente… forse anche un po’ doloroso 😊.

Comprensione teoricA e pratica di Scrum – Conclusioni

Per praticare Scrum Professionale è necessario colmare il divario tra comprensione teorica e pratica di Scrum stesso. E un lavoro continuo, che non finisce mai, in quanto anche Scrum evolve nel tempo, i problemi da risolvere cambiano ed evolvono.

Poco importa la seniority, uno Scrum Master Professionale dovrebbe avere sempre l’umiltà di rimettersi in discussione, imparare dagli altri e, quando richiesto, condividere le proprie esperienze.

Il primo passo rimane comunque la comprensione teorica e, in seguito, un’applicazione pratica perché l’esperienza è alla base dell’apprendimento.

Immersion Training per Scrum Master

Vuoi farti accompagnare nella riduzione del gap tra conoscenza e esperienza di Scrum Professionale? Abbiamo una proposta che stiamo sperimentando. Si chiama l’Immersion training.

Questo formato permette di alternare teoria e pratica in azienda. Il contenuto è uguale a quello della formazione Professional Scrum Master, ciò che cambia è il modo di imparare.

Proponiamo 7 sessioni di mezza giornata (la prima e l’ultima in presenza, le altre a distanza), fra una sessione e l’altra forniamo degli esercizi pratici da svolgere in azienda per mettere in pratica la teoria vista durante il corso.

Nella sessione successiva, prendiamo le esperienze e forniamo feedback su come ti puoi migliorare.

Per saperne di più visita la pagina web dove trovi anche le prossime date e puoi iscriverti se lo desideri!

7 ostacoli a Scum

7 ostacoli a Scrum

Continuo ad osservare 7 ostacoli a Scrum nelle aziende che aiuto nell’evoluzione verso la Business Agility. Piccoli o grandi che siano, questi ostacoli sono spesso l’eredità di una cultura aziendale nata e sviluppatasi negli anni della rivoluzione industriale.

Sono convinto che molto dipenda anche dal sistema scolastico (pur non avendone la prova, è solo un’intuizione) che non ci prepara a lavorare insieme, a collaborare.

7 ostacoli principali all'implementazione di Scrum nelle organizzazioni
Clicca l’immagine per ascoltare l’episodio del Podcast

E questo è un grosso freno quando dobbiamo risolvere problemi complessi.

Ecco un elenco, non esaustivo ed in ordine casuale, degli ostacoli che riducono i benefici che Scrum può portare all’azienda.

Sei d’accordo? Se vuoi aggiungerne altri, lascia un commento!

7 ostacoli a Scrum – Persone, non risorse

La cultura industriale ci ha portato a considerare le persone come macchine. Bisogna essere sempre performanti, non portarsi al lavoro i problemi che abbiamo a casa, sempre sorridenti, infallibili, perfetti al primo colpo.

In questa cultura il dirigente è il primo a dover essere infallibile, avere risposta a tutto, mai nessun dubbio… un robot.

Scrum e l’Agile rimettono l’essere umano al centro, ammettendo che si possono avere giorni positivi ed altri no; che si può dubitare di una soluzione (o di se stessi) e che il dubbio è positivo perché stimola la sperimentazione.

7 ostacoli a Scrum – Gerarchia

La gerarchia è utile quando non si ha necessità di prendere decisioni velocemente. Pertanto è un fattore limitante dell’Agile, dove si vuole agire prima di tutto, osservare il risultato ottenuto per poter capire se la strada intrapresa è quella giusta o no.

Agile significa movimento, sperimentazione, collaborazione… le decisioni che si prendono riguardano rischi limitati ad un mese al massimo, durante il quale si sperimenta per capire meglio la soluzione ad un problema dato.

Dover aspettare la decisione di qualcuno per poter fare qualcosa limiterà la vostra agilità.

Hai già visto un giocatore di Rugby aspettare l’autorizzazione del coach per poter agire? Quanto competitiva sarebbe una squadra del genere?

7 ostacoli a Scrum – Ego

I cinque valori fondamentali di Scrum illustrati
Clicca l’immagine per ascoltare l’episodio del Podcast

Contribuire allo sforzo del team con umiltà e dire il più rapidamente possibile quando si ha bisogno di aiuto. Mostrarsi infallibili e senza dubbi è abbastanza sospetto in un contesto di complessità.

Se l’ambiente di lavoro è sano, ci si sente al sicuro e non giudicati, probabilmente l’ego personale potrà essere messo da parte.

Considero l’ego come uno dei 7 ostacoli a Scrum, perché limita la trasparenza (uno dei pilastri dell’empirismo) e contraddice i valori Scrum, in particolare l’apertura.

Abbiamo tutti un certo livello di ego, chi più chi meno. Ci sta. Ciò che è importante è rendersene conto e lavorare per fare in modo che non sia deleterio per il team.

Il video qui sotto mi ha personalmente aiutato a capire perché l’ego può essere un problema, soprattutto quando ci impedisce di imparare (perché pensiamo di sapere già tutto).

Growth Mindset, perché è cosi importante oggigiorno?

7 ostacoli a Scrum – Dipendenze

Le dipendenze, di qualsiasi tipo, creano vincoli rischiosi che limitano l’agilità. Per esempio, se si è dipendenti da una sola persona per un certo tipo di competenza, quando questa persona sarà in vacanza è probabile che si potrà rimanere bloccati.

Ovviamente ci sono anche le dipendenze tecniche, che possono essere problematiche.

Essere agili significa essere resilienti alle situazioni più difficili, le dipendenze limitano la resilienza. Per questa ragione parliamo di Scrum Team cross-functional, che hanno tutte le competenze necessarie a risolvere un problema complesso.

Lo Scrum Team lavora per assicurarsi che nessuno sia indispensabile, ma tutti siano necessari!

Silos

Praticamente tutte le aziende con cui ho lavorato sono organizzate in silos. La logica è quella di ottimizzare un settore di attività, come il marketing per esempio.

Questa strategia funziona bene quando un prodotto è statico, evolve lentamente nel tempo. Come un tostapane 😊. In un mercato dove le novità sono lente ad arrivare al consumatore finale.

Nel settore informatico, per esempio, essere organizzati in silos è un problema grosso. Che diventa gigantesco quando combinato con la forte gerarchia e un pizzico di ego.

Il silo impedisce la collaborazione e, di conseguenza la trasparenza, con un impatto negativo sulla Business Agility.

Per questa ragione uno Scrum Team è auto-gestito, mette tutti sullo stesso livello e si focalizza su un obiettivo comune da raggiungere.

7 ostacoli a Scrum – Politica interna

L’organizzazione in silos obbliga a fare politica, alleanze, per portare acqua al proprio mulino (fare in modo che la priorità del Team diventi priorità di tutti).

Porta il focus delle persone su problemi interni, su decisioni che sono (forse) utili per fare carriera, ottenere un bonus… ma che distraggono dalla ragione per la quale lavoriamo, ossia creare qualcosa di utile per qualcuno (valore).

La politica interna, conseguenza abbastanza normale dell’organizzazione in silos, porta a perdere di vista l’obiettivo principale dell’azienda: creare valore per gli utilizzatori dei propri prodotti.

7 ostacoli a Scrum – Burocrazia

La burocrazia, un’altro dei 7 ostacoli a Scrum, utile per garantire il controllo del lavoro ripetitivo (contabilità, rischi operativi, ecc.), è una catastrofe per l’agilità dell’azienda. Obbligare uno Scrum Team a sottostare alle stesse regole burocratiche del servizio contabilità (per esempio) è un grave errore.

In contesti complessi, la burocrazia dovrebbe essere ridotta al minimo. Favorire linee guida e regole semplici ed incrementali basate sull’esperienza è una migliore soluzione, più agile.

Conclusioni

Mi sono divertito a fare come nell’agile manifesto, mettendo in contrapposizione ciò che favorisce un contesto agile da ciò che l’ostacola, ecco il risultato.

Favorevole all’agilitàSfavorevole all’agilità
PersonePiuttosto cheRisorse
Auto-GestionePiuttosto cheGerarchia
UmiltàPiuttosto cheEgo Personale
AutonomiaPiuttosto cheDipendenze
Cross-FunctionalPiuttosto cheSilos
ValorePiuttosto chePolitica interna
Linee GuidaPiuttosto cheBurocrazia
A sinistra riconosco i fattori stimolanti per l’agilità aziendale, pur riconoscendo che gli elementi a destra possono essere necessari in contesti non complessi.

Ti ritrovi nei 7 ostacoli a Scrum che ho descritto? Li osservi nella tua azienda? Nulla di grave, è piuttosto normale perché questo permette di far funzionare correttamente il lavoro quotidiano. In ogni caso ha permesso di farla funzionare fino ad oggi 😊.

Tuttavia, bisogna prendere coscienza che la perdita di competitività dovuta all’incapacità di reagire rapidamente alle domande del mercato è un problema che stanno affrontando diverse realtà.

Uno Scrum Master Professionale ha la responsabilità di rivelare e far capire che ciò che funziona bene in un contesto ripetitivo e prevedibile non è in realtà molto utile per risolvere problemi complessi.

Allora non perdere tempo, costruisci argomenti solidi per far capire ed utilzzare Scrum correttamente. Questo permetterà di limitare i rischi e aumentare la Business Agility aziendale. Scrum On! 💪

Per ricevere i nuovi articoli in anteprima, abbonati. Pubblichiamo più o meno un articolo al mese. Puoi annullare l’iscrizione in qualsiasi momento.