Certified ScrumMaster Training: Done!

Sono sopravvissuto

Ieri è terminato il training inerente alla certificazione ScrumMaster.

E’ stato tanto complesso e faticoso quanto interessante e coinvolgente.

Innanzitutto l’intensità e la durata del corso: diciotto ore in totale nelle due giornate. Pause, diciamo così, ridotte al minimo per evitare dispersioni e cadute di concentrazione; in aula sempre disponibili caramelle, snack vari e ampia disponibilità di caffé e bevande, evitando di doversi allontanare per cercare “ristoro”.

La lingua: data la sede (Scozia) interamente in inglese. Ero l’unico non madre-lingua o che comunque non usava l’inglese giornalmente. Questo ha ovviamente giocato a mio svantaggio ed è stato di fatto un impedimento (termine caro a uno ScrumMaster).

Cervello in perenne stato di saturazione nel tentativo di gestire l’ingente mole di dati in input, i processi di traduzione, decodifica e di interpretazione e per finire con la memorizzazione di quanto appreso ed elaborato.
In certi momenti devo aver fatto un pò la figura del tonto, in quanto la mia reattività non era certo da guinness dei primati!

E’ stato però estremamente avvincente confrontarsi con persone così differenti in termini culturali, ma ancora di più ritrovare sé stesso in quel contesto, così diverso da quello usuale ed essere obbligati a cavarsela.

Lo svolgimento: SCRUM è una modalità agile, concreta e coinvolgente di condurre progetti.
Simon (il trainer) ha gestito il corso allo stesso modo. Le giornate pensate come fossero degli sprint, in cui gli argomenti da trattare erano riportati nella SCRUM Tasks Board e, all’inizio delle quali, abbiamo condotto gli SCRUM daily meeting (rigorosamente in piedi e entro i famosi quindici minuti) e a fine corso una specie di review meting per verificare quanto appreso.

E infine, cosa dal mio punta di vista a maggior valore aggiunto dell’intero corso, una serie di esercizi pratici in cui noi (il team) eravamo direttamente e “fisicamente” coinvolti nello svolgimento. Esempi dai quali ho tratto i più importanti spunti e insegnamenti.

La sfida: cosa c’è di più sfidante nel sostenere ritmi molto serrati, comunicando in una lingua diversa dalla tua, trovandoti coinvolto in team con persone che non conosci?
Infine, per dare ancora più senso alla sfida, uno stravolgente cambio di mentalità nel gestire i progetti! Questa di certo è la sfida nella sfida!

La creatività: SCRUM è un framework che indica regole piuttosto chiare a cui attenersi per gestire progetti in modo agile. Sebbene possa sembrare un contesto piuttosto rigido in cui muoversi, il team al fine di meglio collaborare, crescere e auto organizzarsi, deve essere molto aperto ai cambiamenti, agli adattamenti, essere molto curioso e coraggioso nello sperimentare: in una parola parola deve fare largo uso della creatività. Così anche noi durante il corso siamo stati chiamati a disegnare, trovare soluzioni innovative, avere a che fare con post-it di vario colore e forma per tracciare e gestire i task, valutare, trovare accordi.

 Una nota a margine.

Ero uno dei partecipanti più “anziani”: sono io che mi sono mosso in ritardo, oppure in generale, in Italia siamo parecchio indietro rispetto a questi argomenti?

L’aereo mi aspetta, ho diverse ore per pensarci! Be good

SCRUM (2^ parte)

Ecco la seconda parte della saga “SCRUM”.

Avevamo iniziato qui (http://www.emilianosoldipmp.info/2010/11/08/scrum-1-parte/) parlando in generale di SCRUM e di una delle sue componenti principali: gli artefatti.
Oggi parleremo di altre due componenti: time boxes e ruoli.

---

Questo post è disponibile ai soli utenti registrati. La registrazione è libera.

Per procedere alla registrazione cliccare sulla voce “Amministrazione/Registrati” nella side-bar di destra.

This post is available only to the registered users (free). Please register using the voice “Administration/Register” on the right side-bar.

SCRUM (1^ parte)

In un post precedente, raccontavo di come poter conciliare realtà aziendali lontane da un modello di business prevalentemente orientato ai progetti (matrice debole), con le tematiche agili, tanto in voga in questi periodi.
Questo è il primo post di una piccola serie, in cui fornisco indicazioni rispetto a SCRUM: uno dei più utilizzati framework agili.  

---

Vorrei cominciare enunciando i diversi “perché” potresti, o dovresti,  decidere di utilizzare SCRUM per gestire i progetti nella tua azienda.  

• Perché non esiste un’analisi dettagliata del lavoro da eseguire
• Perché è necessario fornire al più presto al committente, valore di business, anche parziale, attraverso il prodotto rilasciato
• Perché i change di progetto potrebbero essere frequenti in rapporto alla volatilità del mercato di riferimento in cui si opera
• Perché la tecnologia utilizzata è innovativa o poco sperimentata
• Perché i rischi sono molto alti
• Perché è necessario ricevere feedback dagli utenti con buona frequenza

Ti ritrovi in qulcuno dei punti sopraccitati?  

Bene!  SCRUM potrebbe aiutarti a trovare le risposte giuste…SEGUIMIIIIIII!!  

 

Come funziona?

SCRUM suddivide il lavoro in tempi precisi, dà loro il nome di sprint e identifica una durata media di 2/4 settimane ognuno.  

Quando terminato, lo sprint permette di rilasciare in produzione un “pezzo di prodotto” funzionante, sin da subito utilizzabile dal committente.  Identifica ruoli che hanno perimetri di responsabilità ben definiti, chiari a tutti e regolamentati.

 Non necessita di analisi e piani di progetto “ultra-dettagliatissimi“. Solitamente SCRUM dedica a tali attività solo il 20% del tempo impiegato dalla normale attività di project management. 

Solo lo sprint corrente si giova di analisi sufficientemente approfondite, cosa non obbligatoria per i successivi sprint.
Questi ultimi, infatti, verranno particolareggiati quando arriverà il loro turno.  

Prevede infine, regole ben definite che scandiscono rapporti, tempistiche, modalità e strumenti, permettendo agli appartenenti al team, di essere efficienti, efficaci, focalizzati.  

Quali i principi ispiratori?

I principi ispiratori sono ovviamente mutuati dal manifesto agile. 

1. Soddisfare le esigenze del cliente
2. Accettazione dei change di progetto come normali accadimenti
3. Rilasciare prodotti funzionanti, anche parziali, frequentemente
4. Far lavorare a strettissimo contatto i tecnici, gli ingegneri e le persone più vicine al business
5. Puntare all’eccellenza tecnica, di design e di qualità
6. Essere motivati e motivare il team
7. Preferire comunicazioni dirette (face-to-face)
8. Ritmi lavorativi sostenibili
9. Semplicità a 360°
10. Retrospezione dell’operato

Cos’è esattamente SCRUM

SCRUM è un framework che permette il governo agile dei progetti. Riguarda essenzialmente il processo, gli strumenti, le persone, le modalità; non detta leggi inerenti le tecnicalità o le modalità in cui svolgere il lavoro che produce il prodotto, bensì ne governa l’avanzamento.  

E’ un approccio facilmente adattabile a progetti software, ma portabile anche a progetti di tipo hardware, marketing, operation (solo per citare alcuni esempi).  

Sono diverse le dimensioni dello SCRUM:  

• Strumenti e artefatti (Artifacts)
• Tempistiche precise (Time boxes)
• Ruoli (Roles)
• Regole (Rules)

Artifacts

   

Product Backlog

E’ il registro delle funzionalità necessarie, ordinate per importanza.  

Il Product Owner è il responsabile unico di tale registro.  

Egli, con l’aiuto degli altri stakeholder, comincia con la compilazione delle user stories: casi d’uso dell’applicazione descritte per singola tipologia d’utente.  

Dalle user stories vengono derivate le diverse funzionalità che le compongono e queste vengono elencate.  

In base alle priorità dello sponsor/committente, ai rischi identificati, al grado di dettaglio disponibile, alle funzionalità vengono assegnate priorità.  

E’ proprio da quelle in cima a quella lista che si comincerà a lavorare.  

Release Backlog

E’ un sottoinsieme del product backlog: identifica le funzionalità da implementare, raggruppate per versioni di prodotto che verranno rilasciate in produzione.  

Sprint Backlog

Rappresenta l’insieme delle funzionalità in ordine di priorità, che dovranno essere implementate nello sprint corrente.  

Queste vengono analizzate, scomposte in task, stimate dal team e prese in carico dai singoli componenti.  

Burndown chart

   

E’ un grafico che rappresenta il totale del lavoro mancante (ore o punti) suddiviso per giorno.  

Via via che il team evaderà lavoro, il trend della linea sarà discendente. E’ una rappresentazione che restituisce immediatezza rispetto alla resa e alle performance del team.  

Impediments Backlog

Lista degli impedimenti o dei problemi identificati, che risultano essere ostacoli al libero svolgimento del lavoro.  

Tale registro è gestito dallo Scrum Master, il quale dovrebbe affrontare e risolvere, nella teoria, i problemi emersi entro 24h dalla loro nascita.  

Bene per questa sera può bastare….nel prossimo post ripartiamo da qui: time boxes, ruoli e regole. 

Have a nice evening