Blog

Le Basi di Scrum - Eventi Scrum: Sprint Retrospective

8 – Eventi Scrum: Sprint Retrospective

La Sprint Retrospective è un’opportunità per lo Scrum Team d’ispezionare l’andamento dello Sprint e creare un piano di miglioramento per il prossimo Sprint.

Questo event ha una timebox di 3 ore per uno Sprint di un mese, proporzionalmente meno per uno Sprint più breve.

Immagina di far parte di una squadra di rugby, non avendo mai giocato a questo gioco. L’efficienza del team nelle prime partite non sarà ottimale. Dopo ogni partita, il team discuterà le azioni di miglioramento da attuare per il prossimo gioco, come ad esempio:

Sprint Retrospective Scrum: facilitazione e miglioramento continuo del team agile
Clicca l’immagine per ascoltare l’episodio del Podcast
  • Il livello di comprensione dei valori e delle regole del gioco da parte dei giocatori;
  • L’efficacia del processo messo in atto per soddisfare lo scopo del gioco;
  • Verificare se gli strumenti utilizzati quotidianamente sono efficaci per raggiungere l’obiettivo: semplificano le nostre vite o la complicano?
  • Relazioni tra giocatori e stakeholder del team

Lo Scrum Master farà in modo che l’intero Scrum Team partecipi all’evento e che l’obiettivo sia chiaro a tutti.

Può facilitare la sessione, su richiesta del team, o parteciparvi contribuendo all’emergere di nuove idee di miglioramento.

Le Basi di Scrum - Eventi Scrum: Sprint Retrospective
Le Basi di Scrum – Eventi Scrum: Sprint Retrospective

TRE ORE SONO TROPPO PER UNA RIUNIONE!

Scrum aiuta a creare un processo empirico per fornire un prodotto o un servizio complesso. Il tempo dedicato alla ricerca del miglioramento non è tempo sprecato, è tempo investito per il futuro.

Spesso la frase citata nel titolo viene pronunciata in ambienti di lavoro dove:

  • Si è affetti da “riunionite”: è una malattia che è nota in molte aziende e che consiste nell’organizzare incontri che non hanno uno scopo specifico, in cui ci si annoia. In questi contesti, comprensibilmente, le persone fanno molta attenzione prima di accettare una riunione;
  • Tutti sono sempre sopraffatti: manca l’attenzione per potersi dedicare pienamente ad un argomento;
  • L’Individualismo: un processo empirico richiede trasparenza. Non partecipare agli eventi Scrum è come guardare attraverso un vetro opaco. Come possiamo migliorare insieme se non prendiamo il tempo di stare insieme?

Inoltre le tre ore di Sprint Retrospective sono un timebox, ciò vuol dire que se l’obiettivo dell’evento è raggiunto rapidamente, si potrà tornare al lavoro ben prima delle tre ore di lavoro previste in generale per uno Sprint di un mese.

IL PRODUCT OWNER DEVE PARTECIPARE ALLa SPRINT Retrospective?

Naturalmente! È membro del Team Scrum e in quanto tale la sua partecipazione è fondamentale. Se non partecipa, come potranno migliorarsi le interazioni fra Product Owner, Scrum Master e Developers?

Uno dei punti di forza di Scrum è abbattere i compartimenti stagni… quindi se il Product Owner è una persona del business (come sales, marketing, dirigente, ecc.), deve capire che far parte di uno Scrum Team richiede coinvolgimento e collaborazione!

SIAMO IN RITARDO, RISPARMIEREMO TEMPO CANCELLANDO La SPRINT Retrospective!

Quante volte ho sentito questa frase… Anche tu?

Immagina una squadra di Rugby che decide di non andare negli spogliatoi alla fine del primo tempo perché è meglio rimanere sul campo a fare autografi, è possibile?

La cancellazione della Sprint Retrospective è spesso motivata da:

  • Pressione esterna allo Scrum Team, spinto a “fare sempre più cose”, sempre più velocemente… senza prestare attenzione al valore creato, o alla qualità.
  • Un Product Owner che spinge il team di sviluppo a fare sempre di più, anche se significa utilizzare le ore della Sprint Retrospective per sviluppare più funzionalità.
  • Un Scrum Master che non è in grado di mediare e proteggere il team dalle incitazioni degli altri dipartimenti (o peggio non previsto nel budget) e che non può rivelare i malfunzionamenti nell’applicazione Scrum. (nota che uno Scrum Team senza Scrum Master non gioca a Scrum, è come giocare a Rugby in 14). Guarda questo video per approfondire l’argomento.

Scrum non è rigido, è una struttura molto semplice, con regole del gioco chiare e descritte nello Scrum Guide.  Se si desidera creare un prodotto o un servizio complesso empiricamente con Scrum, bisogna giocare secondo le regole di 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 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.

Tradotto dal francese da Denise Monreale, grazie!

Le Basi di Scrum - Eventi Scrum: Sprint Review

7 – Eventi Scrum: Sprint Review

La Sprint Review è l’evento in cui lo Scrum Team e gli stakeholder (usualmente invitati dal Product Owner) si incontrano per ispezionare l’Incremento e adattare il  Product Backlog.  Questa frequenza di ispezione e adattamento del lavoro svolto è molto importante per capire se la direzione intrapresa è corretta e insieme decidere cosa fare in seguito.

Si tratta di un evento informale, che non ha bisogno di preparazione, perché verrà ispezionato un Incremento Done e quindi, per definizione, corretto e senza anomalie, pronto per essere messo in produzione se il Product Owner lo decide.

Evento Sprint Review in Scrum
Clicca l’immagine per ascoltare l’episodio del Podcast

Un possibile risultato di questo evento potrebbe essere (vedi la Guida Scrum): 

  • Presentazione dello Sprint Goal (definito in Sprint Planning) dal Product Owner
  • Descrizione degli elementi del Product Backlog implementati dalla definizione di Done e non Done, relativo allo Sprint Goal, dal Product Owner
  • I Developers condividono i contenuti dell’Incremento con le scelte tecniche effettuate per le soluzioni implementate
  • Rendere l’Incremento disponibile agli Stakeholders per ottenere feedback
  • Adattare il Product Backlog con nuove idee, un ordine diverso, l’eliminazione di alcuni elementi, ecc.
  • Revisione del Product Backlog e condivisione delle date estimate di consegna in funzione dei progressi compiuti fino ad oggi (dati empirici).
Le Basi di Scrum - Eventi Scrum: Sprint Review
Le Basi di Scrum – Eventi Scrum: Sprint Review

LA SPRINT REVIEW NON È

  • Una demo: ad esempio solo un video, con le nuove funzionalità, mostrato agli Stakeholders.
  • La lettura di un Power Point: teorico, possibilmente con screenshot, che spiega cosa è stato fatto.
  • Una presentazione del lavoro svolto dai Developers al Product Owner, allo Scrum Master o ad un manager.

nella SPRINT REVIEW Non abbiamo nulla da mostrare

C’è sempre qualcosa da ispezionare in Sprint Review, se la Scrum Team si trova in una situazione in cui non c’è nulla da mostrare agli Stakeholders, si deve avere il coraggio di mantenere l’evento e spiegare in modo trasparente gli ostacoli (impediments) che hanno impedito la creazione dell’Incremento Done alla fine dello Sprint.

Le disfunzioni riscontrate sul terreno, che portano a questo tipo di situazione, possono essere:

  • Elementi del Product Backlog troppo grandi da sviluppare durante lo Sprint;
  • Lo Scrum Team non ha tutte le abilità per creare un Incremento Done;
  • Lo Scrum Team, che lavora su diversi progetti/prodotti in multitasking, senza potersi concentrare sulla creazione dell’Incremento
  • Un prodotto esistente che viene tagliato in strati tecnici
  • L’assenza di uno Sprint Goal

Qualunque cosa accada, lo Scrum Team si auto-organizzarsi per poter, in Sprint Review, portare del valore agli stakeholders. L’interesse deriva dall’essere riusciti a creare una variazione del valore del prodotto rispetto all’ultima volta. Questo può essere difficile all’inizio, in alcune situazioni. L’annullamento della Sprint Review non aiuterà a migliorare, al contrario, avrà un effetto negativo sulla trasparenza del lavoro e impedirà allo Scrum Team di ricevere feedback preziosi.

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.

Tradotto dal francese da Denise Monreale, grazie!

Le Basi di Scrum - Eventi Scrum: Daily Scrum

6 – Eventi Scrum: Daily Scrum

Il Daily Scrum è un evento quotidiano che mira a ispezionare i progressi verso lo Sprint Goal e ad adattare lo Sprint Backlog, se necessario. Ha una time-box di 15 minuti.

Il Daily Scrum si svolge sempre nello stesso luogo alla stessa ora, per ridurre la complessità. Sono i Developers che decidono le modalità d’organizzazione.

Il Daily Scrum consente agli sviluppatori di capire se lo Sprint Goal verrà raggiunto o meno entro la fine dello Sprint. Se il Product Owner o lo Scrum Master stanno lavorando attivamente su elementi dello Sprint Backlog, partecipano come Developers.

I Developers, per capire se lo Sprint Goal è raggiungibile, utilizzeranno un modo per rendere trasparente il lavoro svolto e quello ancora da fare. Molto spesso sentiremo parlare di “Burndown Chart” (vedi il glossario di Scrum), in formato cartaceo o elettronico. L’importante è la trasparenza delle informazioni.

Daily Scrum in Scrum Framework
Clicca l’immagine per ascoltare l’episodio del Podcast

IL DAILY SCRUM NON È…

… un incontro per risolvere i problemi, il suo scopo è quello di rivelarli per affrontarli al momento giusto e a seconda della loro gravità.

… una riunione di follow-up e lo stato di avanzamento del lavoro dei Developers da parte dello Scrum Master, del Product Owner o di un manager.

… un evento settimanale, il suo nome “Daily” significa ogni giorno… troviamo dunque la risposta alla domanda: “Abbiamo deciso di fare il Daily ogni due giorni, perché vederci ogni giorno non aveva senso”. In questo caso, bisogna pensare alla mancanza di trasparenza nello Scrum Team e all’occasione mancata per sapere se si è ancora in grado di raggiungere lo Sprint Goal.

Non bisogna dimenticare che la base di un approccio empirico è la trasparenza… in quale altro modo potreste ispezionare correttamente il lavoro e adattarlo?

Le Basi di Scrum - Eventi Scrum: Daily Scrum
Le Basi di Scrum – Eventi Scrum: Daily 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 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.

Tradotto dal francese da Denise Monreale, grazie!

Le Basi di Scrum - Eventi Scrum: Sprint Planning

5 – Eventi Scrum: Sprint Planning

Eventi Scrum: Sprint Planning. Lo Sprint Planning è il primo evento dello Sprint. Il suo obiettivo è quello di collaborare alla pianificazione del lavoro da fare durante lo Sprint. Ha un timebox di 8 ore per uno Sprint di un mese, proporzionalmente meno per uno Sprint più breve. L’intero Scrum Team partecipa per tutta la durata.

Sprint Planning Scrum
Clicca l’immagine per ascoltare l’episodio del Podcast

I tre argomenti seguenti vengono discussi durante lo Sprint Planning.

1 – PERCHÉ QUESTO SPRINT È IMPORTANTE?

Il Product Owner propone come il prodotto potrebbe aumentare il valore e l’utilità durante l’attuale Sprint.

La parte superiore del Product Backlog sarà costituita da elementi abbastanza piccoli, conosciuti e compresi dall’intero Scrum Team e coerenti con la visione del Product Owner.

Lo Scrum Team lavora insieme per definire uno Sprint Goal realistico e realizzabile per la fine dello Sprint.

2 – COSA POSSIAMO FARE in questo SPRINT?

I Developers selezionano gli elementi del Product Backlog realizzabili in uno Sprint, collaborando con Product Owner. 

Alcuni fattori hanno un impatto sulle stime dei Developers, come: 

  • Definizione di Done 
  • Prestazioni passate
  • Azioni di miglioramento da implementare
  • La capacità dello Scrum Team (ferie, assenze varie, assegnazioni parziali).

3 – COME VERRÀ SVOLTO IL LAVORO SCELTO?

Per ogni elemento del Product Backlog (non necessariamente tutti), gli sviluppatori pianificano il lavoro necessario per creare un incremento che soddisfi la definizione di Done, con più o meno dettagli a seconda dell’esperienza.

Lo Sprint Goal, gli elementi del Product Backlog per lo Sprint, così come il piano per consegnarli costituiscono lo Sprint Backlog. Accetteremo che lo Sprint Backlog cambi in base alle informazioni che emergono durante lo Sprint.

OSSERVAZIONI IMPORTANTI

  • In un contesto complesso, come lo sviluppo software, le interazioni non sono mai lineari. Aspettatevi che tutti e tre gli argomenti siano ridiscussi più volte durante lo Sprint Planning.
  • L’unico commitment preso dallo Scrum Team è il raggiungimento dello Sprint Goal. Non è la quantità di lavoro, o gli elementi del Product Backlog sviluppato alla fine dello Sprint che conta, è il fatto che lo Scrum Team sia riuscito a raggiungere lo Sprint Goal e a creare un incremento Done potenzialmente rilasciabile in produzione. Anche il più piccolo.
  • Da “Push” a “Pull”: solo i Developers possono fare previsioni su quanti elementi del Product Backlog verranno realizzati durante lo Sprint. Si dice che i Developers “tirano” il lavoro da fare in base ai suggerimenti del Product Owner. Nessuno può imporre loro o “spingere” una quantità di lavoro da fare. Rinunciare ad accettare questo modo di lavorare significa depotenziare i Developers e spesso porta ad effetti collaterali come: mancanza di commitment, mancanza di qualità, debito tecnico, turnover, ecc.
  • I Developers selezioneranno gli elementi del Product Backlog nell’ordine definito dal Product Owner.  Non si sceglie l’elemento più facile da raggiungere, per comodità.
  • Il Product Owner partecipa e collabora alle discussioni sull’argomento “3 – Come verrà svolto il lavoro scelto?”.  Sì! Rimane per il motivo indicato nel primo punto di questa lista. Ci si deve sempre aspettare interazioni non lineari all’interno dello Scrum Team durante lo Sprint Planning.
  • Lo Sprint Backlog non necessità dettagli in tutti i suoi contenuti. L’importante sarà avere abbastanza dettagli per poter avviare lo Sprint. Si accetterà l’emergere del lavoro durante lo Sprint (e le modifiche conseguenti allo Sprint Backlog).

Al termine dello Sprint Planning, lo Sprint Goal, le previsioni degli elementi del Product Backlog  da sviluppare (realizzati dai Developers) e il piano per raggiungerli saranno tutti elementi visibili nello Sprint Backlog.

Le Basi di Scrum - Eventi Scrum: Sprint Planning
Le Basi di Scrum – Eventi Scrum: Sprint Planning

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.

Tradotto dal francese da Denise Monreale, grazie!

Le Basi di Scrum - Eventi Scrum: Sprint

4 – Eventi Scrum: Sprint

COS’È UNO SPRINT?

Scrum prescrive cinque eventi, lo Sprint è il cuore e il contenitore di tutti gli altri. Ha una durata di massimo un mese, durante il quale viene creato e potenzialmente rilasciato un incremento di prodotto finito (“Done”) in produzione, (cfr. Guida scrum).

Lo Sprint consente una frequenza regolare di ispezione e adattamento del prodotto e della maniera di lavorare insieme nello Scrum Team e al di fuori. Il miglioramento continuo è alla base di Scrum.

Uno Sprint può essere considerato un mini-progetto con: 

  • Un obiettivo chiaro e immutabile (lo Sprint Goal)
  • Una durata fissa (massimo un mese)
  •  Una qualità impeccabile (resa trasparente nella definizione di Done)

…  e il contenuto?

Eventi Scrum e Sprint
Clicca l’immagine per ascoltare l’episodio del Podcast

Delle previsioni in merito al contenuto dello Sprint vengono fatte durante lo Sprint Planning dai Developers, perché per un prodotto complesso si accetterà l’adattamento del contenuto in relazione all’emergere di nuove informazioni (positive o negative).

Al termine dello Sprint, lo Scrum Team raggiunge lo Sprint Goal, materializzato da un Incremento di prodotto che aderisce alla definizione di Done.

L’unica eccezione sarebbe l’obsolescenza dello Sprint Goal nel corso dello Sprint, ad esempio un cambiamento delle condizioni di mercato. In questo caso, solo il Product Owner può decidere di annullare lo Sprint, che termina prematuramente con gli eventi rimanenti.

Tutto il lavoro degli sviluppatori viene eseguito all’interno dello Sprint e ha come origine il Product Backlog. Ciò implica che le tradizionali attività di ingegneria del software (analisi, progettazione, sviluppo, test, integrazione, ecc.) si svolgono in uno Sprint, in modo non lineare e attraverso la collaborazione di tutti. 

Formalizzeremo meno e collaboreremo di più.

Fabio Panzavolta

Pertanto, uno Sprint non ha aggettivi: lo Sprint 0, lo Sprint di Stabilizzazione, il Test Sprint, lo Sprint di concezione, ecc. non esistono in Scrum.

Le Basi di Scrum - Eventi Scrum: Sprint
Le Basi di Scrum – Eventi Scrum: Sprint

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.

Tradotto dal francese da Denise Monreale, grazie!

Le Basi di Scrum - Il Team Scrum

3 – Lo Scrum Team

Lo Scrum Team è autogestito e multidisciplinare.

Podcast Scrum Team Collective Genius con Fabio Panzavolta
Clicca sull’immagine per ascoltare l’episodio del Podcast

Scrum definisce tre responsabilità specifiche all’interno dello Scrum Team:

  • Product Owner (proprietario del prodotto): massimizza il valore del prodotto e gestisce il backlog del prodotto.
  • Developers: creano l’incremento “Done” potenzialmente finito ad ogni sprint e gestiscono e implementano lo sprint backlog.
  • Scrum Master: rimuove gli ostacoli che impediscono al team scrum di creare un incremento finito e gestisce il l’ambiente scrum.

L’avrete notato, in Scrum le persone non sono gestite, d’altra parte si fissano gli obiettivi e gestiscono gli artefatti.

La Guida Scrum descrive queste responsabilità in modo più accurato. È importante mantenere questa semplicità e immaginare come le responsabilità aziendali esistenti possano convergere con quelle di Scrum. L’unica domanda da porre dovrebbe essere:

Quali competenze sono necessarie per creare valore per i futuri utenti?

L’auto-gestione di Scrum è fondamentale per essere in grado di fornire prodotti complessi più velocemente. È possibile solo se tutti i membri dello Scrum Team capiscono le proprie responsabilità. In questo caso, come nel caso di un campo magnetico, ci sarà un equilibrio di forze che consentirà un’efficienza senza pari nella creazione di valore.

In questo video ci occupiamo di questo argomento.

Le Basi di Scrum - Il Team Scrum
Le Basi di Scrum – Lo Scrum Team

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.

Tradotto dal francese da Denise Monreale, grazie!

transformation petites victoires

Piccole vittorie: e se la trasformazione del mondo cominciasse da… voi?

Di Philippe Silberzahn, pubblicato il 22 marzo 2021 su HBR France.

transformation petites victoires
© GETTY IMAGES

Se i grossi problemi rimangono, è perché le grandi soluzioni non funzionano e non sappiamo come mettere in atto le piccole soluzioni.

La nostra epoca non ha mai avuto tanto bisogno di cambiamento, e non siamo mai apparsi così impotenti di fronte alla nostra incapacità di cambiare. Spesso, tuttavia, non è per mancanza di tentativi.

La guerra contro la droga negli Stati Uniti è iniziata in fanfara dal presidente Richard Nixon nel 1970. Nonostante dei mezzi colossali, circa 10 miliardi di dollari all’anno di spese dirette (ma molto di più se si contano le spese indirette), l’ONU ha finito per riconoscere ufficialmente, nel 2016, che questa guerra è stata un fallimento dalle conseguenze sociali disastrose. Dagli studi televisivi ai consigli d’amministrazione, dall’ENA (ndt Ecole Nationale d’Administration) alle scuole di commercio, dal governo alle ONG, è comunemente accettato che solamente un approccio deliberato, vuol dire un’azione pianificata su larga scala, permette di risolvere un grande problema, attraverso un “grande piano”, o altri eventi di dimensioni significative. Ora più la situazione è complessa, meno l’approccio funziona. Bloccati dalla volontà di fare le cose in grande, i dirigenti sono impotenti e sembra possa rimanere, per quelli che vogliono cambiare, solo la violenza, rifugio nel “mondo di domani” idealista e astratto, oppure la rassegnazione.

Da molto tempo però, una ricca corrente in sociologia, in scienze politiche e in teoria delle organizzazioni difende l’idea di un approccio incrementale del cambiamento, a piccoli passi e a scala locale. Questa corrente a mostrato come i problemi più complessi si risolvano al meglio organizzando una serie di piccole vittorie, le sole accessibili ai singoli. La loro successione costituisce una base solida che si rinforza progressivamente, limitando i rischi, dissuadendo gli oppositori e unendo gli indecisi in favore del cambiamento. Questa corrente si è rinnovata a partire dagli anni 2000 con l’entusiasmo delle grandi organizzazioni per l’imprenditorialità, nella quale hanno visto una maniera di reinventarsi.

Quattro caratteristiche concrete

Concretamente, una piccola vittoria ha quattro caratteristiche: costituisce un risultato “tangibile”, “completo”, “implementato in maniera collettiva” e d’”importanza moderata”. “Tangibile” e “completo” significa che deve esserci un cambiamento effettivo nella vita dell’organizzazione, come un nuovo modo di lavorare; “implementato in maniera collettiva” significa che la trasformazione può essere effettiva solo se si basa sull’impegno degli stakeholders, perché si tratta di risolvere dei problemi sociali, non individuali. Infine, “importanza moderata” è il significato stesso della piccola vittoria: si tratta di ridurre l’ambizione dell’azione al punto in cui rappresenta un rischio accettabile.

Nonostante un interesse regolarmente rinnovato per l’approccio incrementale e numerosi successi concreti, l’approccio deliberato rimane comunque molto dominante nelle nostre modalità d’azione. Quando viene tentato, l’approccio incrementale spesso si esaurisce dopo un certo periodo di tempo e non riesce a risolvere il problema per cui è stato utilizzato, ma senza sapere bene il perché. I grandi problemi rimangono perché le grandi soluzioni non funzionano e non sappiamo implementare le piccole soluzioni, da qui i bloccaggi che osserviamo oggi a tutti i livelli – nelle aziende come nella società.

Trasformare i modelli mentali

La nostra esperienza con team di dirigenti in progetti di trasformazione e d’accompagnamento d’innovatori e imprenditori da molti anni suggerisce che l’approccio incrementale fallisce per due ragioni: la prima, perché non identifica l’origine del bloccaggio che pretende risolvere. Si condanna quindi a rimanere in periferia, a non toccare il cuore collettivo: lo sforzo è superficiale. La seconda, perché, essendo puramente individuale, non permette alle diverse iniziative di aggregarsi in un tutto coerente al servizio di una trasformazione voluta: lo sforzo è disperso. Bisogna quindi identificare l’origine del bloccaggio e definire un principio guida.

L’origine del bloccaggio di un’organizzazione, sono i suoi modelli mentali, le convinzioni costruite col tempo su sé stessi e sul proprio ambiente. Sono i modelli mentali che determinano le decisioni prese dalla collettività. Per trasformare questa collettività, bisogna trasformare i propri modelli mentali. Il principio guida è il modello mentale target a cui miriamo. E quello che permette di scegliere le piccole vittorie e di aggregarle in modo coerente in modo tale che il cambiamento, piccolo all’inizio, finisca per avere un grande impatto.

Così, questa grande azienda industriale vedeva, anno dopo anno, i suoi costi di struttura aumentare, fino a metterne a rischio la competitività. La diagnosi era quella di una burocrazia in crescita di cui tutti i collaboratori si lamentavano, ma tutte le iniziative di semplificazione fallivano, senza che se ne capisse il perché. Un lavoro sui modelli mentali a permesso di mettere in evidenza una convinzione profonda che era: “un manager deve avere la risposta a tutto”. Era un po’ sorprendente in questa società dove ma maggioranza dei manager sono degli ingegneri. La moltiplicazione delle procedure veniva dalla paura collettiva di un incidente industriale e da quella, individuale, di esserne designato come responsabile. Questo portava i manager a formalizzare tutto e a deresponsabilizzarsi sui loro colleghi, per evitare di prendere dei rischi e questo per un numero sempre maggiore di decisioni. È quindi su questa esigenza di perfezione e non sulla burocrazia stessa, che si è dovuto lavorare e sulla convinzione che una procedura riduce il rischio, che non è per forza di cose vero. Alcuni manager volontario hanno, ciascuno individualmente, identificato un piccolo progetto in cui potevano prendere in considerazione la riduzione delle procedure. Qui, il filo conduttore delle piccole vittorie era la nozione di rischio e quella di fiducia con, sullo sfondo, la ridefinizione di cosa sia un manager.

Creare un impatto collettivo

Identificare il modello mentale bloccante, concordare con uno stakeholder su un modello alternativo che fungerà da principio guida, considerare un’azione a basso rischio con loro su questa base, poi capitalizzare con un nuovo stakeholder se funziona, oppure provare qualcos’altro se fallisce, ecco la chiave di un approccio per piccole vittorie. Questo aspetto sociale, cioè agire con qualcun altro sulla base di convinzioni alternative, è ciò che permette l’aggregazione di piccole vittorie, in altre parole, la creazione di un impatto collettivo maggiore della somma delle singole azioni. E così che una piccola vittoria diventerà grande. Con le piccole vittorie, non c’è bisogno di aspettare un piano o una visione: la trasformazione del mondo può semplicemente iniziare da voi.

Philippe Silberzahn

Professore associato all’EM di Lione, ex imprenditore, oggi lavora con grandi aziende sui temi d’innovazione e trasformazione. È l’autore di sei libri su questi temi, tra cui “Effectuation” che ha ricevuto il premio per il miglior libro di management, assegnato da Consult’in France. È anche co-autore, con Milo Jones, di un libro sulle sorprese strategiche intitolato “Constructing Cassandra: Reframing Intelligence Failure at the CIA, 1947-2001”, pubblicato dalla Stanford University Press nel 2013. Potete seguirlo su Twitter: @phsilberzahn.

Risorse correlate

Le Basi di Scrum - Le Fondamenta di Scrum

2 – Le fondamenta di Scrum

Per comprendere appieno le fondamenta di Scrum, si parte dalla premessa che creiamo e manteniamo sistemi complessi: un sistema informatico, una campagna di marketing, una strategia di vendita, ecc.

Le fondamenta di Scrum sono “I Valori di Scrum” e “l’Empirismo”.

Valori Scrum

Il Framework Scrum si basa su cinque valori fondamentali per stimolare i comportamenti adatti alle sfide di creazione di prodotti complessi. Questo documento è la traduzione di un’idea originale di Gunther Verheyen, troverete la versione originale e internazionale su questo sito web.

I valori Scrum sono fondamentali per ottenere uno stato d’animo adatto alle sfide di creazione di prodotti complessi, perché ti permettono di sentirti fiducioso per sperimentare e imparare.

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

I Valori Scrum sono cinque:

  • Focus (Attenzione): sul lavoro da fare durante lo Sprint e al compimento dello Sprint Goal
  • Openose (apertura): alla collaborazione con altri team, con altre persone e alle critiche costruttive che permettono il miglioramento continuo
  • Respect (rispetto): delle persone, delle loro competenze ed esperienze; dell’ambiente Scrum e delle responsabilità di ogni ruolo
  • Courage (coraggio): dire di no! Non lo so! Chiamare aiuto! Rifiutare di creare funzionalità inutili per l’utente finale; coraggio di rifare ciò che era stato fatto; coraggio di cambiare corsia, o opinione; di sfidare lo status quo
  • Committment (impegno): dare il meglio di sé in ogni attività; aiutare gli altri membri del team a raggiungere lo Sprint Goal

Ecco un’idea di workshop sui valori di Scrum con cui poter sperimentare.

Empirismo

Empirismo e Scrum
Clicca l’immagine per ascoltare l’episodio del Podcast

Un sistema complesso non può essere pianificato, emergerà nel tempo, grazie ai vari esperimenti e al feedback degli utenti finali. L’empirismo è un tipo di processo di controllo in cui le decisioni si basano sui risultati osservati, sull’esperienza e sulla sperimentazione. L’empirismo attua ispezioni e adattamenti regolari che richiedono e creano trasparenza.  Noto anche come “processo di controllo empirico” (vedi Lessico Scrum).

Pertanto, una delle prime aree di intervento aziendale è comprendere il livello di fiducia e trasparenza tra gli stakeholder coinvolti nella creazione del prodotto e agire di conseguenza.

Le imprese in cui la cultura si basa naturalmente sulla fiducia e sulla trasparenza saranno probabilmente più rapidamente efficaci nei loro cicli di ispezione e adattamento.

Fabio Panzavolta

Asse di riflessione: che legame fai tra i valori di Scrum e l’empirismo?

Per andare oltre nella comprensione di Scrum, dei suoi valori e dell’empirismo, ti consigliamo di leggere Scrum a Pocket Guide – 2a edizione di Gunther Verheyen. (Se l’inglese non è un problema per te, esiste una terza edizione in inglese, che consigliamo).

Le Basi di Scrum - Le Fondamenta di Scrum
Le Basi di Scrum – Le Fondamenta di 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.

Tradotto dal francese da Denise Monreale, grazie!

Le Basi di Scrum - Cos'è Scrum?

Cos’è Scrum?

UN PO’ DI STORIA

Cos’è Scrum? In quest’articolo trovate un pò di storia relativa a Scrum e alcune delle ragioni per le quali è importante capire che cos’è Scrum… che lavoriate o meno in uno Scrum Team!

Definizione di Scrum: Guida Completa
Clicca l’immagine per ascoltare l’episodio del Podcast

Scrum è un framework leggero con il quale le persone possono risolvere problemi adattivi complessi, fornendo in modo produttivo e creativo prodotti del massimo valore possibile.

La parola Scrum, la mischia in Rugby, è stata scelta da Ken Schwaber e Jeff Sutherland negli anni Novanta. È un omaggio a Hirotaka Takeuchi e Ikujiro Nonaka, gli autori dell’articolo « The New New Product Development Game » che ha fortemente ispirato le sperimentazioni iniziali.

Un framework costituito da un insieme di principi e di regole da seguire per raggiungere un obiettivo comune. Le persone, organizzate in team autonomo (auto-gestito) e multidisciplinare, avranno maggiori possibilità di raggiungere l’obiettivo di ogni Sprint e di migliorare continuamente.

The New New Product Development Game
The New New Product Development Game

Lo Scrum Guide, versione 2020, è il punto di partenza e di riferimento per qualsiasi persona che ha voglia di approfondire l’argomento.

Tutti i giocatori in campo, allenatori e arbitri, conoscono le regole del rugby. In azienda, è importante che tutte le parti interessate di uno Scrum Team comprendano le regole del gioco. In altre parole, la comprensione di Scrum non può essere superficiale, delegata o ignorata! Lo Scrum Team, col tempo, diventerà l’equivalente di una squadra di rugby ad alte prestazioni. Di conseguenza sarà in grado di risolvere problemi complessi in modo empirico.

Le Basi di Scrum - Cos'è Scrum?
Le Basi di Scrum – Cos’è Scrum?

Scarica e stampa (in A4 o A3) il poster relativo a questo articolo, potrà esservi utile in ufficio, i codici QR permettono di approfondire la conoscenza del framework Scrum!

Tradotto dal francese da Denise Monreale, grazie!

Principio di unicità

Scrum e il principio di unicità

Scrum e il principio di unicità risponde ad una domanda che capita spesso in formazione:

come usare Scrum per un team di più di 11 persone?

In questo articolo destinato a un pubblico informato, condivido la mia comprensione di Scrum e come propongo di sperimentarlo nel caso particolare di uno Scrum Team che ha un numero significativo di Developers.

La Scrum Guide è stata scritta per uno Scrum Team, composto da un Product Owner, un gruppo di Developers e uno Scrum Master.

L’obiettivo dello Scrum Team è di creare un Incremento di prodotto Done entro e non oltre la fine dello Sprint.

Il punto focale di Scrum è un prodotto, per il quale abbiamo un Product Backlog e un Product Owner che gestisce il Product Backlog ed è responsabile per massimizzare il valore del prodotto.

In ogni momento esiste anche un Product Goal, che indica il passo successivo verso la visione.

Poi abbiamo un gruppo di Developers (ignoriamo il numero di persone, perché si auto-organizzano) che gestiscono lo Sprint Backlog e hanno la responsabilità di creare un Incremento di Prodotto Done e integrato entro e non oltre la fine dello Sprint.

Scrum e il principio di unicità
Principio di unicità

Gli sviluppatori devono conformarsi a una definizione di done

Lo Scrum Master è responsabile della comprensione e dell’applicazione corretta di Scrum.

Se si comprende il principio di unicità, le responsabilità di ciascuno e l’autogestione funziona (non ci sono interferenze dall’esterno dello Scrum Team) non c’è motivo per cui, con l’ispezione e l’adattamento, lo Scrum Team non trovi un modo efficace di lavorare, che sia composto da 5 o 50 persone!

Il miglior framework Scaled Scrum è quello definito dallo Scrum Team… se viene imposto dall’esterno sarà meno efficace – Fabio Panzavolta.

Tenendo conto di questo principio di unicità, implicitamente descritto nello Scrum Guide, è possibile rispondere agevolmente alle seguenti domande.

  • È possibile per un singolo Product Owner gestire un Product Backlog quando abbiamo 30 sviluppatori?
  • Abbiamo più team che lavorano su un singolo prodotto, come risolviamo i problemi di integrazione?
  • Abbiamo tre Product Owner per il nostro prodotto perché è molto grande. Abbiamo anche aggiunto uno Chief Product Owner, per coordinare gli altri tre. È corretto secondo Scrum?
  • Per ogni gruppo di Developers abbiamo aggiunto una persona che si occupa della relazione e del coordinamento con il Product Owner e gli altri gruppi di Developers, è Scrum?

Il principio di unicità ti aiuterà a prendere decisioni in accordo con Scrum, è molto probabile che non troverai una soluzione efficace la prima volta, l’importante è collaborare per migliorare continuamente senza infrangere regole, principi e valori di Scrum.

Conclusione

Hai problemi a rispondere alle domande qui sopra? Contattami, o registrati per una delle mie prossime formazioni, ti aiuteranno a tornare al lavoro con un modo di pensare e decidere in accordo con Scrum.

Alcune risorse aggiuntive

Partecipare ad una delle nostre formazioni