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!

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!

Scrum Promozione

Come si fa a ‘promuovere’ Scrum in una azienda a vocazione metalmeccanica?

Durante l’evento “Ask a Professional Scrum Trainer” edizione italiana del 26 maggio 2021, con Massimo SartiAniello di Florio, certe domande non hanno ottenuto risposta.

Abbiamo deciso di rispondere a tutti con una serie di articoli, che troverete qua.

La domanda di Giuseppe è : come si fa a “promuovere” Scrum in un’azienda a vocazione metalmeccanica?

Foto di Possessed Photography su Unsplash
Foto di Possessed Photography su Unsplash

La promozione di Scrum è spesso spinta da una persona che in passato l’ha già praticato oppure da qualcuno che ha ne ha intuito la potenzialità e ha voglia di sperimentarlo. Personalmente ho visto la promozione di Scrum, in qualsiasi tipo di azienda, avvenire sia dal basso che dall’alto, o da una combinazione dei due.

Io stesso, quando ho iniziato a capire le potenzialità di Scrum nel 2010, ho cominciato a sperimentarlo con i miei clienti che non lo conoscevano.

Questa esperienza ha mostrato che la miglior promozione che si possa fare è con l’esempio. Quindi identificare un prodotto con il quale si possa portare avanti una sperimentazione Scrum e mettersi al lavoro. Molto spesso non c’è bisogno di autorizzazioni interne o altre cose complicate per iniziare.

Ho cominciato così a praticare Scrum, senza pubblicizzarlo troppo, proponendo al team gli eventi e cominciando, insieme, a identificare tutte le barriere che ci impedivano di utilizzare Scrum per creare il nostro prodotto (software).

Rapidamente, questa sperimentazione ci ha portato a parlare e discutere di Scrum al di fuori del team, ha motivato altre persone a provare e ha scatenato molte domande.

La sfida più grande per qualsiasi persona e azienda consiste a cambiare modo di pensare, agire e prendere decisioni. Capire che in un mondo complesso e mutevole non c’è certezza è uno dei primi passi. Adeguarsi a questo dato di fatto è più difficile.

Questo è ancora più importante quando si parla di prodotti tangibili (e non software), dove la roadmap e la strategia del prodotto devono tener conto dello sviluppo iterativo e incrementale.

Per esempio, una società metalmeccanica che ho avuto il piacere di formare, deve creare un nuovo prodotto che integra componenti elettronici (iot). Cosa mai fatta prima.

Riunendo insieme tutte le competenze necessarie (tecnici, sales, sviluppatori, marketing, ecc.) sono riusciti a creare una roadmap che avesse un senso per tutti, in breve:

  1. La prima versione del prodotto avrà una cavità pronta ad ospitare i componenti elettronici. La commercializzazione sarà possibile e appetibile perché il minor peso del pezzo ci permetterà di venderlo meno caro. Questo finanzierà la seconda versione
  2. La seconda versione del prodotto conterrà l’elettronica necessaria e una parte del software per farlo funzionare. La commercializzazione sarà possibile e appetibile perché questa versione ci permetterà di tracciare il numero di movimenti del pezzo e programmare i richiami automatici per la manutenzione
  3. La terza versione del prodotto avrà aggiornamenti software, con ulteriori funzionalità utili al cliente per pilotare e ottenere informazioni sul movimento del martinetto…

Vedete come sia importante, in ogni caso e forse ancor più per un’azienda metalmeccanica, avere una visione, un obiettivo e una roadmap di prodotto chiara, tanta apertura e collaborazione per ottenere questo tipo di risultati.

Le formazioni Applying Professional ScrumProfessional Scrum Master e Professional Scrum Product Ownersono le più indicate per aiutarvi a capire Scrum e cominciare a pensare, agire e prendere decisioni come quelle che ho esposto sopra.

Trovate qua le date delle prossime formazioni in Italia.

Spero di aver fornito spunti di riflessione a Giuseppe (e tanti altri!), che aveva fatto la domanda “come si fa a promuovere Scrum in un’azienda a vocazione metalmeccanica”.

Scrum Caretakers Meetup

Scrum Caretakers Meetup. A case of Scrum and organizational design in practice

Lunedì 6 luglio 2020, Gunther Verheyen e Fabio Panzavolta hanno avuto il piacere di condividere la loro esperienza nel mettere in pratica una trasformazione organizzativa implicita. La semplicità di Scrum consente di scalare le montagne, lavorando sodo e rimuovendo gli ostacoli uno dopo l’altro…

Leggete il case study e il libro “97 Things Every Scrum Practitioner Should Know“.

Esempio Trello

Scrum e efficacia personale

Ascoltate l’articolo

Scrum e efficacia personale sono compatibili? In queste ultime settimane ho sperimentato l’utilizzo di Scrum per la mia organizzazione personale. Se avete molte cose da fare, a livello lavorativo o personale, se vi sentite superati dagli eventi allora è possibile che questo articolo vi sia utile. Sono alla settima settimana di sperimentazione.

Questo articolo potrebbe anche essere utile alle persone che non conoscono Scrum perché i principi che spiego e che mi sono applicato a me stesso non sono altro che i principi di Scrum.

Rendere il lavoro da fare visibile

Uno dei fattori di stress per quanto mi riguarda derivano dal fatto che provo a memorizzare tutto. È evidente che ad un certo punto è impossibile e per questo mi aiuto con l’agenda, le note ed i task come tutti insomma. Volevo trovare un modo più efficace per rendere il lavoro visibile ed ho cominciato a riportare su Trello (ovviamente ci sono anche altri strumenti da provare) tutte le mie note, i miei task e le mie idee da esplorare.

Ho organizzato lo spazio con diverse colonne:

  • Modelli: dove memorizzo tutti i modelli di elementi del Backlog per evitare di riscriverli ogni volta. È molto utile per esempio per organizzare una formazione perché ho una check list di 45 elementi.
  • Product Backlog: la lista di tutte le cose da fare
  • Sprint Backlog: la lista di tutte le cose da fare in uno Sprint, nel mio caso una settimana, a volte aggiungo anche dei dettagli nei commenti
  • On Going: è la lista dei lavori in corso. Limito volontariamente ad un elemento questa colonna
  • Done: tutte le cose che ho terminato. Terminato per me vuole dire non avere più niente da fare e quindi dovete ben pensare per voi che cosa vuol dire aver terminato un elemento del Backlog

Ho aggiunto altre tre colonne per tenere traccia dei libri che voglio leggere, che sto leggendo e che ho letto.

Esempio Trello 1
Esempio Trello

Uso codici colore che mi sono utili per capire in quale settore passo la maggior parte del mio tempo e anche per equilibrare bene lo Sprint. Per esempio, tutti gli item che sono in rosso corrispondono ai task amministrativi: se mi rendo conto che la metà di uno Sprint è costituito da item rossi vuol dire che c’è un problema perché questo mi impedisce di creare valore per voi e di fare quello che mi piace di più, cioè studiare e praticare Scrum… come avrete capito!

Ordinare il lavoro da fare

All’inizio avrete solo la colonna Product Backlog con tanti elementi, le altre colonne saranno probabilmente vuote. Ora è il momento di ordinare il lavoro da fare. Utilizzate i criteri che sono più adatti nel vostro caso, come: l’urgenza, l’importanza, il guadagno, eccetera. 

Personalmente ho ordinato con un obiettivo in mente: ogni settimana voglio creare del contenuto di valore, il più piccolo che sia, più altre cose tipo secondarie.

Durata e obiettivo di uno Sprint

L’avete senza dubbio indovinato ora bisogna decidere la durata dello sprint e soprattutto fissarsi degli obiettivi. Ma prima decidete la durata dello Sprint; io ho scelto una settimana e vi consiglio di non superare le quattro settimane.

Una volta fissata la durata cominciate a prendere gli item del Product Backlog dall’alto, immaginando tutto il lavoro che farete nel corso di uno Sprint (quindi nel mio caso di una settimana). Non passate molto tempo in questa attività, un quarto d’ora dovrebbe essere sufficiente anche perché all’inizio vi sbaglierete 😊.

Mi sono fatto un modello di item che mi serve a delimitare uno Sprint e nel quale prendo nota dello Sprint Goal, l’obiettivo che mi sono fissato per la settimana. Questo mi permetterà di portare nello Sprint Backlog gli elementi del Product Backlog che sono coerenti con lo Sprint Goal (e quindi a delimitare un insieme coerente di lavoro da fare).

Modello item
Il modello di item che utilizzo per creare un nuovo Sprint personale. Sostituisco X con il numero dello Sprint e aggiungo l’obiettivo
Esempio di Sprint
Un esempio del mio primo Sprint, con l’obiettivo corrispondente. Fra parentesi vedete il numero di item completati alla fine dello Sprint

Selezione del lavoro da fare nel corso di uno Sprint

Durante lo Sprint, ora che l’obiettivo è chiaro, scelgo nel Product Backlog le cose da fare (in generale lo faccio il venerdì sera, per iniziare il lunedì con la lista già pronta, ma che modifico a volte).

Bisogna tener conto delle proprie disponibilità, pensare anche a liberare tempo per il vostro benessere, che è molto importante! Per esempio, io aggiungo elementi “sport” nello Sprint perché spesso le idee di articoli ed altre idee importanti mi vengono mentre corro e sapete che il cervello è fatto bene e utilizza questo tempo per digerire le informazioni e per metterle in ordine. Fare sport o qualsiasi altra attività che vi fa bene non vuol dire che non state lavorando, il cervello continua a lavorare!

Siete pronti per il vostro primo sprint preparatevi perché sarà pieno di sorprese 😊.

Lo Sprint

Cominciate il vostro ciclo di lavoro prendendo cura di rispettare qualche regola che vi siete fissati. Le mie sono: non più di un elemento alla volta, aver finito vuol dire che non ho più niente da fare su questo elemento e nessuna concessione sulla qualità del risultato.

In questo momento sto sperimentando il time-boxing di certe attività che mi occupano molto tempo, come per esempio la lettura e la risposta alle mail. Quando comincio a trattare le mail avvio il conto alla rovescia di 30 minuti e quando scade il tempo interrompo il lavoro e considero questo elemento del Backlog come terminato. Ho tre elementi nello Sprint Backlog: controllare le mail al mattino, controllare le mail al pomeriggio e controllare le e-mail la sera. Il time-box totale è di un’ora e mezza, ciò vuol dire che a volte finisco in cinque minuti ed altre volte invece arrivo alla scadenza dei 30 minuti e smetto termino l’attività. 

Ogni mattina rileggete l’obiettivo che vi eravate dati per lo Sprint, chiedetevi se siete sempre concentrati a realizzare questo obiettivo! Lo avevate dimenticato? È sempre d’attualità? 

Piccolo consiglio: non cambiate l’obiettivo dello Sprint una volta che lo avete cominciato. Se qualcosa di importante si aggiunge segnatelo nel Product Backlog, se è veramente molto importante mettetelo in alto, lo tratterete nel prossimo Sprint. Non fatevi distrarre dalle novità che spesso possono aspettare la fine dello Sprint.

Fine dello Sprint

Ecco ci siamo, è la fine dello Sprint (quindi della settimana per me). Ora è molto importante prendere il tempo per analizzare il lavoro che è stato fatto e il lavoro che vi resta da fare nella colonna “On Going” e soprattutto se il vostro obiettivo è stato raggiunto o meno! 

Nel primo caso a potete aprire una bottiglia di buon vino e nel secondo caso una bottiglia di birra. E già, bisogna sapere ricompensarsi all’altezza dei propri risultati e immagino che questo tipo di ricompensa vi aiuterà e vi motiverà a raggiungere i vostri Sprint Goal. 

Ovviamente se non vi piace o non potete bere vino o birra, cercate un’altra ricompensa che vi aiuterà e vi motiverà a raggiungere l’obiettivo dello Sprint 😊.

Non abbiamo finito, ora bisogna sapere come migliorarsi nel prossimo Sprint. Prendete un’ora almeno per riflettere a tutte le cose che sono andate bene e a cosa volete migliorare per il prossimo Sprint.

Ad ogni Sprint obbligatevi a trovare un’azione di miglioramento che potete implementare concretamente al prossimo Sprint. Definite in quest’azione i risultati attesi nel corso dello Sprint e verificateli alla fine. Se non lo fate, le azioni di miglioramento non vi serviranno a niente.

Ora che gli elementi che rimangono nella colonna “On Going” e Sprint Backlog sono stati analizzati possono essere spostati nel Product Backlog. Fate la somma degli elementi che si trovano nella colonna “done” per lo Sprint che avete terminato. Questa informazione vi sarà utile più tardi.

È venerdì sera, il mio Sprint è terminato. Questo era l’ultimo item da fare, dopo aver pubblicato l’articolo e aver messo l’item in “done”, vedrò se posso aprire una bottiglia di vino o una di birra!

Fra due settimane pubblicherò un nuovo articolo: come migliorare la vostra prevedibilità personale con un Burndown chart.

Buon week-end!