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.
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à.
In questo episodio esploriamo come lo Scrum Master agisce da vero agente del cambiamento organizzativo, guidando team e azienda verso una maggiore agilità. Scopriremo le strategie pratiche e gli approcci concreti che uno Scrum Master utilizza per promuovere il cambiamento e migliorare l’efficacia dell’organizzazione, come illustrato nell’omonimo articolo del blog.
🎧 Ascolta l’Episodio
🎯 Ruolo dell’Agente del Cambiamento
Lo Scrum Master come agente del cambiamento si concentra su:
Identificazione delle aree di miglioramento nell’agilità del team
Supporto al team nel raggiungimento di una maggiore qualità del prodotto
Accelerazione del time-to-market
Incremento della soddisfazione del cliente attraverso feedback rapidi
Lo Scrum Master efficace è molto più di un facilitatore di eventi – è un vero agente del cambiamento che, attraverso osservazione, dati e proposte concrete, guida l’organizzazione verso una maggiore agilità. Il suo impatto si misura nella capacità di trasformare gli ostacoli in opportunità di miglioramento
Fabio Panzavolta, Professional Scrum Trainer
🔜 Prossimo Episodio
Non perdete il prossimo episodio dove approfondiremo le tecniche avanzate di facilitazione per Scrum Master.
Questo articolo è basato sull’episodio 45 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.
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
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.
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
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.
Saper fissare gli obiettivi in Scrum è un elemento chiave per massimizzare il valore rilasciato agli utenti del prodotto.
Alla fine di questo articolo saprai che cos’è un Product Goal ed uno Sprint Goal, come usarli per aumentare il focus, l’autonomia e controllare i rischi di uno Scrum Team.
Uno degli aspetti fondamentali dello sviluppo empirico di prodotti è quello di far emergere le soluzioni a problemi identificati. Per farlo, un’obiettivo chiaro permette di cambiare il focus dalle “esigenze da sviluppare” (spesso senza sapere realmente il perché) a un risultato che si vuole ottenere per gli utenti del prodotto (senza che le funzionalità per farlo siano tutte previste in anticipo).
Uno Scrum Master ha la responsabilità di far capire questo concetto allo Scrum Team ed all’azienda. Vediamo un modo di fare…
⚠️ Questo articolo contiene contenuto riservato ai soli utenti registrati. Se non hai ancora un account o non hai effettuato l’accesso è il buon momento per farlo e ritornare qui! ⚠️
Il Product Goal è l’obiettivo a medio termine in Scrum, definito dal Product Owner, permette di fare un passo in più verso la visione del prodotto.
Questo è un “commitment” in Scrum, il che significa che tutto lo Scrum Team si impegna a raggiungerlo contribuendo con le proprie competenze.
Quando un Product Goal è raggiunto, se ne crea uno nuovo. Ovvero non possono esistere due (o più) Product Goal in parallelo.
Clicca l'immagine per ascoltare l'episodio del podcast
Gli obiettivi in Scrum – lo Sprint Goal
Lo Sprint Goal è l’obiettivo a corto termine, definito dallo Scrum Team, che permette di fare un passo in più verso il raggiungimento del Product Goal
Anche questo è un “commitment” in Scrum, l’unica cosa che non può cambiare durante uno Sprint. Se lo Sprint Goal diventa obsoleto, allora il Product Owner può decidere di annullare lo Sprint e ricominciare con un nuovo Sprint Goal (caso molto raro).
Clicca l'immagine per ascoltare l'episodio del podcast
Esempi di obiettivi
Per capire meglio ecco degli esempi di Product Goal e Sprint Goal che considero corretti. Propongo diversi esempi di Sprint Goal per uno stesso Product Goal, l’ordine è completamente casuale.
Da questi esempi si possono evincere diverse cose:
Il Product Goal è raggiungibile con una serie di Sprint
C’è una coerenza fra Product Goal e Sprint Goal
Lo Sprint Goal è un esperimento che lo Scrum Team vuole fare, non una lista di features da implementare
I Goal in Scrum forniscono una direzione, non il dettaglio del lavoro da fare
I Goal in Scrum motivano il team a trovare soluzioni a problemi complessi
I Goal devono essere ambiziosi. Se avete la certezza che il goal sarà raggiunto alla fine dello Sprint, chiedetevi come potete renderlo più ambizioso
I Goal servono a controllare i rischi, in quanto ci aiutano a capire cosa siamo capaci di fare e cosa no. Ma anche a capire cosa ci manca per raggiungere un goal.
I Goal motivano le persone a dare il meglio di se per contribuire alla riuscita! Capisco che la mia competenza ha un senso ed è utile a ciò che stiamo facendo. So che da solo non potrei fare quello che stiamo facendo insieme!
Roadmap e obiettivi
Il Product Goal può essere utile per dare una visione del futuro, una roadmap da condividere con gli stakeholders.
Se il Product Owner attualmente non è capace di fornire trasparenza sulla sua strategia, allora lo Scrum Master può intervenire per aiutarlo.
Detto questo, bisogna fare attenzione a come si comunica una roadmap, in quanto l’approccio empirico di Scrum abbraccia il cambiamento e rende il futuro non (totalmente) prevedibile.
Per aiutare i Product Owner, uso spesso una versione adattata del modello di Roadmap che trovi sul sito The Product Manager di Roman Pichler (una referenza).
Scarica il modello di Roadmap
Per aiutarti a progredire nell’utilizzo di obiettivi e roadmap, ho creato un modello ed un esempio che puoi usare nel tuo contesto lavorativo. Fammi sapere se ti è stato utile nei commenti!
Non inviamo spam e le tue informazioni sono protette. Puoi cancellare la tua iscrizione in qualsiasi momento contattandoci.
Conclusioni
Avere degli obiettivi comprensibili da tutti, ispiranti e trasparenti è un passo fondamentale verso la business agility.
Se è difficile trovare un solo Product Goal e un solo Sprint Goal per Sprint, allora vuol dire che c’è qualcosa che non va a livello di definizione del prodotto. Oppure che il lavoro è talmente orientato all’implementazione di una serie di task non coerenti gli uni con gli altri che la definizione di un obiettivo diventa praticamente impossibile.
Se questo è il caso tuo, capire come funziona Scrum e quali sono le responsabilità di un Product Owner in Scrum è un buon primo passo.
In questo episodio esploriamo il concetto di “guidare con i valori Scrum”, dall’articolo del blog, attraverso un caso pratico di leadership Scrum. Scopriremo come i valori Scrum guidano il processo decisionale e contribuiscono a creare un ambiente di lavoro efficace, attraverso la storia di un Developer alle prese con una decisione importante.
In un’epoca dove la risoluzione di problemi complessi richiede approcci innovativi, il ruolo del Servant Leader diventa fondamentale. Non abbiamo bisogno di più manager tradizionali, ma di leader che sappiano guidare attraverso i valori, creando ambienti di lavoro dove le persone si sentono sicure nel prendere decisioni coraggiose e allineate con gli obiettivi del team
Fabio Panzavolta, Professional Scrum Trainer
🔜 Prossimo Episodio
Non perdete il prossimo episodio del podcast Scrum Italia dove continueremo ad esplorare temi fondamentali per la crescita professionale in ambito Agile.
Questo articolo è basato sull’episodio 44 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.
Leading with values è il seguito dell’articolo che ho scritto il mese scorso, il management in Scrum. Ti racconto una storia che uso spesso in formazione, un fatto che mi è capitato qualche mese fa da un cliente.
Il contesto
Clicca sull’immagine per ascoltare l’episodio del podcast
Stavo aiutando uno Scrum Team a praticare Scrum, nel contesto della creazione di un prodotto che includeva hardware e software.
Avevamo cominciato lo Sprint da un pò più di una settimana, lo Sprint Goal era chiaro e ben visibile a tutti, i Developers stavano lavorando insieme per raggiungerlo il più velocemente possibile.
Leading with values – La storia
Stavo passeggiando nell’open space, quando uno dei Developers, Luca, mi viene incontro e mi chiede: “Fabio, un altro team ha bisogno del mio aiuto. Sono bloccati e sono l’unico a poterli aiutare. Mi sai dire cosa devo fare?”.
Ci penso e gli rispondo: “purtroppo non so dirti cosa fare, ma possiamo ragionarci insieme, poi sarai tu a decidere, ti va bene?”.
Luca: “Si ok grazie, volentieri!”.
Fabio: “Bene! Come sta andando lo Sprint?”.
Luca: “Stiamo facendo un gran lavoro, impariamo tanto e allo stesso tempo non sappiamo se riusciremo a fare tutto in questo Sprint”.
Fabio: “Capito… mi puoi ricordare lo Sprint Goal, che mi sono dimenticato?”. Non era assolutamente vero, ma avevo bisogno di capire se Luca lo aveva ben in mente.
Luca: “Dobbiamo dimostrare di essere capaci di costruire da A a Z un nuovo prototipo in due settimane. Questo è lo Sprint Goal che ci siamo dati. Come sai abbiamo uno Sprint di tre settimane, ma prima di questo Sprint non siamo mai riusciti a fare questa cosa in meno di cinque settimane… quindi è una vera sfida per noi”.
Fabio: “Si, adesso ricordo, grazie… e come sta andando? Ho visto il vostro burndown chart e mi sembrate messi bene, corretto?”.
Luca: “Dopo un pò più di una settimana di lavoro c’è meno ansia, abbiamo acquistato fiducia e pensiamo onestamente di farcela a raggiungere l’obiettivo. Per questo, visto che i ragazzi di un altro team hanno bisogno di me per sbloccare una situazione, pensavo di lasciare il team per qualche giorno per andarli ad aiutare”.
Fabio: “Si capisco, mi sembra logico. Ma se lasci il team per qualche giorno, pensi che lo Sprint Goal attuale sia in pericolo o no?”.
Clicca sull’immagine per ascoltare l’episodio del podcast
Luca: “Onestamente c’è il rischio che il team abbia interruzioni dovute alla mia assenza, quindi si, un pò di pericolo c’è”.
Fabio: “OK, quindi pensa al commitment che hai preso in Sprint Planning quando hai dato il tuo accordo per lo Sprint Goal. L’obiettivo sarebbe a rischio se tu lasciassi il team attuale, anche solo per qualche giorno?”.
Luca, dopo qualche tempo di riflessione: “Ho capito, rimango nel team attuale. Il significato di commitment e l’importanza dello Sprint Goal sono più chiari ora. Dirò all’altro team che sono disponibile fra due settimane, se ho difficoltà mi potrai dare una mano per affermare la mia posizione?”.
Fabio: “certo, puoi contare su di me. Grazie per il tuo coraggio nel prendere questa decisione”.
Leading with Values – Conclusione
E così è andata… leading with values significa aver capito che il nostro comportamento e le nostre scelte sono guidate dai cinque valori Scrum: “Commitment, Courage, Respect, Openness, Focus”.
Abituati a far domande che aiutano i colleghi a ragionare, ricorda quali sono i limiti da non oltrepassare, crea un ambiente dove ci si sente sicuri per prendere certe decisioni e supporta le persone che hanno il coraggio di agire allineandosi con i valori. Continua fino a quando ti farai sorprendere dai colleghi, perché li vedrai prendere decisioni, fare esperimenti ed avere comportamenti che non vedevi prima. Questo vorrà dire che hai fatto un buon lavoro e potrai imparare a tua volta da loro!
Se lavori alla risoluzione di problemi complessi, in contesti di “produzione intellettuale” (software, sales, marketing, ecc.), allora devi prendere in seria considerazione un cambiamento personale come quello che ho descritto.
Nell’epoca attuale abbiamo disperatamente bisogno di più servant leader che manager, qui sotto condivido qualche risorsa da studiare per capire come diventare un miglior leader.
Scrum Coaching
Hai bisogno di uno Scrum coach per il tuo team? Contattami, posso aiutarvi!
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:
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 è 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.
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“).
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).
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 lavorofatto 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.
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
In questo episodio sulla corretta implementazione di Scrum, Fabio Panzavolta e Stefano Milanesi, entrambi Professional Scrum Trainer, condividono strategie pratiche per un’efficace trasformazione agile. Attraverso le loro esperienze come Scrum Master professionali, esplorano come superare le sfide comuni nell’applicazione pratica di Scrum e forniscono consigli concreti per un coaching Scrum efficace nelle organizzazioni. Leggi l’articolo associato a questo podcast.
🎧 Ascolta l’Episodio
🎯 Le Sfide nell’Implementazione di Scrum
Ostacoli comuni nell’applicazione pratica Scrum nelle organizzazioni
Un’implementazione Scrum efficace richiede più della semplice conoscenza teorica. Come Scrum Master professionali, dobbiamo saper guidare la trasformazione agile con coraggio e determinazione, applicando il framework nel modo corretto per il contesto specifico
Fabio Panzavolta, Professional Scrum Trainer
Il successo nell’implementazione Scrum si misura non solo attraverso i risultati del prodotto, ma anche attraverso la crescita delle persone e la maturità della trasformazione agile
Stefano Milanesi, Professional Scrum Trainer
🔜 Prossimo Episodio
Non perdere il prossimo episodio del podcast Scrum Italia, parleremo del management in Scrum!
Questo articolo è basato sull’episodio 42 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.
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
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.
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.
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
Per fornire le migliori esperienze, utilizziamo tecnologie come i cookie per memorizzare e/o accedere alle informazioni del dispositivo. Il consenso a queste tecnologie ci permetterà di elaborare dati come il comportamento di navigazione o ID unici su questo sito. Non acconsentire o ritirare il consenso può influire negativamente su alcune caratteristiche e funzioni.
Funzionale
Sempre attivo
L'archiviazione tecnica o l'accesso sono strettamente necessari al fine legittimo di consentire l'uso di un servizio specifico esplicitamente richiesto dall'abbonato o dall'utente, o al solo scopo di effettuare la trasmissione di una comunicazione su una rete di comunicazione elettronica.
Preferenze
L'archiviazione tecnica o l'accesso sono necessari per lo scopo legittimo di memorizzare le preferenze che non sono richieste dall'abbonato o dall'utente.
Statistiche
L'archiviazione tecnica o l'accesso che viene utilizzato esclusivamente per scopi statistici.L'archiviazione tecnica o l'accesso che viene utilizzato esclusivamente per scopi statistici anonimi. Senza un mandato di comparizione, una conformità volontaria da parte del vostro Fornitore di Servizi Internet, o ulteriori registrazioni da parte di terzi, le informazioni memorizzate o recuperate per questo scopo da sole non possono di solito essere utilizzate per l'identificazione.
Marketing
L'archiviazione tecnica o l'accesso sono necessari per creare profili di utenti per inviare pubblicità, o per tracciare l'utente su un sito web o su diversi siti web per scopi di marketing simili.
Professional Scrum Facilitation SkillsFascia di prezzo: da 695,00 € a 795,00 €
Professional Scrum Master™Fascia di prezzo: da 1295,00 € a 1395,00 €
