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!
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
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
Ma Scrum funziona veramente? Questa domanda un pò provocatoria è venuta fuori come tema in una delle puntate del podcast Scrum 🇮🇹.
Clicca l’immagine sopra per ascoltare il podcast
Ho avuto il piacere di sedermi con alcuni dei più brillanti Scrum Master professionisti per discutere di un argomento che ci sta a cuore: l’agilità e, in particolare, Scrum.
Grazie di ❤️ a Silvia, Emanuele, Alessandro e Mike per essersi prestati all’esercizio!
Podcast Scrum Italia – Ep. 40 – Ma Scrum funziona veramente?
Ma Scrum funziona veramente? – Ecco i punti forti della nostra chiacchierata.
🚀 Cultura e Mindset: Alessandro ha sollevato un punto cruciale sulla necessità di un cambiamento culturale nelle organizzazioni. Lontani dai Gantt e dai rigidi controlli, è tempo di abbracciare l’autonomia e l’empirismo.
🔍 Empirismo vs Predizione: Io stesso ho sottolineato come molti affermino di usare Scrum senza abbracciarne la natura empirica. Ricordate, prevedere il futuro in un mondo complesso è un’illusione; ciò che conta è rimuovere gli ostacoli e cambiare mentalità.
👥 Autonomia del Team: Michael ha condiviso una storia di successo su come l’empowerment di un giovane team ha portato alla consegna anticipata di un prodotto funzionante. Piccoli cambiamenti possono fare la differenza!
📈 Disciplina nell’applicazione: Alessandro ha ribadito che l’applicazione rigorosa dei concetti può portare al successo, coinvolgendo i clienti e dimostrando l’efficacia del nostro approccio.
🌱 Cultura di squadra: Silvia ha parlato dell’importanza di coltivare una cultura di comprensione e di possesso del metodo Scrum a livello di team, mentre Emanuele ha evidenziato come le retrospettive genuine abbiano rafforzato il senso di squadra.
Questi sono solo alcuni degli spunti che abbiamo esplorato nel nostro ultimo episodio. Se sei curioso.a di scoprire come queste idee possano essere applicate e di ascoltare le storie personali dei miei ospiti, non puoi perderti questo episodio del podcast.
Sintonizzati per un viaggio nel cuore dell’agilità e scopri come piccole modifiche possano portare a grandi risultati. Non vedo l’ora di condividere con voi queste conversazioni illuminanti!
Un abbraccio e fino al prossimo ascolto, Fabio 🎙️
P.S. Ricordate, l’agilità è un viaggio, non una destinazione. Siate coraggiosi, sperimentate e adattatevi. Il vostro team vi ringrazierà!
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!
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.
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.
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!
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.
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
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!
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.
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à
Persone
Piuttosto che
Risorse
Auto-Gestione
Piuttosto che
Gerarchia
Umiltà
Piuttosto che
Ego Personale
Autonomia
Piuttosto che
Dipendenze
Cross-Functional
Piuttosto che
Silos
Valore
Piuttosto che
Politica interna
Linee Guida
Piuttosto che
Burocrazia
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.
Scrum: performance e risultato è una riflessione su quanto sia necessario distinguere la performance e la “casualità” del risultato.
Recentemente, durante una formazione Applying Professional Scrum, ho condiviso la differenza che esiste fra performance e risultato con un esempio sportivo.
Clicca l’immagine per ascoltare il podcast
La performance, se pensiamo alla corsa a piedi, corrisponde al passo che riusciamo a riprodurre regolarmente, per esempio 6min/km di media.
Questo dato ci permette di dedurre che una semi-maratona è fattibile in poco più di 2 ore.
Il risultato dipende da tanti fattori, alcuni dei quali al di fuori del nostro controllo. Sono i famosi “unknown/unknown”… o semplicemente la sfiga 🙂
Il giorno della semi-maratona ci si sveglia con il mal di pancia, la corsa probabilmente non andrà come previsto (esperienza personale 😊).
Il risultato è diverso dalle performance passate. Questo è imprevedibile e fa parte dell’incertezza che non possiamo controllare. Ma che si deve accettare.
In un contesto complesso, il risultato non si può comprare. Se cercano di vendervelo, scappate!
Fabio
Performance
Scrum: performance e risultato
Definizione del dizionario: in senso generico, realizzazione concreta di un’attività, di un comportamento, di una situazione determinata (ref Treccani)
La performance è qualcosa che richiede allenamento, perseveranza, miglioramento continuo. Un team, per poter diventare performante, ha bisogno di tempo, di sicurezza psicologica, di commettere errori per imparare. Nel mondo professionale in cui viviamo, si esige la performance dal primo giorno. Ovviamente è impossibile. Ancora peggio, non si fa nulla per aumentare la performance del team, si guarda al risultato individuale.
È l’accountability dello Scrum Master quella di aiutare il team a capire e usare Scrum correttamente per ottenere un team performante. A seconda del contesto lavorativo e delle persone nel team per ottenere una performance accettabile ci vorrà più o meno tempo.
Qui sotto trovi l’episodio del nostro podcast Scrum 🇮🇹 nel quale parlo dello Scrum Master.
Clicca l’immagine per ascoltare il podcast
Scrum: performance e risultato – come si riconosce uno Scrum Team performante?
Ci sono tre fattori che, secondo me, rivelano un team performante.
Uno Scrum Team performante è capace di rilasciare uno o più Increment Done nel corso di uno Sprint, ad ogni Sprint. Esattamente come per la corsa a piedi, inizialmente un Increment Done sarà composto da pochi elementi del Product Backlog, con il tempo, il team sarà capace di realizzarne sempre di più, a qualità costante o migliore.
Un’altro segno distintivo che la performance esiste, è un team felice e motivato a fare meglio. Un team che trova autonomamente e rapidamente correzioni agli ostacoli che incontra.
Altra caratteristica di un team performante: nessuno chiede il permesso di fare qualcosa, tutti sanno qual’è l’obiettivo e il lavoro da fare per tentare di raggiungerlo (trasparenza).
Per ottenere un team di questo tipo, l’apporto di uno Scrum Master è fondamentale. È un lavoro che richiede tempo, competenza, dedizione.
Se lo Scrum Master lavora anche come Developer o, addirittura, su più prodotti allo stesso tempo, ovviamente il tempo per ottenere un team efficace si allungherà.
Nell’episodio del podcast Scrum 🇮🇹 che trovi qui sotto, condivido vantaggi ed inconvenienti della doppia responsabilità Scrum Master / Developer.
Risultato
Risultato: ciò che risulta come esito definitivo e conclusivo di un’azione, un’attività o un’operazione (ref. Treccani)
Il risultato è una cosa diversa dalla performance. È perfettamente possibile ottenere risultati mediocri con un team performante e viceversa (grazie alla fortuna). Le due cose sono sconnesse.
Clicca l’immagine per ascoltare il podcast
Un team performante avrà più probabilità di ottenere buoni risultati se il Product Owner capisce la propria responsabilità: massimizzare il valore del prodotto. Che vuol dire avere il coraggio di fare piccoli esperimenti per capire se la direzione presa è quella giusta.
E qui si dovrebbe capire come Scrum, nella sua semplicità, è potente.
Un Product Owner incapace (per diverse ragioni) di fornire una direzione chiara, che non ha il gusto della sperimentazione, probabilmente porterà il team ad avere risultati mediocri oppure, tutt’al più equivalenti a quelli che già si hanno.
Un Product Owner sostenuto e rispettato dall’azienda, capace di prendere iniziative coraggiose, di sperimentare e osare probabilmente otterrà uno dei due risultati possibili che mi vengono in mente: successo o esperienza necessaria ad ottenere successo in futuro.
Nel video qui sotto, un pò datato ma ancora d’attualità, condivido quanto le tre responsabilità di Scrum siano necessarie per la performance.
Scrum: performance e risultato – come si ottengono i risultati?
Uno Scrum Team ottiene una migliore comprensione dei risultati che può raggiungere quando:
ha una visione e un Product Goal chiari, quindi un Product Owner che condivide una strategia
è capace di “ascoltare” i propri utilizzatori, per proporre soluzioni
ha l’umiltà di pensare che le soluzioni sono ipotesi di successo e necessitano il feedback dell’utilizzatore per sapere se “funzionano”
è capace di fornire incrementi di prodotto di qualità impeccabile
sa rimettersi in discussione e trovare nuove soluzioni
Conclusione
In conclusione, performance e risultati sono due cose diverse. Darsi il tempo per crescere e sperimentare è importante per ottenere un team performante e, forse, ottenere risultati.
Il successo non si compra, il successo è il risultato di un duro lavoro. Chiedere agli sportivi di professione per conferma.
Scrum professionale ci prepara alla performance e ci fa comprendere ed accettare che il risultato è spesso frutto di un duro lavoro di collaborazione fra il produttore ed il consumatore.
Superare il concetto di ritardo con Scrum è possibile! In un mondo in cui le scadenze sono spesso un pilastro cruciale, l’approccio di Scrum può inizialmente suscitare dubbi e scetticismo. La flessibilità apparente delle funzionalità da sviluppare può sembrare controintuitiva, ma è proprio questa caratteristica che rende Scrum un approccio ideale per affrontare problemi complessi in modo empirico. Questo articolo esplora come il concetto di “ritardo” si trasforma in un’opportunità di crescita, quando Scrum è applicato con competenza. Clicca qui, o nell’immagine qui sotto, per ascoltare l’episodio del Podcast Scrum 🇮🇹.
Clicca l’immagine per ascoltare il podcast
Affrontare la complessità empiricamente
L’idea di essere in ritardo presuppone una conoscenza completa e certa delle variabili coinvolte in quello che si sta facendo.
In tutta onestà, nel tuo progetto, puoi immaginare una cosa del genere? Nel contesto aziendale, le variabili sono spesso innumerevoli e i percorsi da seguire sono, molto spesso, incerti. Bisogna farsene una ragione.
L’approccio Scrum sfida questa prospettiva. Accetta l’incertezza come un dato di fatto e si basa su iterazioni brevi e feedback costante per adattarsi alle sfide emergenti. Questo significa che le “scadenze rigide di un’insieme di funzionalità” vengono trasformate in obiettivi, consentendo al team (ed al cliente!) di adattarsi ai cambiamenti e di affrontare la complessità con una mentalità aperta. Le funzionalità diventano variabili, in quantità e granularità (nel senso finezza di sviluppo).
Il Product Owner riveste un ruolo fondamentale nell’orientare il team verso il successo. Invece di considerare le scadenze come funzionalità statiche, il focus si sposta sugli obiettivi del prodotto. Il Product Owner, grazie alla sua conoscenza del contesto business e dei clienti, è capace di fissare Product Goals, stabilendo un legame chiaro tra le attività del team e l’obiettivo attraverso il contenuto del Product Backlog.
Superare il concetto di ritardo con Scrum, significa avere un Product Owner che sia libero di fissare Product Goals chiari e misurabili.
L’Empirismo in azione: Sprint dopo Sprint
Le Basi di Scrum – Cos’è Scrum?
Un aspetto distintivo di Scrum è lo Sprint, in cui il team affronta una parte specifica del lavoro in un periodo di tempo definito. Ogni Sprint è un passo in avanti verso un Product Goal e realizza le funzionalità del Product Backlog coerenti con questo obiettivo.
L’empirismo è alla base di ogni Sprint. Le funzionalità vengono sviluppate in modo iterativo, consentendo al team (e agli Stakeholders) di apprendere e adattarsi man mano che la conoscenza e l’esperienza cresce. Il coinvolgimento del cliente alla fine di ogni Sprint garantisce un feedback tempestivo, orientando ulteriormente il percorso del progetto.
Costruire Fiducia e Valore
L’approccio Scrum, se implementato con maestria, produce risultati che spazzano via l’angoscia del ritardo. Oltre a raggiungere i tradizionali obiettivi di progetto, il processo crea elementi di valore che vanno oltre il mero rispetto delle scadenze:
1. Fiducia: Ogni Sprint dimostra il progresso costante del team, costruendo fiducia sia internamente che verso i clienti o gli stakeholder.
2. Prodotto Funzionante: ogni Sprint porta a un incremento di prodotto funzionante, anche se non corrisponde esattamente alla visione iniziale. Questo approccio guidato dal feedback produce un prodotto di valore reale.
3. Agilità per il futuro: la flessibilità di Scrum consente al team di adattarsi rapidamente ai cambiamenti. Man mano che si apprende e si cresce, il team può perseguire nuove direzioni o eliminare funzionalità superflue.
Superare il concetto di ritardo con Scrum: affrontare le Sfide Comuni
Sebbene Scrum offra un approccio valido, le sfide possono emergere. La mancanza di risorse, la mancanza di interazione con il cliente e altri ostacoli possono minare l’efficacia dell’approccio. In queste situazioni, la collaborazione diventa fondamentale. I membri del team, gli stakeholder e l’azienda devono lavorare insieme per comprendere le priorità reali, mantenendo la qualità e il benessere del team al centro dell’attenzione.
In sintesi, Scrum si dimostra un’arma potente per affrontare il concetto tradizionale di “ritardo”. Il suo approccio empirico, basato su feedback costante, flessibilità e adattabilità, trasforma le sfide in opportunità di crescita e successo. Se applicato con dedizione e competenza, Scrum guida il team verso la fiducia, il valore e una gestione più efficace dei progetti complessi.
Con scrum.org, la nostra missione consiste ad aiutarvi a risolvere problemi complessi, qui sotto trovate alcuni dei corsi che potranno aiutarvi a capire meglio come superare il concetto di ritardo con Scrum!
Scrum e la reazione autoimmune aziendale è una riflessione sulla mia esperienza dell’applicazione di Scrum professionale in azienda. Rivela i meccanismi socio-aziendali, ai quali ho assistito, che impediscono di trarre massimo beneficio dallo sviluppo empirico di un prodotto.
Clicca l’immagine per ascoltare il podcast
Ovviamente non sono un esperto in campo medico, mi scuso in anticipo se certi paralleli o nozioni sono incorrette da questo punto di vista.
Il parallelo fra Scrum Professionale (considerata come “sostanza sana” quando si pensa allo sviluppo di prodotti complessi) e gli anticorpi aziendali (che dovrebbero riconoscere Scrum come “amico”, ma non lo fanno, scatenando una reazione anomala di distruzione autoimmune) mi è venuto da tempo e penso possa essere una buona metafora per rappresentare le sfide che ci aspettano in azienda.
Qual’è un ambiente di lavoro considerato come “sano” in un contesto di complessità?
Un ambiente di lavoro “sano” consiste in pochi principi, ma importanti:
Anticorpo
Servant Leadership: dei dirigenti e manager che sono al servizio delle persone che lavorano, per aiutarle ad abbattere gli ostacoli che impediscono di creare prodotti complessi (burocrazia, procedure, silos, gerarchie, etc.)
Psychological Safety: trovarsi in un ambiente di lavoro che permette di imparare velocemente, eventualmente celebrando gli errori che fanno parte del processo di apprendimento
Responsabilità chiare: un capitano, il Product Owner, delle competenze per dirigere la nave e esplorare soluzioni (i Developers), una persona che conosce bene le regole del gioco (lo Scrum Master)
Focus alla risoluzione di problemi o opportunità: capire bene per chi si lavora e come si può soddisfare
Ownership condivisa: grazie ad obiettivi chiari
Video un pò datato, ma ancora valido. Scusate il suono orribile.
Il sistema immunitario aziendale
Un’azienda tradizionale è stata concepita secondo un modello di produzione industriale, trarre massimo profitto dalla produzione di massa. È il sistema immunitario aziendale. Di conseguenza, è normale osservare:
Command & Control: il management dice ai lavoratori cosa (e, a volte, come) devono fare il lavoro
Sanzione dell’errore: se non si mantiene la parola data, o qualcosa va storto, saltano teste
Responsabilità sparsa: su diverse persone, con due risultati possibili (decisioni lente, oppure immobilismo)
Carriera: le persone gerarchicamente di alto livello hanno uno stipendio migliore, concorrenza interna, politica
Focus su funzionalità: senza pensare o chiedere agli utenti il loro feedback
Silos: ossia funzioni ottimizzate per produrre un certo tipo di output come, per esempio, marketing, informatica, sales, etc.
Burocrazia: processi e procedure per assicurarsi che ogni tipo di input crea un preciso output in qualsiasi situazione
Scrum e la reazione autoimmune aziendale
Quando Scrum Professionale arriva in azienda, si osserva la reazione autoimmune aziendale, che lo riconosce come una minaccia e lo attacca, in maniera più o meno evidente.
Fabio Panzavolta
Nella mia esperienza ho potuto osservare le reazioni autoimmuni seguenti, in ordine casuale e non esaustivo:
L’adattamento di Scrum all’azienda: ossia modificarlo profondamente per farlo entrare nei processi aziendali, mantenere le gerarchie ed i controlli esistenti. Qualche esempio:
Nominiamo due Product Owner, uno business e uno tecnico. Invece di una sola persona, con la conseguenza di creare disordine e difficoltà a prendere decisioni.
Selezioniamo gli eventi Scrum che ci fanno più comodo. Limitando la capacità a lavorare in modo empirico e, di fatto, mantenendo il lavoro a cascata (waterfall)
Imponiamo una quantità di lavoro ai Developers, gli obiettivi sono inutili. Annullando l’autogestione, l’ownership e la responsabilità
Facciamo a meno dello Scrum Master, non serve a niente. Alimentando il massacro di Scrum, in quanto non c’è più nessuno che può aiutare a combattere gli anticorpi.
L’autogestione da noi non funziona: continuiamo a scrivere specifiche, assicurandoci che siano seguite alla lettera e nei tempi stabiliti. E poi serve comunque qualcuno che gestisca il team, altrimenti il lavoro non va avanti
La pressione è necessaria per far lavorare le persone: quindi imponiamo date di fine all’inizio del progetto, su scope fisso e chiediamo il commitment a tutto il team. Sacrificando la qualità e l’innovazione
Il reporting è fondamentale: dobbiamo sapere come vanno le cose per poter prendere decisioni. Il team non è in grado di farlo. Controllare le persone è più facile rispetto al controllo degli obiettivi e delle performance del prodotto.
Ci sono tante altre reazioni autoimmuni, quali osservi nel tuo lavoro? Scrivilo nei commenti!
Quali sono le cure alla reazione autoimmune?
Se hai riconosciuto almeno una reazione autoimmune fra quelle elencate, non tutto è perduto, esistono delle cure 😊. Più o meno invasive.
L’ideale consiste a cominciare a lavorare con Scrum per scatenare le reazioni autoimmuni, osservarle e renderle trasparenti. In poche parole bisogna avere il coraggio di non seguire la corrente.
Fabio Panzavolta
Un piccolo team, di qualche persona, che lavora secondo i principi di Scrum, rivelerà molte cose che non funzionano in azienda.
Una volta rivelati i disfunzionamenti aziendali, l’obiettivo è quello di curare la reazione autoimmune, non cambiare Scrum.
Bisogna fare tutto ciò che è necessario per far riconoscere Scrum come “sostanza sana” e far progredire la sua comprensione/applicazione, per l’interesse dell’azienda e degli utilizzatori dei prodotti.
La brutta notizia è che la soluzione miracolo non esiste, bisogna sperimentare approcci diversi, a seconda del contesto, per capire cosa funziona meglio.
La buona notizia è che, dal momento che si vedono progressi nel sistema azienda, anche minimi, allora vuol dire che le cose evolvono. Ci vuole pazienza e perseveranza ed anche un buon grado di accettazione che la reazione autoimmune potrebbe vincere.
Vediamo qualche cura possibile da sperimentare.
Ristabilire la Psychological Safety – Team Manifesto
Per prima cosa lavorare nel contesto dello Scrum Team, che deve assolutamente capire che certi comportamenti e decisioni sono necessari quando si crea un prodotto complesso. Quindi la nozione di quello che è “giusto o sbagliato” cambia. Questa può essere una vera sfida per quei team composti in parte da dipendenti e in parte da contractors.
Questo è un lavoro che si fa mettendo al centro i Valori Scrum (coraggio, rispetto, apertura, focus, commitment), assolutamente fondamentali per comportarsi in modo consono ad un contesto complesso.
Scrum e la reazione autoimmune aziendale – Clicca l’immagine per accedere al contenuto
Il Team Manifesto è necessario per rendere trasparente la nozione di coraggio (ad esempio) per ogni membro del team, riconoscere e mettersi d’accordo su cosa vuol dire avere coraggio per il team ed impegnarsi a comportarsi di conseguenza.
Questo aiuta a capire che il comportamento del team, di fronte a certe situazioni, sarà uniforme e contribuisce ad aumentare la sicurezza psicologica.
Ovviamente il Team Manifesto è qualcosa che evolverà nel tempo, un ottimo strumento per accogliere un nuovo arrivato, per esempio.
Comprensione di Scrum
Comprendere perché Scrum è uno strumento adatto alla risoluzione di problemi complessi è assolutamente necessario.
Applicare Scrum secondo le regole permetterà di rivelare ciò che disfunziona in azienda (attivare gli anticorpi aziendali per riconoscerli) e che è necessario correggere, col tempo, per rimanere o diventare competitivi in un contesto di complessità.
Un’esempio di come ho aiutato un’azienda ad adottare Scrum si trova qui a destra (in inglese).
Come riconoscere la guarigione dalla reazione autoimmune
La guarigione prenderà tempo, a seconda della cultura aziendale. Aziende che esistono da decine d’anni, con strutture gerarchiche piramidali forti avranno più difficoltà ad evolvere. A volte evolvono fino ad un certo punto, per poi tornare improvvisamente ai vecchi metodi di lavoro. Altre volte evolvono solo in certi dipartimenti, non a livello globale.
I segnali che considero come positivi e che permettono di riconoscere un certo successo sono:
Meno burocrazia: si semplifica il lavoro, concentrandosi e mantenendo unicamente i processi utili alla creazione di valore
Personale più felice: meno assenze per malattia, ambiente più sereno e quindi più produttivo
Clienti più felici: i clienti acquistano fiducia, si sentono ascoltati e credono in noi per risolvere i loro problemi
Qualità del prodotto in crescita: meno interruzioni dalla produzione, quindi più focus per creare nuove cose
Rapidità nell’arrivare sul mercato: capacità del team a mettere in produzione più rapidamente e regolarmente
Capacità di reazione alle difficoltà: il team è capace di trovare soluzioni a qualsiasi cambiamento, da solo, dimostrando la capacità di adattamento richiesta in un contesto di complessità
Quali altri segnali positivi hai notato nella tua azienda? Condividili nei commenti!
Conclusioni
Il problema nelle aziende non è Scrum, o qualsiasi altro approccio di lavoro, il problema è la reazione aziendale alla novità. Perché rappresenta un pericolo, scatenando la reazione autoimmune.
Una malattia autoimmune si può curare, a volte ci si deve convivere, altre volte ci vogliono interventi chirurgici pesanti. Mi scuso se qualche lettore è passato attraverso queste prove difficili, è una metafora forse fuori luogo, ma che trovo talmente azzeccata in un contesto di adozione di Scrum in azienda.
Il problema in azienda è la mancanza di leadership, di visione. Le persone che sono semplici esecutori di “ordini”, la mancanza di fiducia (orizzontale e verticale), l’incapacità a dire di no, una strategia mirata solo alla creazione di fatturato o soddisfazione degli azionari.
Questi sono i problemi, non Scrum o qualsiasi altro approccio di lavoro.
La leadership mediocre, porta a risultati mediocri e a reazioni autoimmuni che alimentano la mediocrità.
In conclusione mi piace ricordare il perché si ha bisogno di Scrum. Il futuro (ormai il presente) è costituito da prodotti customizzabili, riutilizzabili, ecologici, utili, specifici.
L’utente è ormai il prodotto, bisogna capirlo per soddisfarlo, non creare qualcosa e poi pensare che una campagna marketing o un buon venditore riuscirà a venderlo.
Gli anticorpi aziendali fanno di tutto per continuare a creare prodotti che non hanno qualità, arrivano tardi sul mercato, non corrispondono a qualcosa che gli utenti desiderano, creano un sacco di spreco, di infelicità.
La nostra missione, da Collective Genius e Scrum.org, è quella di aiutarvi a far riconoscere Scrum come elemento “sano” del vostro sistema azienda e farvi diventare il leader di mercato del vostro mestiere!
Project Manager e Scrum Master sono due mestieri diversi. Se sei un project manager, senti parlare sempre di più di Scrum e vorresti capire cosa c’è di così diverso fra questi due ruoli? Perché dovresti scegliere fra l’uno o l’altro e non si può fare un pò dei due?
In questo articolo provo a condividere le risposte a queste domande, con i principi e le ragioni che differenziano Scrum Professionale dal Project Management.
L’obiettivo non è quello di convincere che Scrum è la soluzione miracolo a tutto, al contrario. La mia esperienza come project manager mi porta ad apprezzare tutto quello che ho imparato durante gli anni spesi a gestire progetti in modo tradizionale.
Aggiornamento del 6 luglio 2023 – aggiunta del video dell’evento in diretta relativo a questa tematica.
Premessa
Ho avuto tre esperienze principali di lavoro:
Sviluppatore software per sistemi industriali complessi (essenzialmente C, C++ e SQL) dal 2001 al 2006 (6 anni)
Team leader, project e program manager nel settore bancario, trasporto e logistica, finanza dal 2007 al 2014 (8 anni)
Scrum Master e Professional Scrum Trainer dal 2015 ad oggi (9 anni)
Conosco bene cosa pensa (e cosa vive) uno sviluppatore, un project manager o uno Scrum Master. In particolare, per averli vissuti personalmente, conosco le sfide che un project manager deve affrontare se vuole diventare un buon Scrum Master.
Esploriamole insieme!
Project Manager e Scrum Master
Sono due mestieri diversi. È importante capirlo, perché il focus e le responsabilità di questi due ruoli sono diametralmente opposti.
Il Project Management funziona bene in contesti complicati o semplici (clicca sull’immagine per accedere all’articolo del blog “Cynefin, Scrum e Agile”)
Project Manager: ha per missione di tenere sotto controllo costi, time e scope del progetto. Garantisce all’azienda che gli investimenti strategici sono correttamente gestiti. Spesso è un esperto tecnico o funzionale e dice ai colleghi cosa fare, assegna i task e controlla che siano eseguiti secondo i piani. Ne parlo in questo articolo.
Un project manager lavora per soddisfare il management interno, ovvero controllare che il lavoro sia eseguito secondo i piani.
Fabio Panzavolta
Scrum funziona bene in contesti complessi (clicca sull’immagine per accedere all’articolo del blog “Cynefin, Scrum e Agile”)
Scrum Master: ha per missione di assicurarsi che Scrum è correttamente capito ed utilizzato. Contrariamente al project manager, i risultati del team “non gli interessano”. Se i membri dello Scrum Team hanno capito cosa vuol dire creare prodotti complessi in modo empirico, i risultati arriveranno.
Lo Scrum Master è un servant leader, aiuta a rimuovere gli ostacoli che impediscono il raggiungimento degli obiettivi del team (ne parlo in questo articolo).
Uno Scrum Master (con tutto lo Scrum Team) lavora per soddisfare gli utilizzatori del prodotto il più rapidamente possibile.
Fabio Panzavolta
Project Manager e Scrum Master, focus interno o esterno all’azienda?
La ragione di esistere di un project manager è quella di limitare i rischi aziendali garantendo il controllo degli investimenti.
Questo funziona principalmente per progetti altamente prevedibili, per i quali non sono previsti cambiamenti sostanziali durante lo sviluppo.
Quando lavoravo come project manager i primi cambiamenti al piano del progetto arrivavano molto rapidamente. Questo portava inevitabilmente a ginnastiche improbabili per non stravolgere il piano.
Project Manager – Focus interno
Per un Project Manager il focus è interno all’azienda, si passa più tempo a negoziare un paio d’ore di lavoro a destra e sinistra con gli sviluppatori che a sviluppare effettivamente il prodotto.
Questo focus interno porta a perdere di vista il perché si fa un progetto concentrandosi principalmente su budget, time e scope.
Ho personalmente conosciuto sviluppatori software che lavoravano da due anni su un progetto e non avevano mai visto il prodotto finito… immaginate la motivazione e l’impegno che potevano mettere al lavoro.
Scrum Master – Focus esterno
Uno Scrum Master, aiuta lo Scrum Team e gli stakeholders a fare un focus sui problemi da risolvere agli utilizzatori, ad ottimizzare il lavoro non fatto per concentrarsi solo su ciò che è veramente importante: il valore creato per gli utilizzatori del prodotto.
Questo non vuol dire che i limiti aziendali sono ignorati, perché il Product Owner fa attenzione a massimizzare il valore del prodotto. Quindi, per esempio, il budget a disposizione è speso in maniera opportunistica e non pianificata su un anno o due, ma con cicli di un mese al massimo.
Massimizzare il valore del prodotto vuol dire, fra l’altro, che la strategia del Product Owner implica la creazione di un prodotto che si auto-finanzierà il prima possibile.
Project Manager e Scrum Master, Scope fisso o variabile!
Altro cambiamento fondamentale, uno Scrum Master aiuta ad acquisire un modo di lavorare orientato sugli obiettivi, i requirements ci interessano, ma fino ad un certo punto.
Il project manager raccoglie tutti i requisiti, che molto spesso fanno parte del contratto. Per ottimizzare (sigh, sob 😊) si cerca di elencare tutte le funzionalità, con il cliente, nelle prime fasi del progetto. In modo tale da non doversi più vedere per un annetto o due (ri-sigh, ri-sob).
Ovviamente questo modo di lavorare funziona, come dicevo prima, se ciò che state facendo non ha incertezze sostanziali.
Purtroppo (in particolare per l’informatica), molto spesso il cliente non sa nemmeno cosa vuole. Oppure (che è anche peggio) è assolutamente convinto di sapere cosa vorrebbe avere (poi si scopre che gli utenti e i loro problemi quotidiani non li conosce veramente).
Quindi il povero project manager (esperienza vissuta) fa dei piani nel momento in cui il team, il cliente e lui stesso hanno meno esperienza e meno informazione possibile… conoscete i risultati… altrimenti non sareste arrivati fino qui a leggere 😊.
Questo problema è risolto in Scrum, perché invece di lavorare a scope fisso, si lavora con obiettivi fissi, concedendo una certa “liquidità” nelle funzionalità da implementare grazie all’ordinamento del Product Backlog.
Lo Scrum Master insegnerà a tutti (anche al cliente) come fondare il lavoro su obiettivi, generare risultati concreti per gli utilizzatori e farà in modo che le esigenze emergano con l’esperienza, grazie al feedback degli utilizzatori ed alla collaborazione regolare con il cliente.
In un mondo complesso ed incerto, quando non si sa veramente cosa si vuole, un prodotto non si pianifica, emerge dall’esperienza.
Fabio Panzavolta
Scegliere di fissare un obiettivo ed avere funzionalità variabili avrà come conseguenza una migliore qualità, più implicazione da parte di tutti, più innovazione nella ricerca di soluzioni e più rilasci in produzione.
Project Manager e Scrum Master, dalle esigenze agli obiettivi
Parlavo di contratto prima… quante volte, da project manager, mi sono trovato a dover discutere con il cliente per giorni, settimane per cambiare una virgola in una particolare esigenza… con il risultato che dopo la discussione ci volevano altre settimane per avere il GO per implementare il cambiamento (che nel frattempo, a volte, era già stato fatto).
Purtroppo, in certi casi, ci siamo anche trovati ad implementare delle cose che sapevamo sbagliate, o incoerenti, per non dover subire il processo descritto sopra.
Il focus sulle esigenze è un focus malato in un contesto complesso e mutevole.
Fabio Panzavolta
Il giusto focus è negli obiettivi… in Scrum ce ne sono due:
Product Goal: definito dal Product Owner, è un obiettivo a medio termine, un passo in più verso la visione del prodotto
Sprint Goal: definito dallo Scrum Team, è un obiettivo a corto termine (un mese massimo), un passo in più verso il Product Goal
In un contratto si possono fissare i Product Goal, facendo attenzione a non renderli troppo stringenti, bensì sufficientemente vaghi per dare una direzione e lasciare libertà nel decidere cosa e come sperimentare nuove soluzioni.
Segui questo link se vuoi saperne di più sui contratti agili.
Riuscire a fare un focus sul goal (Scrum Professionale) e non sui requirements (Project Management), vuol dire concentrarsi sul perché si vuole fare qualcosa, non sul come. Le discussioni sul cosa e come raggiungere l’obiettivo saranno legate al perché si vogliono fare, con un focus maggiore, più o meno funzionalità a seconda del contesto e degli esperimenti che si faranno collaborando.
Conclusioni
Project Manager e Scrum Master sono due mestieri diversi, con focus diverso. Non si può pensare di accettare un ruolo di Scrum Master senza aver capito Scrum Professionale o le responsabilità di uno Scrum Master (ne parlo in un episodio del podcast Scrum 🇮🇹).
La difficoltà non è Scrum, bensì il cambiamento nel modo di pensare, agire e prendere decisioni.
Uno Scrum Master si accontenta di rivelare ciò che non funziona secondo Scrum, non dà soluzioni o dice agli altri cosa fare. Piuttosto, aiuta le persone a trovare e sperimentare le soluzioni grazie alle idee che emergono discutendo.
Se sei un Project Manager e desideri cominciare o continuare il tuo percorso di professionalizzazione, puoi cominciare da autodidatta.
Personalmente ho letto tanto, questi sono i libri, ho praticato in condizioni differenti (prima in contesti al di fuori del lavoro, poi al lavoro) e non smetto mai di pensare che sto ancora imparando.
Un’altra fonte inesauribile di conoscenza è ovviamente il sito scrum.org, ma anche i blog di Ken Schwaber e Gunther Verheyen, i miei due punti di riferimento.
Se vuoi imparare o migliorare la tua conoscenza di Scrum Professionale, facendoti accompagnare, puoi anche scegliere di partecipare ad una delle nostre formazioni.
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.
