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 episodio esploriamo lo Sprint Backlog, un artefatto di Scrum che comprende lo Sprint Goal, gli elementi del Product Backlog selezionati per lo Sprint e il piano per la realizzazione dell’Incremento. Scopriremo come questo strumento supporta l’autogestione del team e contribuisce al successo dello Sprint.
🎧 Ascolta l’Episodio
🎯 Cos’è lo Sprint Backlog
Lo Sprint Backlog è un artefatto gestito dai Developer, contiene la pianificazione dello Sprint che si compone di tre elementi essenziali:
Lo Sprint Goal (il perché)
Gli elementi selezionati dal Product Backlog (il cosa)
Il piano attuabile per la consegna dell’Incremento (il come)
“Lo Sprint Backlog non è solo un elenco di attività, ma uno strumento che promuove l’autogestione e la collaborazione del team. La chiave del successo sta nella sua trasparenza e nella capacità di adattarsi alle scoperte fatte durante lo Sprint, mantenendo sempre il focus sullo Sprint Goal.”
🔜 Prossimo Episodio
Non perdete il prossimo episodio dove approfondiremo la Sprint Review in Scrum.
Questo articolo è basato sull’episodio 18 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.
Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.
In questo episodio esploriamo il Product Backlog, uno degli artefatti di Scrum che rappresenta l’unica fonte di lavoro per lo Scrum Team. Scopriremo come questo “living artifact” evolve nel tempo e come contribuisce al successo del prodotto attraverso una gestione efficace e collaborativa.
🎧 Ascolta l’Episodio
🎯 Cos’è il Product Backlog
Il Product Backlog è un elenco emergente e ordinato di tutto ciò che è necessario per migliorare il prodotto. Rappresenta:
L’unica fonte di lavoro per lo Scrum Team
Un documento vivente che evolve con il prodotto
Il punto di riferimento per qualsiasi modifica o miglioramento
🔄 Caratteristiche Principali
Elementi Ready
Gli elementi nella parte alta del Product Backlog sono considerati “Ready”
Sufficientemente dettagliati per essere selezionati nello Sprint Planning
Raggiungono la trasparenza necessaria dopo il Refinement
Product Backlog Refinement
Attività continuativa di scomposizione degli elementi
Il Product Backlog refinement aggiunge dettagli come descrizione, ordine e dimensione
Serve come obiettivo a lungo termine per lo Scrum Team
Deve essere raggiunto o abbandonato prima di definirne uno nuovo
È visibile nel Product Backlog
⚙️ Best Practices
Gestione Product Backlog
Elementi più piccoli e atomici possibile
Trasparenza nel movimento delle attività
Gestione efficace attraverso la collaborazione continua
Visibilità degli impegni del team
Responsabilità e Ruoli
Lo Scrum Product Owner gestisce il Product Backlog
Developers stimano la dimensione degli elementi
Tutto lo Scrum Team partecipa al Refinement
Product Owner definisce il Product Goal
Responsabilità e Ruoli
Product Owner gestisce il Product Backlog
Developers stimano la dimensione degli elementi
Tutto lo Scrum Team partecipa al Refinement
Product Owner definisce il Product Goal
📚 Approfondimenti Consigliati
La Scrum Guide: Product Backlog e Product Goal
Tecniche di Refinement efficace
Gestione degli elementi del Product Backlog
Pattern di collaborazione nel Refinement
🎓 Note del Trainer
“Il Product Backlog non è una semplice lista di requisiti, ma un artefatto vivente che riflette l’evoluzione del prodotto e le necessità degli stakeholder. La chiave del successo sta nella sua gestione dinamica e nella collaborazione continua tra Product Owner e Developers.”
🔜 Prossimo Episodio
Non perdete il prossimo episodio dove approfondiremo lo Sprint Review in Scrum.
Questo articolo è basato sull’episodio 17 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.
Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.
In questo episodio esploriamo gli artefatti di Scrum: Product Backlog, Sprint Backlog e Increment. Scopriremo come questi elementi fondamentali del framework rappresentano il lavoro e il valore, e come sono collegati ai rispettivi impegni (commitment) che ne garantiscono l’efficacia.
🎧 Ascolta l’Episodio
🎯 Cos’è un Artefatto in Scrum
Un artefatto in Scrum è un elemento creato dall’intelligenza umana che rappresenta informazione, lavoro o valore. Gli artefatti sono progettati per:
Massimizzare la trasparenza delle informazioni chiave
Fornire una base comune per l’ispezione e l’adattamento
Garantire la visibilità dell’avanzamento del lavoro
🔄 I Tre Artefatti Principali
Product Backlog
Contiene tutto il lavoro da realizzare per il prodotto
È associato al Product Goal come impegno
Rappresenta la visione a medio-lungo termine
Sprint Backlog
Contiene il lavoro pianificato per lo Sprint corrente
È legato allo Sprint Goal come impegno
Ha una durata massima di un mese
Increment
Rappresenta l’ultima versione del prodotto
È associato alla Definition of Done come impegno
Riflette l’approccio iterativo e incrementale di Scrum
💡 Gli Impegni (Commitment)
Ogni artefatto è associato a un impegno specifico:
Product Goal: Impegno a medio termine visibile nel Product Backlog
Sprint Goal: Impegno a breve termine (massimo un mese) visibile nello Sprint Backlog
Definition of Done: Impegno sulla qualità dell’Increment
⚙️ Importanza degli Impegni
Gli impegni in Scrum:
Rinforzano l’empirismo e i valori Scrum
Garantiscono la trasparenza per il team e gli stakeholder
Supportano il processo decisionale
Mantengono alta la qualità del prodotto
📚 Approfondimenti Consigliati
La Scrum Guide: Artefatti e loro impegni
Pattern di trasparenza in Scrum
Gestione efficace degli artefatti
Metriche per misurare l’avanzamento
🎓 Note del Trainer
“Gli artefatti in Scrum non sono semplici documenti o deliverable, ma rappresentano impegni concreti che il team prende verso la qualità e il valore. La loro corretta gestione è fondamentale per mantenere la trasparenza e permettere un’efficace ispezione e adattamento.”
🔜 Prossimo Episodio
Non perdete il prossimo episodio dove approfondiremo il Product Backlog e il Product Goal in dettaglio.
Questo articolo è basato sull’episodio 16 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.
Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.
In questo episodio esploriamo la Sprint Retrospective agile, l’evento conclusivo dello Sprint dedicato al miglioramento continuo del team. Scopriremo come questa retrospettiva Scrum permette allo Scrum Team di evolvere e ottimizzare il proprio modo di lavorare, garantendo maggiore efficacia e qualità Sprint dopo Sprint.
🎧 Ascolta l’Episodio
🎯 Cos’è la Sprint Retrospective
La Sprint Retrospective Scrum è l’evento finale dello Sprint dove l’intero Scrum Team si riunisce per migliorare la Scrum Team effectiveness. Gli obiettivi principali sono:
Analizzare l’andamento dello Sprint concluso
Identificare punti di forza e aree di miglioramento
Pianificare azioni concrete per ottimizzare il lavoro futuro
Incrementare qualità ed efficacia del team
🔄 Caratteristiche Principali
Timeboxing e Partecipanti
Durata massima: 3 ore per Sprint mensili
Durata proporzionalmente minore per Sprint più brevi
Partecipanti: intero Scrum Team (Developers, Product Owner, Scrum Master)
Focus sull’Ispezione
Come parte fondamentale degli Scrum events, lo Scrum Team ispeziona:
Relazioni e interazioni tra i membri
Processi di sviluppo
Strumenti utilizzati
Definition of Done
Dinamiche con gli stakeholder
💡 Elementi Chiave per il Successo
Psychological Safety Scrum
Creazione di un ambiente sicuro per l’espressione
Importanza della trasparenza e del feedback onesto
Possibilità di comunicare liberamente preoccupazioni e proposte
Tecniche di Facilitazione della Retrospettiva
Utilizzo di post-it per coinvolgere anche i più introversi
Atmosfera informale ma produttiva
Esercizi di team building e discussione strutturata
Strumenti di facilitazione retrospettiva specifici per team distribuiti
Focus sulle Azioni
Identificazione di almeno un’azione di miglioramento concreta
“La Sprint Retrospective non è solo un momento di riflessione, ma un’opportunità concreta per evolvere la Scrum Team effectiveness. Il segreto sta nel bilanciare la serietà dell’evento con un’atmosfera che favorisca l’apertura e la partecipazione attiva di tutti i membri del team.”
🔜 Prossimo Episodio
Non perdete il prossimo episodio dove approfondiremo gli artefatti di Scrum.
Questo articolo è basato sull’episodio 15 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.
Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.
In questo episodio, approfondiamo la Sprint Review, un evento cruciale di Scrum che si concentra sull’ispezione dei risultati dello Sprint e sull’adattamento dei piani futuri. Scopriamo come i Team Scrum possono trasformare questo evento da una semplice presentazione a una sessione di lavoro collaborativa che aumenta il valore del prodotto e il coinvolgimento degli stakeholder.
🎧 Ascolta l’Episodio
🎯 Cos’è la Sprint Review
La Sprint Review è il penultimo evento dello Sprint, timeboxed a un massimo di 4 ore per uno Sprint di un mese. I suoi scopi principali sono:
Ispezionare il risultato dello Sprint
Determinare i futuri adattamenti
Verificare i progressi verso il Product Goal
Collaborare con gli stakeholder sui prossimi passi
🔄 Caratteristiche Principali
Timeboxing e Partecipanti
Durata massima: 4 ore per Sprint di un mese (generalmente più breve per Sprint più corti)
Coinvolge l’intero Scrum Team
Include gli stakeholder chiave
Focus sulla collaborazione invece che sulla presentazione
Struttura Efficace
Verifica del raggiungimento dello Sprint Goal
Utilizzo dell’Increment funzionante
Feedback e interazione con gli stakeholder
Discussione del Product Backlog e direzione futura
Previsione della timeline di consegna
💡 Benefici della Sprint Review
Feedback diretto degli stakeholder sul prodotto funzionante
Maggiore trasparenza dei progressi
Migliore collaborazione tra Scrum Team e stakeholder
Maggior allineamento con le esigenze degli utenti
Identificazione precoce delle necessità di adattamento
⚙️ Best Practices
Coinvolgimento degli Stakeholder
Invitare stakeholder rilevanti che useranno o saranno impattati dal prodotto
Spiegare lo scopo e l’importanza della loro partecipazione
Fornire interazione diretta con il prodotto
Raccogliere e organizzare il feedback sistematicamente
Gestione della Sessione
Mantenere la presentazione iniziale breve (20-30 minuti)
Concentrarsi sull’utilizzo del prodotto funzionante
Utilizzare strumenti come feedback board (Mi piace/Da migliorare/Nuove idee)
Riservare tempo per la discussione collaborativa
Condividere il potenziale Sprint Goal successivo e la direzione del Product Backlog
📚 Errori Comuni da Evitare
Trasformarla in una presentazione PowerPoint
Limitare la partecipazione al solo Scrum Team
Mostrare solo video o screenshot invece del prodotto funzionante
Presentare al Product Owner invece che agli stakeholder esterni
Non raccogliere feedback actionable
🎓 Note del Trainer
“La forza della Sprint Review sta nella sua natura collaborativa. Quando i team vanno oltre le semplici presentazioni e attivano un vero coinvolgimento degli stakeholder con il prodotto funzionante, sbloccano preziosi insight e creano un allineamento più forte con le esigenze degli utenti. Ricordate, non è una riunione di reporting – è una sessione di lavoro che guida il valore del prodotto.”
🔜 Prossimo Episodio
Non perdete il prossimo episodio dove esploreremo la Sprint Retrospective in Scrum.
Questo articolo è basato sull’episodio 14 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.
Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.
In questo episodio esploriamo il Daily Scrum, noto anche come daily standup, l’evento quotidiano di 15 minuti che permette ai Developer di sincronizzarsi e pianificare il lavoro delle successive 24 ore. Scopriremo come questo evento del framework Scrum contribuisce al successo dello Sprint e del team.
🎧 Ascolta l’Episodio
🎯 Cos’è il Daily Scrum
Il Daily Scrum, spesso chiamato anche scrum daily meeting, è un evento di 15 minuti che coinvolge i Developer dello Scrum Team. Il suo scopo principale è:
Ispezionare l’avanzamento verso lo Sprint Goal
Adattare lo Sprint Backlog secondo le esigenze
Pianificare il lavoro delle prossime 24 ore
🔄 Caratteristiche Principali
Timeboxing e Partecipanti
Durata massima: 15 minuti
Si tiene ogni giorno, idealmente alla stessa ora e luogo
Partecipanti principali: Developer
Product Owner e Scrum Master possono assistere (se autorizzati dai developers) o partecipare come Developer (se contribuiscono alla creazione dell’Increment)
Focus sull’Autogestione
I Developer scelgono struttura e tecnica preferita per il daily standup
Concentrazione sullo Sprint Goal
Promozione dell’autogestione del team
💡 Benefici del Daily Scrum
Migliora la comunicazione nel team
Identifica rapidamente gli impedimenti
Promuove il processo decisionale veloce
Elimina la necessità di altri meeting
Aumenta la trasparenza del lavoro
⚙️ Best Practices
Gestione Efficace
Task dimensionati per essere completati in una giornata
Visibilità del movimento delle attività
Identificazione rapida dei problemi
Collaborazione invece di lavoro in silos
Gestione delle Discussioni
Separare rilevazione e risoluzione dei problemi
Utilizzare post-it per tracciare temi da approfondire
Pianificare discussioni separate per i dettagli tecnici dopo il daily scrum meeting
Tecniche di facilitazione per Daily Scrum efficaci
Metriche e visualizzazione dell’avanzamento
Pattern di comunicazione efficace nei meeting agili
🎓 Note del Trainer
“Il Daily Scrum non è solo un momento di aggiornamento, ma una vera e propria occasione per i Developers di sincronizzarsi e mantenere il focus sullo Sprint Goal. La chiave del successo sta nella sua regolarità e nella capacità di mantenere l’evento conciso e focalizzato.”
🔜 Prossimo Episodio
Non perdete il prossimo episodio dove approfondiremo la Sprint Review in Scrum.
Questo articolo è basato sull’episodio 13 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.
Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.
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!]
In questo episodio, esploriamo lo Sprint Planning secondo la Scrum Guide (versione Novembre 2020). Analizziamo come questo evento dà il via allo Sprint e stabilisce le basi per il successo del team.
🎧 Ascolta l’Episodio
🎯 I Tre Argomenti dello Sprint Planning
1. Perché questo Sprint è di valore?
Il Product Owner propone come incrementare valore nel prodotto
Lo Scrum Team collabora per definire lo Sprint Goal
Focus sugli outcome per gli stakeholder
2. Cosa si può fare in questo Sprint?
I Developer selezionano elementi dal Product Backlog
Selezione basata su:
Performance precedenti
Capacità futura
Definition of Done
3. Come si svolgerà il lavoro?
Decomposizione in task giornalieri
Pianificazione tecnica dettagliata
Autonomia dei Developer nelle decisioni
⏱️ Timeboxing e Struttura
8 ore massimo per Sprint mensili
Proporzionalmente più breve per Sprint più corti
Concentrazione delle attività di pianificazione
🔄 Lo Sprint Backlog
Include:
Sprint Goal (commitment fisso)
Elementi del Product Backlog selezionati
Piano di consegna dettagliato
💡 Punti Chiave
Lavoro collaborativo dell’intero Scrum Team
Autonomia dei Developer nella selezione del lavoro
Flessibilità nella pianificazione dettagliata
Focus sulla trasparenza e comunicazione
📚 Approfondimenti Consigliati
Scrum Guide 2020
Sprint Goal e sua importanza
Tecniche di decomposizione del lavoro
Stima e previsione in Scrum
🎓 Note del Trainer
“Lo Sprint Planning è come un concentratore di riunioni. Tutto quello che c’è da fare per il prossimo mese è discusso durante queste ore, eliminando la necessità di ulteriori incontri di pianificazione.”
🔜 Prossimo Episodio
Non perdete il prossimo episodio dove approfondiremo il Daily Scrum e la loro importanza nell’ispezione e adattamento quotidiano.
Questo articolo è basato sull’episodio 12 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.
Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.
In questo episodio, esploriamo gli Eventi Scrum secondo la Guida Scrum (versione Novembre 2020), con particolare attenzione allo Sprint come contenitore di tutti gli altri eventi. Analizzeremo come questi eventi creano regolarità e supportano l’ispezione e l’adattamento continui.
🎧 Ascolta l’Episodio
🔄 Gli Eventi Scrum: Fondamenti
Gli eventi in Scrum nello Scrum Framework sono occasioni formali per ispezionare e adattare gli artefatti. Progettati per:
Garantire la trasparenza necessaria
Creare regolarità nel processo
Minimizzare riunioni non definite
Facilitare l’ispezione e l’adattamento
🎯 Lo Sprint: Il Cuore di Scrum
Lo Sprint è l’evento principale dove:
Le idee si trasformano in valore
Ha una durata fissa (massimo un mese)
Include tutti gli altri eventi Scrum
Mantiene costante la qualità
Permette la rinegoziazione dell’ambito (scope)
⏱️ Durata dello Sprint
La scelta della durata si basa su tre fattori:
Livello di rischio e incertezza
Sincronizzazione con eventi esterni
Limite massimo di un mese
📊 Prevedibilità e Metriche
Utilizzo di burn-down, burn-up, flussi cumulativi
Importanza dei dati empirici
Focus sulla previsione basata sull’esperienza
🛑 Annullamento dello Sprint
Solo il Product Owner può annullare uno Sprint
L’unica ragione: Sprint Goal obsoleto
Processo post-annullamento
📚 Approfondimenti Consigliati
Teoria dell’empirismo nello Scrum Framework
Gestione degli eventi secondo la Scrum Guide
Ruolo del Product Owner
Metriche e visualizzazione dell’avanzamento
🎓 Note del Trainer
“Gli eventi in Scrum costituiscono l’opportunità di ispezionare e adattare l’incremento di prodotto. Lo Sprint è come il battito cardiaco che dà il ritmo al processo, permettendoci di lavorare in modo empirico e limitare i rischi.”
🔜 Prossimo Episodio
Non perdete il prossimo episodio dove approfondiremo lo Sprint Planning.
Questo articolo è basato sull’episodio 11 del podcast Scrum Italia con Fabio Panzavolta, Professional Scrum Trainer certificato Scrum.org.
Vuoi approfondire Scrum? Visita Collective Genius per risorse, formazione e consulenza professionale.
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.