Il servant manager è una delle chiavi per stimolare l’innovazione in azienda. In questo articolo concentro le risorse che ti permetteranno di esplorare questo argomento.
Discutendo con dirigenti di società di qualsiasi dimensione, i problemi ricorrenti che espongono sono: qualità scarsa dei nostri prodotti, lentezza nel mettere in produzione nuovi prodotti, difficoltà a trattenere o attirare talenti, clienti insoddisfatti. Questi sono i sintomi di un’azienda che adotta una leadership che funzionava mezzo secolo fa. Quando si parla di innovazione spesso il focus è fatto su nuove tecnologie, ma la vera prima innovazione consiste ad adottare una leadership che sia adatta all’epoca in cui viviamo, costituita da incertezze e cambiamenti rapidi.
Un vero problema quando si devono risolvere problemi complessi.
2 – Le conseguenze
Osservabili facilmente in qualsiasi azienda, in maniera più o meno evidente:
Personale infelice
Competitività aziendale in diminuzione
Burn-out
Turnover
ecc.
Il controllo eccessivo delle persone, la burocrazia ed i processi che si usano per limitare i rischi, scatenano i sintomi osservati sopra. Purtroppo la soluzione usata in molte aziende, quando le cose vanno male, consiste nell’incrementare burocrazia e processi. Questo nel tentativo di correggere la situazione.
Purtroppo si ottiene l’effetto contrario.
3 – Capire il contesto
Questa mancanza di impegno al lavoro può essere spiegata dal fatto che il management non si è ancora perfettamente adattato alla gestione di problemi complessi.
Per prima cosa, quindi, è necessario farsi le domande giuste, cioè capire se il contesto nel quale operiamo è ancora del tipo “industriale”, con processi di sviluppo lineari e predittivi. In questo caso procedure e processi per controllare il risultato del lavoro sono la buona soluzione.
Ma se il contesto è di tipo complesso, allora il management come l’abbiamo imparato all’università (ed il modo di pensare) non sono più adatti in quanto in questo tipo di situazioni il pensiero e la risoluzione dei problemi non sono più lineari e prevedibili. In questo caso, è necessario ridurre (eliminare il più possibile) burocrazia e procedure, liberare le persone e concentrarsi su obiettivi chiari e misurabili. Questa è la logica post-industriale, dove l’obiettivo è creare valore in modo creativo e innovante.
Nel video qui sotto sviluppo questo concetto.
4 – Adattare il proprio stile di management
Se si vuole più impegno al lavoro, da parte di tutti, allora è necessario capire cosa vuol dire mettersi al servizio degli altri, ovvero come diventare un buon servant leader.
In un contesto di complessità il management è sostituito dalla leadership.
Management tradizionale
Servant Manager
Focus sulle persone
Focus sul sistema (vincoli, regole semplici non imposte)
Impone soluzioni
Fa domande, le risposte e le soluzioni arrivano dalle persone che fanno il lavoro
Orientato ai task (cosa e come fare)
Orientato obiettivi (perché fare)
Focalizzato sulle performance della persona
Focalizzato sul risultato del team (utilizzatori contenti?)
Confronto fra management tradizionale e servant manager
Tanti altri esempi sono possibili, questi sono i primi che mi sono venuti in mente. L’importante è capire che le caratteristiche di un servant manager sono quelle di venire in supporto alle persone che fanno il lavoro per assecondarle e supportarle nelle loro decisioni.
Per sapere se le decisioni sono giuste o sbagliate, bisognerà concentrarsi sugli utenti del prodotto, andare in produzione il più spesso possibile per ottenere feedback e migliorarsi continuamente.
Per saperne di più, esplora il contenuto qui sotto per saperne di più sul Servant Manager! Esplora come, facendo evolvere il nostro modo di essere, stimoliamo l’innovazione, rendiamo i nostri prodotti migliori e i clienti più contenti.
In questo articolo, Cynefin, Scrum e Agile, condivido parte della trascrizione di una conferenza di Dave Snowden del 2017. Mi ha permesso di capire che cos’è un sistema complesso e perché Scrum e Agile sono, al momento, gli approcci più efficaci per risolvere problemi complessi.
Per capire, trascrivere prima in inglese e poi tradurre in italiano questo video ho impiegato circa 12 ore. Spero che apprezzerai lo sforzo. L’articolo ti è stato utile e vuoi ricompensarmi? Allora condividi l’articolo o parlane con i colleghi, grazie!
Importante: l’articolo è la traduzione in italiano, pura e semplice, di parti del video qui sopra. Non ho nessun merito se non quello di aver tradotto le parole di Dave Snowden, che vi invito a seguire.
[ndr. I miei commenti, osservazioni, aggiunte alle parole di Dave sono fra parentesi quadre, precedute dalla menzione ndr. e in italico]. Buona lettura!
In natura esistono tre tipi di sistemi: ordinati, complessi e caotici.
Sistema ordinato
Un sistema ordinato è un sistema altamente vincolato, rigido. Si conoscono tutti gli elementi che lo compongono.
I collegamenti e le interazioni all’interno del sistema sono rigidi e definiti. In un sistema ordinato tutto è prevedibile, c’è una relazione lineare tra causa ed effetto.
Una sala operatoria è un esempio di sistema ordinato, posso sempre dire: “se faccio questa azione, ho sempre questo risultato”.
Nelle sale operatorie, si contano quanti strumenti chirurgici ci sono prima dell’operazione e quanti ce ne sono alla fine. Questo per evitare di dimenticarne all’interno del corpo del paziente e doverlo “riaprire” per fare pulizia.
Per arrivare a questo risultato, le persone hanno fra i 10 e 15 anni di formazione. Quando il chirurgo mette le mani in aria, l’infermiere sa quale strumento deve dargli.
Un sistema prevedibile richiede un investimento importante.
Non è possibile replicare questo tipo di interazioni senza formazioni intense e questo è l’errore che le persone fanno [ndr. che spesso si commette in azienda]. Si vede qualcosa che funziona bene in un contesto e lo si vuole riprodurre velocemente.
[ndr. Solo che non funziona, proprio perché] c’è un alto costo per ottenere ordine e un’enorme ricompensa quando si è capaci di raggiungerlo.
Purtroppo questo ordine può essere portato all’eccesso, con relative conseguenze negative.
[ndr. Le aziende che definiscono processi rigidi per lo sviluppo dei loro prodotti sono ottimi esempi. Ho lavorato in aziende dove i progetti seguivano fasi ben specifiche. Sequenziali. Analisi dei requisiti, concezione, sviluppo, ecc.
Era vietato cominciare la fase successiva se quella precedente non era terminata. Per terminarla dovevamo avere l’autorizzazione di un comitato appositamente creato per autorizzare la fine di una fase e l’inizio della successiva.
Visto che questi tipi di comitati si riunivano in modo non regolare, era pratica comune cominciare in anticipo la fase successiva ben prima della validazione. A volte si facevano addirittura le cose in parallelo (di nascosto) perché non aveva senso aspettare.
In altre parole, avevamo trovato un rimedio al sistema iper-vincolante.]
Se si vincola eccessivamente un sistema che non può essere naturalmente vincolato le persone troveranno delle alternative[ndr. più o meno “legali”].
[ndr. La conseguenza è una perdita importante di energia: la burocrazia ne è un esempio.] Fornisce un’apparenza di ordine, che in realtà richiede un enorme quantità di persone di buona volontà per far funzionare il sistema, nonostante tutto.
Vincolare eccessivamente un sistema può essere pericoloso. Un sistema ordinato ha valore in circostanze molto particolari.
Sistema caotico
Un sistema caotico non ha vincoli. Il sistema è casuale (random). Se un sistema diventa caotico accidentalmente (sistema eccessivamente vincolato, nessuno rispetta più le regole, contornare le regole è diventato normale), allora il sistema si disfa catastroficamente, diventando caotico. È un disastro.
D’altro canto, se si entra deliberatamente in un sistema caotico, allora si apre la strada all’innovazione o la capacità delle persone a interpretare in tempo reale determinate situazioni (la saggezza delle folle).
Quindi il caos è molto utile, se si capisce quando può essere utilizzato e quando deve essere evitato.
La completa casualità, se si raggiunge, ha vantaggi ma deve essere vincolata.
Sistemi complessi adattativi
In un sistema complesso adattativo ci sono talmente tanti impatti esterni che i pattern ripetitivi non esistono o, se esistono, è per puro caso ed in rare eccezioni.
[ndr. Ora introduciamo] il concetto di “coerenza retrospettiva”: [ndr. un fenomeno che ci porta a] vedere solo le cose che sembrano ripetersi.
Può essere pericoloso analizzare le cose in questo senso. [ndr. In un sistema complesso] ci sono talmente tanti fattori che interagiscono fra di loro continuamente che non c’è nessun modo di introdurre una relazione classica di causa ed effetto. Ed il modo in cui ciò è espresso normalmente, in un sistema complesso adattativo, non è causale bensì disposizionale.
Praticamente, si può affermare che il sistema è disposto ad evolvere in un certo modo ed è poco probabile che evolverà in un’altra direzione. Ma non si possono mai avere affermazioni accurate [ndr. e certe].
Ed è per questa ragione che in un contesto complesso si può modellizzazione il presente e vedere cosa si può fare nel presente per cambiare le cose. Non si definisce uno stato futuro.
Questa è una differenza fondamentale e profonda fra “complexity thinking” e “system thinking”.
Nel “system thinking” si fa il modello di uno stato futuro, la cultura aziendale, si definiscono gli obiettivi business e si comunica dove si vuole essere in futuro.
Nel modo di pensare complesso ci si concentra nel mappare il presente, si identifica cosa si può cambiare e, mentre si cambia, si controlla velocemente il cambiamento per rinforzare ciò che funziona bene e abbandonare il resto.
Tipo di sistema e stile di management
Il principio di base è comprendere in quale sistema ci si trova per gestirlo in modo appropriato.
Negli ultimi decenni, è stata praticata la politica dell’approccio standardizzato. Esiste questo metodo, è universale.
La realtà è che questo tipo di soluzioni sono applicabili solo in contesti ben particolari.[ndr. Si capisce meglio perché, in certe aziende, si cambia regolarmente metodo di lavoro. Il precedente non ha dato i risultati sperati. Allora applichiamo un nuovo approccio, ha un sacco di aspetti positivi, avrà sicuramente successo… e si riparte nelle stesse dinamiche. I dipendenti diventano allergici a qualsiasi tipo di nuovo metodo di lavoro e questo è una catastrofe per le persone e per l’azienda.
Se si capisce che si è in un sistema complesso, allora si deve accettare che i metodi o approcci universali non esistono.]
L’esempio della festa di compleanno per bambini di 9 anni.
Immagina di dover organizzare una festa per dei bambini di 9 anni. Immagina come potresti fare.
Per prima cosa bisogna decidere che tipo di sistema è. Caotico? Ordinato? Complesso?
Se è caotico vuol dire che i bambini sono liberi di fare tutto ciò che vogliono, in modo completamente casuale. Probabilmente la tua casa sarà distrutta alla fine della festa, ma è qualcosa che ci si aspettava fin dall’inizio, quando si è scelto il sistema caotico.
Quindi probabilmente trattare la festa di compleanno come un sistema caotico non è una buona idea.
Proviamo con un approccio ordinato allora…
Si definiscono gli obiettivi di apprendimento per la festa, prima che la festa cominci.
Gli obiettivi di apprendimento sono allineati con la mission statement per l’educazione dei bambini del tuo quartiere. Sono chiaramente espressi e visibili in poster motivazionali con belle immagini ispiranti.
Incolli questi poster un pò ovunque in casa e particolarmente nel luogo dove si terrà la festa.
Non chiedi ai bambini di giocare, invece distribuisci delle carte da gioco che spiegano come ogni bambino deve comportarsi.
Ovviamente hai anche preparato un project plan. Il project plan ha delle milestones chiare per tutta la festa, utilizzabili per valutare l’avanzamento della festa secondo gli obiettivi ideali prefissati.
Un adulto senior dà inizio alla festa con un video motivazionale.
Non vuoi che i bambini perdano tempo a giocare, perché non è previsto dagli obiettivi di apprendimento. Invece di giocare usano Power Point per dimostrare il loro commitment personale agli obiettivi della festa.
Dimostri come la loro ricompensa è direttamente legata al raggiungimento dei risultati attesi.
In seguito al grande successo del completamento della festa, proponi una post mortem review e promuovi nuove best practices per tutto il tuo quartiere.
Se, a questo punto, per una qualsiasi ragione improbabile, i bambini non sono felici, allora avrai bisogno di un professionista che racconterà storie divertenti per avere modelli mentali più felici e bambini meglio indottrinati a cui piacerà qualsiasi cosa gli presenterai la prossima volta. Oppure chiami un happiness consultant, o una variante delle due.
Forse anche il sistema ordinato non funziona poi così bene…
L’approccio complesso, in un certo modo, è molto più semplice.
Si comincia con il tracciare una riga per terra. Questo è un limite (constraint) o vincolo in termini di complessità.
Guardi i bambini dritto negli occhi e dici: “se qualcuno osa superare quella riga torna a casa immediatamente, festa finita”. [ndr. in realtà nel video l’espressione è più divertente e colorita]
In seguito si introducono delle sonde caotiche catalitiche: calcio, barbecue, videogame. Con la speranza che si formerà una dinamica di gioco interessante per i bambini.
Questi sono anche chiamati “attractor”, se risultano benefici, si danno più risorse.
Quello che si cerca di fare è di favorire l’emergere di una coerenza benefica nei limiti dei vincoli imposti.
Creazione di prodotti complessi
Se si pensa alla creazione di prodotti complessi, probabilmente ora comincerai a pensare ad approcciarlo in modo diverso.
Non ci penseresti neppure un secondo di gestire una festa in modo ordinato o caotico. Perché allora lo facciamo al lavoro?
La realtà è che si userà molto meno energia per gestire vincoli, sonde catalitiche (barbecue, videogiochi) e strategie di amplificazione piuttosto che decidere in anticipo esattamente come le cose dovrebbero essere. Questo potrebbe dare un sentimento di controllo, ma non un obiettivo.
Cynefin
Cynefin è una parola irlandese, non traducibile in inglese [ndr. e nemmeno in italiano, clicca qui per la pronuncia corretta]. Significa il luogo di molteplici appartenenze. È la sensazione di essere in un continuo flusso di significato nel tempo, non è mai statico.
C’è una sensazione di flusso, di continuità. È un nome perfetto per un modello di complessità, perché nella complessità puoi sapere dove sei e da dove vieni, ma non capisci esattamente la causa e l’effetto.
In pratica è intrinsecamente comprensibile, ma bisogna gestire il flusso. È un pò come andare in canoa in una rapida, piuttosto che seguire una strada precisa e decisa in anticipo, devi costantemente prendere decisioni rapide perché nulla rimane sempre uguale.
Questo è il disegno di Cynefin.
Cynefin – Dave Snowden
Cynefin – Il disordine
La zona centrale è quella del disordine, lo stato di non sapere in quale degli altri sottosistemi ci si trova. Un posto infelice dove trovarsi, perché non si sa se il sistema è ordinato, complesso o caotico, quindi si tenta di fare ciò che è più facile.
Cynefin divide l’ordine in due. Lo divide in uno spazio dove la causa in una relazione è ovvia ed un’altro dove la causa in una relazione è complicata. Questa differenza è ovvia, perché se la relazione fra causa ed effetto è evidente, non bisogna preoccuparsi di spiegare le cose. Le persone faranno ciò che devono fare [ndr. Se piove apro l’ombrello].
Cynefin – Chiaro
In Inghilterra si guida a sinistra, se vai in Inghilterra e guidi a destra devi aspettarti conseguenze negative.
Il modello decisionale è molto semplice: percepire, categorizzare, rispondere e applichiamo le best practices. Abbiamo vincoli rigidi o fissi.
È una buona zona in cui stare, è bella e prevedibile, tutto è meraviglioso, ha un costo energetico molto basso, ma è una base molto pericolosa perché, se la si limita troppo, si ha un collasso nel caos.
Cynefin – Caos
Quindi, la parte inferiore di Cynefin è in realtà disegnata così, perché rappresenta un precipizio che porta nel caos. Se cado in quest’area, qui c’è una zona di compiacimento, penso che tutto funzioni.
Se hai guidato la macchina a Sorrento, e credi che il traffico segua la legge normale, allora aspettati un disastro. La prima volta che ho guidato a Napoli ho causato un tamponamento di massa perché il semaforo iniziava a diventare rosso, quindi ho rallentato. L’auto dietro di me ha reagito in tempo, ma dietro c’è stata un’ammucchiata perché a Napoli si va più veloci e ci sono due minuti di tempo per passare con il rosso prima che arrivi il traffico dall’altra parte. Quindi, si può sbagliare.
Nella pratica, non voglio che si verifichi un guasto catastrofico di questo tipo. Se succede, devo uscirne in fretta. Quello che faccio qui [ndr. nel caos] è agire, percepire, rispondere. La buona notizia è che non ci sono vincoli e la pratica è sempre nuova [ndr. novel practice]. È completamente diverso.
Non abbiamo un’occasione migliore per fare qualcosa di diverso di quando c’è una grave crisi [ndr. pensa al COVID]. Anzi, la crisi è la migliore opportunità che abbiamo per innovare. Perché in quel momento le persone sono aperte alle novità. Non si può innovare durante i periodi di stabilità, si può innovare solo durante i periodi di crisi [ndr. pensa allo smart working prima e dopo il COVID!].
Cynefin – Complicato
Nel sistema complicato le relazioni tra causa ed effetto non sono evidenti, ma possono essere scoperte attraverso l’analisi o l’applicazione di competenze.
Il modello qui è percepire, analizzare, rispondere. La pratica, naturalmente, è buona non migliore, [ndr. good practice al posto della best practice che troviamo nel dominio del semplice] e i vincoli sono chiamati vincoli di governo. In sostanza, all’interno di un limite posso variare ciò che faccio.
Un grande errore nella consulenza di queste iniziative è quello di costringere le persone a un unico approccio.
Le persone che hanno un’esperienza approfondita, dovrebbero avere la possibilità di variare il loro approccio. Agile tende a favorire un unico approccio [ndr. Complesso o complicato]. Tende a metodi che sono stati progettati per essere insegnati, piuttosto che per essere praticati, e naturalmente se si ha bisogno di insegnare si ha bisogno di processi rigidi, perché è più facile insegnare.
Quindi, come si capisce, è un problema generale dei metodi in tutto il mondo.
[ndr. Non sono d’accordo con i due paragrafi precedenti… Scrum Professionale e, più generalmente le formazioni di Scrum.org, insegnano a ragionare in modo adatto al contesto complesso. Ovviamente si passa un pò di tempo a spiegare le 11 (!!) regole di Scrum, che sono i famosi vincoli di cui Dave parla nell’ambito di un sistema complesso.]
Naturalmente, da questo si passa al dominio complesso.
Cynefin – Complesso
Il dominio complesso si gestisce con esperimenti paralleli, che possono fallire. Si sonda, percepisce e si risponde, ma in parallelo, non in sequenza.
Quindi, se ho quindici o sedici idee coerenti su quale sia la cosa giusta da fare, non cerco di risolverle. Ciascuna di queste idee riceve una piccola quantità di risorse per condurre un esperimento di durata limitata in parallelo con le altre idee. Perché l’unico modo per capire cosa è possibile fare è agire all’interno del sistema.
È qui che l’agilità fallisce, ci torniamo fra poco.
La pratica qui è emergente [ndr. emergent practice], con vincoli abilitanti, non vincoli governativi. È una distinzione molto importante. È una differenza tra regole ed euristiche.
Prendiamo alcuni esempi militari, come la famosa innovazione di Napoleone nella guerra. I generali marciavano al suono del cannone. È stata una rivoluzione perché, prima di allora, tutti seguivano gli ordini o agivano in modo autonomo. Ora esiste un principio di governo, il che significa che sanno più o meno cosa fare e sanno cosa faranno gli altri generali intorno a loro. Quindi, c’è un grado di cognizione distribuita o di intelligenza distribuita nel sistema.
I Marines degli Stati Uniti hanno tre regole: conquistare il punto più alto, rimanere in contatto, continuare a muoversi. Si noti che queste regole sono empiricamente misurabili. Non sono principi astratti, come mettere i clienti al primo posto, che possono essere reinterpretati. Sono concreti e tangibili.
Se si guarda in termini militari, sono un modo migliore di esprimere le intenzioni del comandante rispetto a piani precisi. Quindi, la complessità consiste nel gestire l’ambiguità necessaria.
Cynefin, Scrum e Agile
Applichiamo Cynefin ad Agile. Si possono usare gli stessi concetti, nella stessa immagine, aggiungendo un’altro vincolo al sistema. Si tratta della cosiddetta versione liminale[ndr liminal version] di Cynefin, che si presenta più o meno come nell’immagine qui sotto. Anche in questo caso, si tratta di una singola linea che crea di fatto due aree liminari.
Cynefin Liminare – Dave Snowden
La liminalità è un concetto chiave in antropologia. Nelle comunità indigene, quando qualcuno indossa una maschera, diventa uno stregone. C’è uno stato di transizione tra l’essere chi è e il ruolo assunto dalla maschera. E questo si chiama liminalità. Quindi, una condizione liminare è uno stato di transizione che lascia aperte le possibilità di tornare indietro o di andare avanti. La liminalità qui è fondamentale.
Facciamo delle categorie, per ogni sistema. Waterfall corrisponde al dominio del semplice. Non c’è niente di male nel Waterfall se si sa esattamente cosa si deve ottenere; si sa quali risorse, cosa si vuole fare: creare un progetto tradizionale. Tecniche come Prince2 funzionano bene. Non ci sono problemi. Cercare di rendere tutto agile è un errore.
Nel dominio del complicato si osservano tecniche come il timebox, che tendiamo a dimenticare. Solo perché uno Sprint è di due settimane non significa che il timebox non possa essere di tre mesi. [ndr. Qui non ho capito bene il concetto… in effetti uno Sprint può avere un timebox di 2 settimane, ma nulla vieta di avere un Product Goal di più Sprint, quindi con un timebox composto dalla somma dei timebox dei diversi Sprint… forse qui c’è un’incomprensione dei principi di Scrum]
Negli anni ’80 e ’90 si usavano molto queste tecniche. Garantiamo una data di consegna, ma variamo le risorse o la consegna per raggiungerla. E ci sono altre tecniche in questo campo.
Un framework dovrebbe aprire delle possibilità piuttosto che costringere a un solo modo di lavorare. Non c’è niente di sbagliato nell’usare il timebox. [ndr. Che è proprio il principio di Scrum, un framework descrittivo e non prescrittivo]
La forza dell’uso di Scrum, e Scrum è stato assolutamente vitale per tutto questo, è che Scrum sta nella parte blu dell’immagine.
La grande forza di Scrum è quella di mantenere le cose in uno stato liminale di trasmissione, in modo che non escano troppo velocemente dal dominio della complessità.
Questo si chiama convergenza prematura, si trova in quel dominio liminale, perché è un esperimento lineare basato su un requisito parzialmente noto.
Ecco tre esempi di tecniche che stiamo sperimentando [ndr. Riprese da Extreme Programming]:
Pair Programming, con l’aggiunta di un utilizzatore, formato a comunicare efficacemente con gli sviluppatori
Metodo Triple-Eight, si uniscono persone competenti nella concezione di prototipi con persone capace di svilupparli. Lavorano insieme agli utilizzatori per 8 ore e passano il prototipo ad un altro team che lavora sul prototipo per altre 8 ore (senza conoscere i requisiti utilizzatore e senza sapere perché il prototipo è stato creato, devono solo migliorarlo). Poi lo passano ad un terzo team, che esegue lo stesso lavoro per 8 ore. Alla fine il prototipo torna al punto di partenza. In questo modo si rinforza attivamente la mutazione per gestire l’incertezza. Ogni volta che abbiamo provato questo metodo gli utilizzatori erano molto soddisfatti. Si gestisce l’incertezza con metodi che costruiscono a loro volta incertezza.
Esigenze impreviste, richiediamo agli utilizzatori di catturare di continuo le loro frustrazioni quotidiane con l’IT. Si ottengono dati statistici su quali sono i problemi o le esigenze più pressanti e si lavora per risolverle
Se vogliamo che Agile sopravviva, dobbiamo renderlo un quadro flessibile e fluido di strumenti multipli provenienti da contesti diversi. Kanban funziona molto bene nel dominio complicato, ma non molto utile per quello complesso.
Anche l’idea del work-in-progress è buona, ma il modo in cui si rappresenta il work-in-progress nel dominio del complesso non è una serie di carte in colonne, ma una mappa paesaggistica delle potenzialità [ndr. Come le mappe del metro].
Quindi, dobbiamo iniziare a riconoscere la necessità di una diversità essenziale per variare e mescolare efficacemente i vari metodi e dobbiamo spostare l’attenzione di Agile dall’accreditamento [ndr. certificazioni] alla consegna.
L’esperienza conta più dei certificati e dobbiamo riconoscerlo.
Conclusioni
[ndr. Sembra chiaro che il mondo in cui viviamo richiede un modo di affrontare i problemi e le situazioni in modo molto diverso da quello che abbiamo imparato a scuola e negli anni di lavoro. Il determinismo non possibile in un mondo in costante movimento, il futuro non si può prevedere. Ciò che mi è piaciuto in questo video, nel discorso di Dave Snowden, è la coerenza dei propositi, il punto di vista spiegato in modo assolutamente brillante. Quando ho cominciato a praticare Scrum, venivo da anni di Project Management nel dominio dell’informatica. Ero solito scherzare, quando i capi mi chiedevano se il project plan era pronto. Rispondevo certo è pronto, sbrigatevi a leggerlo perché domani sarà già da aggiornare! Ma non capivo perché… ora capisco. E sono felice, perché sono intimamente convinto che grazie alle formazioni, workshop e coaching Scrum che offro sto un pochino cambiando il mondo in meglio!]
Creare prodotti complessi impone una strategia di sviluppo centrata sull’esplorazione di soluzioni incrementali. SpaceX è un’ottimo esempio di come un prodotto evolve nel tempo, facendo tesoro dell’esperienza.
Spesso, in formazione o in clientela, mi sento dire che è impossibile sviluppare prodotti fisici in modo iterativo e incrementale. “Sai Fabio, questo non è software, noi facciamo prodotti fisici complessi”. Ok ok, capisco 😊.
Purtroppo queste affermazioni, ancora più spesso, sono fatte senza che si sia mai provato nulla di diverso. Strategie marketing e di vendita basate su processi predefiniti e rigidi non permettono di innovare. In questi contesti innovare significa far evolvere anche le funzioni a supporto del prodotto. Vediamo come, grazie all’esempio di SpaceX che, penso siamo d’accordo, crea prodotti piuttosto complessi 😊.
Nel seguito dell’articolo trovate le mie interpretazioni e supposizioni, frutto dell’osservazione dei video e altre informazioni trovate su internet. Non ho nessun tipo di contatto diretto con SpaceX. Se tu che leggi e conosci meglio SpaceX, sarò felicissimo di correggere gli eventuali errori di interpretazione!
Creare prodotti complessi: la storia dei vettori riutilizzabili
Quando SpaceX ha cominciato a sviluppare i vettori orbitali, ha dovuto far fronte ad un sacco di problemi. Alcuni di questi piuttosto visibili e spettacolari 💥.
I primi vettori erano di piccole dimensioni, studiati per inviare nell’atmosfera terrestre dei carichi di una certa massa, come piccoli satelliti.
Creare prodotti complessi – Le esplosioni che hanno insegnato tanto al team SpaceX
La domanda da farsi è: “come possiamo risolvere il problema che stiamo affrontando con il prodotto più piccolo ma utile possibile?“. Utile per noi in azienda per imparare e per i nostri clienti per poter fare cose che prima non potevano realizzare.
La serie di problemi ed esplosioni durante la fase di sviluppo ha dato l’idea al team SpaceX dei vettori riutilizzabili, quindi della “funzionalità” di rientro e atterraggio automatica.
Questo era qualcosa che non si era immaginato prima, che è emersa grazie ai diversi esperimenti fatti nello sviluppo. Si capisce quindi che l’innovazione non si pianifica, ma emerge durante lo sviluppo del prodotto.
Falcon 9 – il primo razzo di classe orbitale riutilizzabile (fonte sito SpaceX) è il risultato di tutte queste esplosioni (controllate o meno), e tante altre cose meno visibili ovviamente.
Al momento in cui scrivo questo articolo, il Falcon 9 ha fatto 195 lanci, 153 atterraggi, 132 voli di ritorno (fonte sito SpaceX) e ne fanno uno dei vettori meno cari del mercato per inviare satelliti in orbita.
Creare prodotti complessi – IL Falcon Heavy
Il Falcon Heavy è stato creato mettendo insieme 3 Falcon 9, anche qui si capisce quanto si pensi a riutilizzare ed integrare quello che già si sa.
Creare prodotti complessi – Falcon Heavy et Starman
Con il Falcon Heavy si ottiene una spinta al decollo equivalente a 18 aerei 747 (secondo il sito SpaceX) permettendo l’invio in orbita di masse più importanti e riducendo i costi di trasporto.
Ovviamente, grazie all’esperienza fatta con Falcon 9, questo modello ha subito molto meno esplosioni.
Secondo il sito SpaceX, al momento della scrittura di questo articolo, il Falcon Heavy ha fatto 5 lanci, 11 atterraggi, 6 voli di ritorno.
Andiamo avanti? 😊
Creare prodotti complessi – Starship
Questa è una navetta per trasporto merci e persone. Con questo mezzo si vuole raggiungere Marte.
Starship è il veicolo di lancio più potente al mondo mai sviluppato, con la capacità di portare in orbita terrestre oltre 100 tonnellate metriche (fonte sito SpaceX).
In qualche modo Starship è qualcosa di nuovo, l’esperienza passata con i Falcon 9 e Heavy è sicuramente servita. Ma qui si doveva imparare a far scendere a terra un bestione enorme. Ovviamente c’è stato qualche “piccolo” problema. Anche in questo caso utile per imparare e fare esperienza.
Creare prodotti complessi – I “piccoli” problemi durante lo sviluppo di Starship
Ciò che più mi ha affascinato, seguendo lo sviluppo di questo prodotto, è stato il modo in cui lo sviluppo iterativo e incrementale è evidente.
Dopo i test statici dei motori, Startship è stato fatto decollare a 100m da terra, poi sempre più in alto ed ogni volta per imparare qualcosa di preciso.
Anche le esplosioni avvenivano, a volte, di proposito. Proprio per capire cosa sarebbe successo in certe situazioni.
Si capisce come questo approccio “empirico” aiuti ad imparare in fretta, accumulare dati e risolvere problemi in un contesto di innovazione.
Il video qui sotto ha ispirato l’articolo che sto scrivendo. Si tratta del lancio di Falcon Heavy del 15 gennaio 2023. Si vedono i due booster tornare a terra, senza problemi. Francamente mi ha impressionato.
Al della prodezza tecnica, si capisce bene la logica di sviluppo dei prodotti che contraddistingue SpaceX e gli permette di essere il leader del loro settore.
Altra cosa che mi ha impressionato, è il tweet qui sotto di Musk, che mostra come sia stato fatto un passettino in più verso il raggiungimento della sua visione: andare su Marte.
Questo è quello che ci si aspetta da un Product Owner. Avere una visione, saperla comunicare e avere una strategia per raggiungerla.
Creare prodotti complessi – E così è come atterreremo su Marte.
Qua c’è una logica impressionante, brillante. Almeno per me. Applicare la stessa logica allo sviluppo di Software o Hardware non è poi così impossibile, cosa ne pensate?
Conclusioni
Quali problemi osservo nelle aziende che ho frequentato, che impediscono lo sviluppo agile di un prodotto?
Non c’è una sola persona responsabile dello sviluppo di un prodotto
Questa persona, se esiste, non ha l’autorità per prendere decisioni, o scende a compromessi per far contenti un pò tutti
Questa persona, se esiste, non è capace di concentrarsi sul perché e sul cosa, ma spesso interferisce su come fare le cose
Silos. Sales, Marketing, IT: spesso hanno la loro visione delle cose, solo che non si parlano, non la condividono, oppure lo fanno, ma troppo in fretta o troppo poco spesso.
Sicurezza psicologica: la creazione di prodotti complessi richiede un ambiente di lavoro nel quale ci si senta al sicuro per poter sperimentare, sbagliare e quindi imparare. Purtroppo l’ambiente di lavoro classico richiede persone che dimostrino di essere infallibili, di avere la risposta giusta al primo colpo. Il risultato è il teatro dell’opera, dove si fa finta di sapere le cosa anche quando non si sanno.
Non è un mistero quindi che, per creare prodotti complessi, un approccio agile e quindi empirico è il migliore. Volete innovare, volete battere la concorrenza? Allora prendete il gusto alla sfida, osate qualche bella esplosione 😊.
Scrum prescrive eventi per creare regolarità e trasparenza e ridurre al minimo la necessità di altre riunioni. Gli eventi Scrum sono: Daily Scrum, Sprint Planning, Sprint Review, Sprint Retrospective e Sprint. Spesso gli eventi Scrum non vanno come previsto. Una buona e leggera facilitazione può aiutare i team Scrum a rimettersi in carreggiata.
Senza una buona facilitazione, gli eventi Scrum possono trasformarsi in riunioni inefficaci:
Lo scopo degli eventi può non essere raggiunto
Potrebbero esserci continue interruzioni mentre si parla, oppure persone che non osano esprimersi
Potremmo sentire sempre le stesse poche voci e perdere l’opinione degli altri
Gli eventi potrebbero protrarsi oltre i tempi previsti senza creare concretezza
Si possono perdere le opportunità di collaborare e di progredire verso i risultati desiderati
Questo elenco evidenzia lo scopo degli eventi Scrum, un’indicazione di dove il facilitatore dell’evento dovrebbe concentrarsi e alcuni esempi di tecniche di facilitazione che possono aiutare a guidare un team verso risultati di successo.
Daily Scrum
Scopo dell’evento: i Developers verificano i progressi verso lo Sprint Goal. L’output del Daily Scrum è un piano per la giornata lavorativa successiva.
Focus del facilitatore: creare un’atmosfera in cui il team si concentri sulla qualità, sull’impegno (Sprint Goal) e sulla risoluzione degli impedimenti. Evitare gli “status update”, perché corrispondono a informazione unidirezionale dal lavoratore al manager. Osservare e porre domande quando necessario. Assicurare che il team si concentri sullo Sprint Goal.
Video – Come facilitare il Daily Scrum
Come facilitare il Daily Scrum
Esistono molti modi per facilitare il Daily Scrum. In questa introduzione alla facilitazione di un Daily Scrum, imparerete tre tecniche diverse, con i vantaggi e le sfide di ciascuna. Il team può sperimentarle secondo le proprie necessità e scegliere il metodo che meglio lo aiuta a concentrarsi sui progressi verso lo Sprint Goal, producendo al contempo un piano attuabile per il giorno di lavoro successivo.
Esempi di tecniche di facilitazione:
Vuoi aumentare l’attenzione allo Sprint Goal durante il Daily Scrum?
Il team sta entrando troppo nei dettagli durante il Daily Scrum?
Provate a introdurre ELMO (Enough, L’êtes Move On). – I partecipanti dicono “Elmo” o tengono in mano un pupazzo di Elmo per incoraggiare il gruppo a sospendere la discussione in corso e passare all’argomento successivo.
Sprint Planning
Scopo dell’evento: inizia lo Sprint definendo il lavoro da svolgere per lo Sprint. L’output è uno Sprint Backlog (Sprint Goal + Product Backlog Item selezionati + Piano per realizzarli).
Focus del facilitatore: creare un ambiente collaborativo e trasparente con un obiettivo chiaro. Mantenere il team focalizzato sullo Sprint Goal.
Video – come facilitare lo Sprint Planning
Come facilitare lo Sprint Planning
In questo video di introduzione alla facilitazione dello Sprint Planning, imparerete come e quando utilizzare tecniche di facilitazione come il voto romano, la visualizzazione e le “powerful questions”, in modo che il team possa lasciare l’evento con uno Sprint Goal che persegua il Product Goal e un piano iniziale per lo Sprint.
Scopo dell’evento: ispezionare l’incremento, attraverso il feedback e l’adattamento del Product Backlog, se necessario.
Focus del facilitatore: creare un ambiente coinvolgente, energico e partecipativo. Incoraggiare l’ascolto piuttosto che la reazione. Empatizzare, ascoltare attivamente e costruire una sinergia tra il team Scrum, gli sponsor e gli stakeholder.
Video – come facilitare la Sprint Review
Come facilitare la Sprint Review
In questa introduzione alla facilitazione di una Sprint Review, imparerete una tecnica di facilitazione che può aiutarvi a trasformare la Sprint Review in una sessione più coinvolgente e collaborativa, in modo da poter raccogliere feedback preziosi dagli stakeholder per determinare i futuri adattamenti del vostro prodotto.
Esempi di tecniche di facilitazione:
Hai problemi a coinvolgere gli stakeholder e gli utenti durante la Sprint Review?
Incoraggiare le persone a interagire con il prodotto
Scopo dell’evento: lo Scrum Team esamina come è andato l’ultimo Sprint; individui, interazioni, processo, strumenti e definizione di Done. Output: lo Scrum Team si adatta identificando i cambiamenti più utili per migliorare la propria efficacia.
Focus del facilitatore: creare un’atmosfera sicura in cui tutti i membri del team si sentano aperti a partecipare. Ascoltare attivamente ciò che viene detto e ciò che non viene detto. Aprire la parola ai diversi punti di vista. Costruire il consenso e definire chiaramente i passi successivi.
Video – Come facilitare la SprintRetrospective
Come facilitare la Sprint Retrospective
In questo video Introduzione alla facilitazione della Sprint Retrospective, imparerete passo dopo passo come guidare il vostro team attraverso una Sprint Retrospective con tecniche quali la Prima Direttiva, il Gioco della perfezione, il Dot Voting e la Affinity Mapping, in modo che il vostro team possa lasciare l‘evento con idee su come migliorare.
Esempi di tecniche di facilitazione:
Vuoi creare un ambiente sicuro e mettere il team sulla stessa lunghezza d’onda?
Leadership – 5 cambiamenti fondamentali, analizza le origini dei problemi che bloccano l’innovazione impedendo a certe aziende di rimanere competitive.
Ho potuto osservare questi problemi nel corso degli ultimi 20 anni. In alcuni casi, ho contribuito a migliorare la situazione (qui un case study, in inglese, che potete scaricare).
Molto più spesso, purtroppo, ho assistito a battaglie politiche, di ego e desiderio di dominare che hanno ridotto le possibilità di migliorare la creazione di valore.
Perché cambiare?
Non perché lo dico io, può darsi che la mia esperienza non sia significativa.
L’impegno dei dipendenti al lavoro è globalmente sceso del 2%. È passato dal 22% nel 2019 al 20% nel 2020.
State of the Global Workplace – Rapporto 2021
Effetto COVID? Può darsi, vedremo l’anno prossimo se la tendenza si invertirà.
La cosa che più spaventa, è la cifra a livello europeo (ovest) 11%, con un aspetto positivo però… nel 2020 abbiamo guadagnato 1% di impegno al lavoro rispetto al 2019! L’Europa occidentale è fanalino di coda di tutte le regioni mondiali.
Ancora più terrificante sono le cifre italiane… se l’Europa dell’ovest è ultima al mondo in termini di impegno dei dipendenti, l’Italia è ultima in Europa occidentale.
Solo 5%, 18ema posizione.
Interpreto queste cifre come un segnale che la leadership attuale non è adatta ai nostri tempi. Ciò ha ripercussioni pesanti, che non possono essere la “colpa” di dipendenti svogliati.
La maggior parte delle aziende con cui collaboro sono in difficoltà. O prevedono di esserlo a breve.
Fatturato in diminuzione, turnover, disimpegno dei dipendenti, penali per ritardi nei rilasci, scarsa qualità dei prodotti (con relativi costi).
Questo è un chiaro problema di leadership, dal mio punto di vista.
Per cosa cambiare?
Mi ricordo di un colloquio con un dirigente, che mi disse: “Fabio ho la convinzione che dobbiamo cambiare qualcosa. Così non si può più andare avanti. Ma non so per cosa cambiare!“.
Purtroppo la soluzione magica non esiste. L’esperienza ha mostrato che nuove tecnologie, nuovi processi, nuovo management, più burocrazia non migliorano i problemi identificati sopra.
Il problema non è tecnico, è umano. Viviamo in azienda, come al di fuori, un problema di valori e principi.
Fabio Panzavolta
Ecco perché le aziende che prosperano hanno leader che mettono l’umano al centro. Hanno capito che il cambiamento richiede tempo, lavoro e che non può essere in nessun caso delegato a consulenti o strumenti tecnici.
Si cambia paradigma, modo di pensare… col tempo, un pò alla volta!
Photo by RODNAE Productions on Pexels.com
Come cambiare?
Facile da dire, ma come cambiare? Con 5 cambiamenti nella vostra leadership!
I dirigenti devono essere i primi a capire quali cambiamenti nel loro modo di pensare, agire e prendere decisioni sono necessari quando si creano prodotti complessi.
Devono dare l’esempio, aiutare i dipendenti a capire a loro volta, ma vediamo quali sono questi 5 cambiamenti nella vostra leadership!
Valori – dimostrare che ogni decisione e comportamento sono basati prima di tutto sul rispetto dei valori Scrum. Questo è molto importante, in quanto nel risolvere problemi complessi abbiamo bisogno di un ambiente di lavoro nel quale la “Psychological Safety” è presente. Un ambiente di lavoro psicologicamente sicuro, permetterà ai dipendenti di sperimentare, eventualmente fallire, imparare in fretta e innovare.
Approccio descrittivo – al contrario dei classici approcci prescrittivi (metodologie), che si sono rivelati dannosi in certi mestieri come l’informatica, un approccio descrittivo (tipo Scrum) sono un’insieme di principi e regole da seguire per lavorare insieme. Un pò come il libretto delle regole del monopoli, o degli scacchi. Questo tipo di approccio, unito al precedente, permette alle persone di utilizzare la propria intelligenza e esperienza appieno, rendendoli molto più implicati nella risoluzione di problemi complessi.
Farne il meno possible – quante volte siamo stati congratulati perché abbiamo lavorato molto… ma quanto utili per l’utilizzatore del prodotto è stato il nostro lavoro? Un cambiamento importante nella vostra leadership consiste a realizzare poche funzionalità, ma a forte impatto per l’utente finale. Ciò implica che un prodotto non sia sviluppato a compartimenti stagni e parlando al cliente una volta l’anno. Stimolare una collaborazione continua fra i dipendenti e il cliente per far emergere la realtà del bisogno.
Pensare obiettivi – un leader sa dove va, ha obiettivi chiari ed è capace di comunicarli chiaramente. Quindi passare da una mentalità orientata ai task ad una orientata obiettivi è un cambiamento non banale e importantissimo. Se vogliamo delle persone implicate e motivate al lavoro, dobbiamo smettere di dire agli altri cosa fare e cominciare a spiegare perché devono farlo!
Controllare il prodotto – corollario a tutto quanto visto sopra, controllare le persone è facile, ma inefficace. Molto del disimpegno al lavoro viene da questo problema. Imparare a giudicare le performance del prodotto sul mercato è una leadership più consona ai nostri tempi. Sfidare il team ad avere un prodotto sempre migliore, in linea con gli obiettivi aziendali, è uno dei punti chiave per migliorare la vostra leadership!
Ovviamente i punti precedenti non sono un ordine preciso e neppure esaustivi.
Penso però che siano significativi e possano aiutare a valutare il lavoro che vi aspetta per adattare la vostra leadership ai tempi moderni.
Mi piacerebbe vedere, nel prossimo rapporto di Gallup, l’Italia almeno al penultimo posto!
La facilitazione può essere utilizzata per condurre le persone verso obiettivi concordati in modo da incoraggiare la partecipazione, l’appropriazione e la creatività di tutti i soggetti coinvolti. Una sessione ben facilitata può sbloccare l’intelligenza collettiva e svolgere un ruolo importante nel fornire opportunità di progresso e successo alle persone. Una buona facilitazione consente la trasparenza e la collaborazione, crea sinergie e porta al raggiungimento di un obiettivo collettivo.
Un facilitatore svolge un ruolo importante nell’aiutare le persone a comprendere e a raggiungere gli obiettivi condivisi. Lo fa rimanendo neutrale e imparziale. I facilitatori creano un ambiente partecipativo e propositivo in cui le persone si sentono sicure di impegnarsi, imparare e collaborare. Incoraggiano le persone a esplorare prospettive diverse, a sfruttare la diversità e a far leva sulla saggezza collettiva.
Principi di facilitazione
I Valori di Scrum sono il cuore di un Team Scrum professionale e lo guidano nel lavoro, nelle azioni e nel comportamento. I valori di Scrum sono complementari ai principi di facilitazione: partecipativo, sano, trasparente, processo e finalità. Il richiamo a questi principi fondamentali può aiutare i facilitatori a lavorare con i team per raggiungere gli obiettivi in modo collaborativo in diverse situazioni. Questi principi possono anche aiutare i facilitatori a decidere quali abilità e tecniche di facilitazione possono essere appropriate e utili. Questo vale non solo quando si crea un ambiente energico in cui tutto il team è impegnato e concentrato sul raggiungimento dell’obiettivo, ma anche quando le interazioni non vanno come previsto.
Partecipativo – Il fulcro di una facilitazione efficace è la piena partecipazione e l’impegno, che consente di condividere la responsabilità in un team.
Sano – Un ambiente sicuro significa creare uno spazio sano in cui le persone si sentano al sicuro nel sollevare differenze e persino prospettive contrastanti, imparando rispettosamente gli uni dagli altri.
Trasparente – La trasparenza esiste solo quando c’è una comprensione condivisa.
Processo – La facilitazione deve consentire a un team di progredire verso l’obiettivo desiderato dell’interazione in un modo che sia collaborativo, inclusivo e che faccia leva su prospettive diverse.
Finalità – Le sessioni ben gestite devono avere un obiettivo chiaro con il quale tutti sono allineati e per il quale lavorano.
Competenze e caratteristiche di un facilitatore
I facilitatori possono provenire da diversi contesti e avere diversi livelli di esperienza. I grandi facilitatori, tuttavia, dimostrano le seguenti abilità e caratteristiche:
Ascolto attivo: un facilitatore ha la capacità di ascoltare attivamente e di concentrarsi completamente su ciò che viene detto e su ciò che non viene detto. Dall’esempio, ispirando i partecipanti a esprimersi pienamente e ad impegnarsi nell’ascolto attivo quando gli altri parlano.
Incoraggiare la curiosità: un facilitatore incoraggia la curiosità e i diversi punti di vista. È abile nel porre “powerful questions”, spesso aperte, per stimolare la riflessione e la discussione.
Risolvere i problemi: un facilitatore è abile nell’applicare tecniche di problem solving di gruppo. Può aiutare il gruppo a definire un problema, a riformularlo in una chiara dichiarazione del problema e a incoraggiare il gruppo a considerare una serie di soluzioni al problema.
Risolvere i conflitti: un facilitatore riconosce che il conflitto tra i membri del gruppo è naturale e, purché espresso in modo appropriato, non deve essere soppresso. Il conflitto deve essere previsto e affrontato in modo costruttivo e rispettoso.
Utilizzo di uno stile partecipativo: un facilitatore incoraggia tutti i partecipanti a impegnarsi attivamente e a contribuire alle attività e alle discussioni, a seconda del loro livello di comfort individuale. Ciò comporta la creazione di un’atmosfera sicura e confortevole, in cui i membri del gruppo siano disposti a condividere i loro pensieri e le loro idee.
Incoraggiare l’apertura: il facilitatore incoraggia il gruppo ad aprirsi alle idee, ai suggerimenti e alle prospettive degli altri.
Empatia e compassione: il facilitatore è comprensivo, consapevole e rispettoso dei sentimenti, delle prospettive o delle azioni degli altri.
Dimostrare leadership: il facilitatore guida un gruppo di persone a raggiungere gli obiettivi collettivi.
Costruire il consenso: il facilitatore è abile nell’aiutare i gruppi a raggiungere un accordo generale.
Gestire il tempo in modo efficace: un facilitatore mantiene la rotta pur consentendo la flessibilità. Si concentra sul raggiungimento dei risultati in un arco di tempo piuttosto che su un’agenda rigida. Una gestione del tempo troppo restrittiva può soffocare conversazioni e riflessioni valide e mirate, mentre una mancanza di gestione del tempo può limitare la concentrazione e i progressi.
Definizione degli obiettivi: un facilitatore comunica lo scopo di una riunione in modo chiaro e conciso. Questo può avvenire definendo un obiettivo generale forte (spesso in collaborazione con il team) invece di concentrarsi su un ordine del giorno rigido.
Comunicare in modo adeguato: il facilitatore comunica in modo efficace, utilizzando un linguaggio chiaro e conciso.
Essere organizzato: la facilitazione non inizia o finisce con l’atto di facilitare un gruppo di persone. Comprende la preparazione e il follow-up delle decisioni prese.
Perché la facilitazione è utile ai team Scrum?
Una comunicazione aperta e rispettosa aiuterà uno Scrum Team a prosperare come team autogestito. Mentre i membri di un team Scrum dovrebbero parlarsi ogni volta che ne hanno bisogno, Scrum assicura punti di comunicazione per il team negli eventi Scrum. Ogni evento ha uno scopo specifico e il team trae vantaggio dall’avere questi eventi facilitati con il risultato desiderato in mente.
Qualsiasi persona del team Scrum può facilitare gli eventi Scrum. Ad esempio, lo Sprint Planning è più efficace ed esplorativo quando qualcuno del team, in qualità di facilitatore oggettivo, sa come inquadrare i problemi per capire in che modo gli elementi del Product Backlog possono essere utili per i clienti. Un Developer può essere la persona ideale per farlo, data la sua familiarità con il prodotto.
Spesso gli eventi Scrum non vanno come previsto. Una buona e leggera facilitazione può aiutare i team Scrum a rimettersi in carreggiata. Per esempio, se lo Scrum Master osserva che il team utilizza continuamente il Daily Scrum come uno status update (reporting al manager) invece che come un’ispezione dei progressi verso lo Sprint Goal, allora lo Scrum Master può aiutare i membri del team a concentrarsi ricordando loro lo scopo dell’evento. Questo incoraggerà i membri del team a spostare la loro attenzione dai task al modo in cui possono collaborare per raggiungere lo Sprint Goal.
Assumere un ruolo di facilitatore è prezioso anche per il Product Owner, soprattutto durante la Sprint Review, quando lo Scrum Team e gli stakeholder verificano i progressi verso il Product Goal, raccolgono il feedback degli stakeholder e adattano il Product Backlog di conseguenza. Se ben fatto, il Product Owner e i Developers possono imparare e ascoltare le diverse opinioni degli stakeholder. Se non lo si fa bene, il Product Owner rischia di ancorare o limitare le informazioni raccolte, riducendo l’efficacia della Sprint Review.
Ecco altre risorse sulle tecniche di facilitazione e per aiutarvi a sviluppare l’abilità della facilitazione:
Associazione Internazionale dei Facilitatori – L’Associazione Internazionale dei Facilitatori (IAF) è un’organizzazione partecipativa internazionale che fornisce accreditamento, comunità e formazione sul potere della facilitazione.
The Grove – facilitazione e facilitazione grafica dal 1977
Digital Facilitation – il blog di Rachel Smith, eccellente prof di facilitazione grafica digitale
Liberating Structures – le Liberating Structures sono microstrutture che migliorano il coordinamento relazionale e favoriscono la partecipazione vivace nei gruppi, rendendo possibile l’inclusione di tutti.
Tasty Cupcakes – un sito web gestito dalla comunità con diversi giochi, tecniche e approcci per la facilitazione.
SeriousWork – Tecniche di facilitazione per l’apprendimento basato sulla pratica
Formazione professionale sulle competenze di facilitazione Scrum
Professional Scrum Facilitation Skills
In questo corso di formazione, i partecipanti impareranno a diventare migliori facilitatori per migliorare le interazioni nello Scrum Team, gli stakeholder e i clienti. Si concentreranno su come adottare la facilitazione come atteggiamento e come attivare i valori di Scrum. Gli studenti affronteranno una serie di scenari comuni legati a Scrum applicando diverse tecniche di facilitazione che potranno aggiungere alla loro collezione di pratiche agili. Creeranno e lasceranno il proprio “piano” di facilitazione per migliorare la prossima discussione di gruppo o il prossimo evento Scrum.
Quando si cerca di prevedere il futuro, si è raramente nel giusto. Le stime probabilistiche aiutano a migliorare le previsioni di uno Scrum Team.
Foto di Brian McGowan su unsplash.com
Questo articolo da per scontato che il lettore conosce e pratica già Scrum, i concetti di velocità, story points e le problematiche legate alle stime.
Questa è la trascrizione (ndr. adattata da Fabio Panzavolta) dell’intervista di Michael Forni, nella quale ha condiviso la sua esperienza nell’uso di stime probabilistiche ed i vantaggi che ha potuto osservare. Grazie Michael!
Stimare e quantificare il lavoro da fare durante uno Sprint non è cosa facile. Cosa e come rispondere alla domanda del Product Owner: “quando sarà pronto?”.
Adottare stime probabilistiche, più efficaci delle classiche stime deterministiche basate su story points, può essere una soluzione.
Contesto
Il team che Michael ha aiutato, aveva raggiunto un livello di coesione, collaborazione e affidabilità nelle stime che li ha portati a voler andare oltre.
Questo è naturale perché Scrum è un framework che ci permette di adattarci in permanenza ai cambiamenti e diventare sempre migliori.
Se oggi il vostro team non è ancora capace di fare stime deterministiche, basate su story points e velocità, probabilmente allora non sarà ancora pronto per le stime probabilistiche.
Un consiglio: aiutate il team a maturare, facendo in modo di dare il gusto di migliorarsi continuamente e supportatelo nel viaggio unico che stanno intraprendendo, con pazienza e assiduità.
A quale problema si cerca di rispondere
Il Product Owner non trovava più soddisfacente, anche a livello personale, rispondere alla domanda: “ma il lavoro quando sarà pronto?”.
Usando il metodo tradizionale, con story point e velocità, se abbiamo 150 story points di lavoro e sappiamo che più o meno siamo in grado di fare 50 story points a Sprint, in tre Sprint avremo finito.
Questo però non ci aiuta a sapere quando una specifica “storia” sarà pronta oppure, in caso di cambiamento nell’ordine del Product Backlog, quando saranno pronti gli item che ora hanno più valore?
In questo caso la velocità e gli story points non sono così efficaci per rispondere a questa domanda.
Le stime probabilistiche, contrariamente a quelle deterministiche, indicheranno l’affidabilità dell’informazione che forniamo, indicando la probabilità di successo.
Professional Scrum With kanban
Questi concetti fanno parte di Kanban, che ci viene in aiuto e può essere un buon complemento a Scrum.
Kanban è un insieme di pratiche, abitudini e strumenti che aiutano a migliorare il flusso di lavoro e a rilasciare valore più rapidamente.
Michael ha seguito questa formazione che ha trovato utile per capire che Scrum con Kanban è ancora 100% Scrum ed ha ancora più valore.
Cycle Time
Il Cycle Time è una metrica probabilistica che si calcola misurando quando (con data tipicamente) un oggetto (ndr Product Backlog Item) entra nel sistema (ndr. Sprint) ed il giorno in cui esce. Usando la definizione di Ready e la definizione di Done per decidere cosa entra e cosa esce.
Questa metrica si calcola in giorni e corrisponde al “Cycle Time”. Questo è il calcolo che si è cominciato a fare nel team aiutato da Michael.
Item Age (éta)
Per vedere quanto manca a destinazione usiamo un’altra metrica di Kanban: l'”età dell’item”, o semplicemente “età”, che ci dice quanto sta invecchiando il nostro item nella Scrum board.
Più l’età aumenta, più è probabile che ci sia un problema, un ostacolo o comunque una situazione da analizzare e capire.
L’item esce dal sistema dopo un certo numero di giorni rivelando quello che è il cycle time: 3, 5, x giorni.
La prima indicazione è che quando un item ha un cycle time più lungo di uno Sprint vuol dire che non è abbastanza piccolo e il team cerca una soluzione a questo problema.
Lead Time
A differenza del cycle time, il Lead Time Corrisponde al tempo trascorso da quando l’item è entrato nel Product Backlog a quando è in produzione e gli utenti ne traggono effettivo beneficio.
Il lead time è un tempo superiore al cycle time.
Lead & Cycle Time
Throughput (portata)
Un altra metrica Kanban, lo Throughput (portata), è utile per le stime probabilistiche e corrisponde al numero di item che hanno “attraversato il sistema” in un certo periodo di tempo.
Questa metrica è ciò che ci permette di abbandonare gli story points, a condizione di essere capaci di avere Product Backlog Items di dimensioni simili.
È una delle ragioni per le quali lo Scrum Team deve essere abbastanza maturo per aver capito e saper lavorare su Product Backlog Items di piccole dimensioni.
Carte Planning Poker
Si può arrivare a questo risultato passo dopo passo, per esempio continuando ad utilizzare il Planning Poker per stimare gli story points di un Product Backlog Item sfidandosi, durante il Product Backlog Refinement, ad ottenere items piccoli ed il più possibile della stessa dimensione.
Senza cambiare le abitudini dello Scrum Team, il focus può passare dagli story points alla quantità di Product Backlog Items che sono state terminate alla fine dello Sprint.
Michael Forni
Quindi si possono continuare ad usare Story Points e velocità, che piano piano perderanno importanza, sostituendoli con il numero di items e la loro probabilità di essere effettivamente terminati alla fine dello Sprint sulla base dei throughput precedenti.
Allora, per esempio, il Product Owner potrà affermare con gli Stakeholder che, per la fine dello Sprint, 7 items saranno terminati con una probabilità del 90%; 10 items con una probabilità del 70%, ecc.
Questo aiuta molto il Product Owner professionista a gestire le aspettative con gli Stakeholder, perché non si attiva più il conflitto basato sulle sensazioni, in quanto si utilizzano dati probabilistici per le previsioni tanto più affidabili quanto il sistema è performante nel suo insieme.
Vantaggi di stime probabilistiche
Uno dei vantaggi delle stime probabilistiche, contrariamente a quelle deterministiche, consiste ad essere capaci di fare previsioni future anche su ipotesi di contenuto di Product Backlog. Quando finiremo se abbiamo un Product Backlog con 100 items?
Ovviamente fermo restando che nello sviluppo di un prodotto complesso l’imprevisto è sempre dietro l’angolo e potrebbe cambiare le nostre previsioni.
Più il livello di conoscenza e di padronanza del prodotto e del business saranno grandi, più precisi saranno le previsioni.
Quello che si è capaci di affermare è, per esempio: “con un livello di 85% di probabilità/certezza, sappiamo che un Product Backlog Item che entra nel sistema oggi ne uscirà in 6 giorni o meno”.
Possiamo affermare quando sopra perché questo Scrum Team è in grado di garantire questo livello di output probabilistico.
Conclusione
Studi interessanti di Vasco Duarte, dimostrano che, confrontando uno Scrum Team che per dieci Sprint ha fatto stime deterministiche con story points e velocity con uno che ha utilizzato lo throughput, la capacità di prevedere il futuro è invariata o addirittura migliorata grazie alle stime probabilistiche.
Se il vostro team ha dimostrato, con dati alla mano, di essere capaci di valutare la complessità del lavoro dopo aver ridotto le storie alla dimensione minime possibile, allora è probabile (non certo ovviamente) che possano cominciare a contare le storie perché non c’è più bisogno di considerarle con una stima comparativa.
Ciò permette anche di apprezzare la “potenza” di uno Scrum Team professionale, non solo in termini di capacità a creare valore, ma anche di prevedere in modo probabilistico il futuro.
Per approfondire le stime probabilistiche
Qui di seguito trovate i riferimenti utili per approfondire questi argomenti:
Spesso in formazione si discutono le differenze fra metodologia e framework. In questo articolo troverete la risposta alla domanda: “Perché Scrum non è una metodologia?”
Una metodologia di lavoro consiste ad applicare sempre lo stesso processo, con gli stessi input e output, per realizzare il lavoro. L’obiettivo è di ridurre i rischi e rendere il risultato del lavoro prevedibile.
L’apparizione delle metodologie di lavoro risale al periodo della rivoluzione industriale, l’esempio classico è la catena di montaggio che è pensata per assemblare diversi componenti il più rapidamente possibile ed ottenere come risultato finale il prodotto voluto. Una metodologia ottimizza l’output che si vuole creare, il risultato finale è conosciuto in anticipo.
Con l’avvento di nuovi mestieri, come l’informatica, profondamente differenti dal concetto di una catena di montaggio, si è applicato ciò che si conosceva, trascurando il fatto che la soluzione ad un problema non era conosciuta in anticipo. Ciò ha creato tensioni e problemi di vario tipo fra i lavoratori e il management.
Una metodologia è utile per risolvere un problema semplice, è un’approccio predittivo che presuppone la conoscenza anticipata dello stato finale che si vuole raggiungere.
Fabio Panzavolta
l’evoluzione del pensiero
Nel 1990 alcuni professionisti del mondo dell’informatica, fra i quali Ken Schwaber e Jeff Sutherland (creatori di Scrum) hanno capito che i ritardi, la scarsa qualità e le inefficienze nella creazione di software non erano dovute alle persone che non lavoravano abbastanza duramente, o che non applicavano correttamente la metodologia, bensì al paradigma adottato.
Prima con Extreme Programming poi con Scrum, le cose hanno cominciato a cambiare. L’accettazione del fatto che non si può prevedere in anticipo tutto il lavoro necessario alla creazione di un prodotto complesso ha lasciato lo spazio ad un cambiamento di paradigma.
L’empirismo a preso il posto del determinismo. Un processo empirico basa tutte le decisioni future sull’esperienza passata: la soluzione ad un problema, la creazione di un prodotto o servizio emergono dal feedback ricevuto dall’utilizzatore.
Ken Schwaber, co-creatore di Scrum, in questo articolo descrive le organizzazioni moderne prendendo come metafora il film “La tempesta perfetta” dove una serie di circostanze sfortunate e concomitanti creano una situazione praticamente incontrollabile per l’equipaggio del peschereccio. È evidente come, in questo contesto, nessun tipo di metodologia potrà aiutare l’equipaggio a sopravvivere. Al contrario, la sperimentazione di diverse manovre è necessaria per capire come la barca reagisce e trovare la via d’uscita.
LONDON, ENGLAND – MARCH 09: Federico Ruzza of Italy is tackled by Jamie George of England during the Guinness Six Nations match between England and Italy at Twickenham Stadium on March 09, 2019 in London, England. (Photo by Michael Steele/Getty Images)
Ecco perché Scrum non è una metodologia! Spesso descriviamo Scrum come un gioco di società, oppure come il Rugby, con le proprie regole, principi e valori. Se si vuole giocare a Scrum, bisogna avere il coraggio di affrontare l’incertezza e sperimentare diverse soluzioni fino a trovare quella più adatta al momento.
Scrum permette di navigare l’incertezza, esplorando diverse soluzioni adattative per risolvere problemi complessi.
Fabio Panzavolta
Conclusione
Perché Scrum non è una metodologia? Perché Scrum lascia le persone libere di prendere decisioni per adattarsi a qualsiasi situazione e seguendo poche regole semplici. Basti pensare che lo Scrum Guide in inglese è un libretto di 13 pagine!
Nella tabella qui sotto riassumo alcune differenze fra una metodologia ed un framework, con l’obiettivo di comprenderne la differenze ed aiutare nella scelta migliore per il problema che dovete risolvere.
Metodologia
Framework
Un processo predefinito e ripetitivo, con gli stessi step, input e output da applicare meccanicamente
Delle regole, principi e valori da seguire per creare un processo empirico adatto al problema da risolvere
Deterministico
Empirico
La soluzione è immaginata all’inizio
La soluzione emerge grazie al feedback degli utilizzatori
Utile quando è tutto sotto controllo, pochi cambiamenti e si ha una conoscenza estesa del lavoro
Utile in contesti complessi, con molti cambiamenti e incertezza sulla soluzione da fornire per un problema dato
Le persone seguono le istruzioni, poca comunicazione, divisione e specializzazione del lavoro
Le persone seguono le stesse regole, principi e valori. Comunicano e collaborano nella ricerca della soluzione attraverso la sperimentazione.
Gli elementi associati a Scrum sono strumenti, pratiche e più in generale “tattiche di gioco”, che non sono obbligatorie in Scrum e che si sono rivelate utili nel tempo.
Tuttavia, in un contesto di complessità e imprevedibilità, non è automatico che questi elementi associati a Scrum vi siano utili.
Suggeriamo di sperimentarli e, eventualmente, adattarli al proprio contesto in maniera empirica.
Gli elementi associati a Scrum non dovrebbero essere imposti ad uno Scrum Team, eccone un elenco non esaustivo.
Product Backlog Refinement: si tratta di un’attività ricorrente, durante la quale lo Scrum Team aggiunge dettaglio agli elementi del Product Backlog. Questa attività è molto utile quando diversi Scrum Team lavorano insieme per creare un prodotto o servizio. La durata e la frequenza di questa sessione di lavoro è definita dallo Scrum Team.
Esempio di Burndown chart
Burndown chart: un modo per rappresentare visivamente il lavoro svolto e ancora da fare. Può essere applicato sia al Product Backlog che allo Sprint Backlog. Fornisce trasparenza sullo stato di raggiungimento dello Sprint Goal. Spesso assume la forma di un grafico che mostra sull’asse verticale la quantità di lavoro e sull’asse
Carte Poker Planning
Poker Planning: tecnica per stimare la complessità del lavoro da svolgere. Un gioco divertente che permette ai Developers di allinearsi su un determinato argomento e comprenderne la complessità. Planning Poker si basa sulla sequenza di Fibonacci, presentata sotto forma di carte da gioco (un esempio delle carte Collective Genius fornite ai partecipanti durante una formazione). Ciascun partecipante, una volta discussa l’elemento del Product Backlog, sceglie una carta corrispondente al livello di complessità di realizzazione che percepisce (0 poco complesso, 55 molto complesso). I Developers girano le proprie carte contemporaneamente, rivelando così la propria percezione della complessità, senza esserne influenzati. Potrebbero esserci differenze nelle stime, nel qual caso gli estremi motivano la loro scelta e, dopo aver discusso le differenze i partecipanti rivotano. Alla fine otterremo una stima dei Developers, non di una singola persona.
Business Model Canvas: è un modo per creare un business case agile in modo collaborativo e guidato. Usiamo questo Canvas nei nostri corsi di formazione Professional Scrum Product Owner per esplorare le diverse strategie business riconducibili alla visione aziendale.
E tu, quali altri elementi associ a Scrum?
Le Basi di Scrum – Elementi associati a Scrum
Scarica e stampa (in A4 o A3) il poster relativo a questo articolo, può essere utile per te in ufficio, i codici QR consentono di approfondire la conoscenza del framework Scrum!
Questo articolo fa parte di una serie di dodici pubblicazioni, ognuna delle quali spiega le basi di Scrum, secondo lo Scrum Guide. Potrebbe essere utile per te come presentazione alla direzione o per chiunque sia curioso di approfondire l’argomento.
Clicca l’immagine per ascoltare l’episodio del Podcast
Un Increment è un primo passo concreto verso il Product Goal ed è l’ultima versione del prodotto. È utilizzabile e potenzialmente pubblicabile in produzione.
Un Increment fornisce valore agli utilizzatori del prodotto.
Durante uno Sprint è possibile creare più Incrementi e potenzialmente rilasciarli durante lo Sprint, la somma degli incrementi viene ispezionata durante la Sprint Review. Il lavoro può essere considerato parte di un incremento solo se soddisfa la definizione di Done.
Le Basi di Scrum – Artefatti Scrum: Increment
Commitment: Definizione di Done
La Definizione di Done è una descrizione formale dello stato dell’Incremento quando soddisfa le misure di qualità richieste per il prodotto.
La definizione di Done crea trasparenza consentendo a tutti di comprendere il lavoro svolto nel contesto dell’Increment.
Se la definizione di fatto fa parte degli standard dell’organizzazione, tutti gli Scrum Team devono seguirla, eventualmente arricchendola. In caso contrario, lo Scrum Team deve creare una definizione appropriata di Done per il prodotto.
I Developers sono tenuti a rispettare la definizione di Done. Se più team Scrum lavorano insieme su un prodotto, devono definire una definizione di Done unica che prenda in considerazione le problematiche di integrazione.
Scarica e stampa (in A4 o A3) il poster relativo a questo articolo, può essere utile per te in ufficio, i codici QR consentono di approfondire gli argomenti proposti!
Questo articolo fa parte di una serie di dodici pubblicazioni, ognuna delle quali spiega le basi di Scrum, secondo lo Scrum Guide. Potrebbe essere utile per te come presentazione alla direzione o per chiunque sia curioso di approfondire l’argomento.
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.
