Sprint Retrospective: come funziona?

Sprint Retrospective

Sprint Retrospective: come funziona?
Partiamo con alcune citazioni.

Nel Manifesto per lo Sviluppo Agile di software il principio n. 12 richiama il concetto di retrospective: “a intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza”.

Nella Guida Scrum nel paragrafo dedicato alla Sprint Retrospective si stabilisce che: “Lo Scrum Team ispeziona come è andato il precedente Sprint relativamente agli individui, alle interazioni, ai processi, agli strumenti ed alla propria Definition of Done”.

La Guida al Project Management Body of Knowledge (PMBoK) edizione 7  al paragrafo §2.5.8 si parla in generale di apprendimento nel corso del progetto: “Periodicamente, il gruppo di progetto potrà incontrarsi per determinare sotto quali aspetti può migliorare (lesson learned) e come può migliorare e sfidare il processo nelle iterazioni successive (retrospettive)”.

Sprint Retrospective: come funziona?
Vediamo a partire dalle definizioni il suo funzionamento a grandi linee.

La retrospective è un incontro presente in tutti gli approcci: agili, ibridi e predittivi. Quando tenere la retrospective può essere o meno formalizzato nel framework o metodo utilizzato. Ad esempio: in Scrum è un evento denominato Sprint Retrospective e si tiene alla fine di ogni Sprint; nel metodo Kanban non è definito un momento specifico in cui tenere la retrospective ma spetta al team che si auto-gestisce stabilire la periodicità di questo incontro.

La definizione della Guida Scrum mette in evidenza degli ambiti specifici su cui confrontarsi durante la retrospective:

  • Individui
  • Interazioni
  • Processi
  • Strumenti
  • Definition of Done

In modo trasversale rispetto a questi ambiti, il team mette in evidenza cosa ha funzionato, cosa non ha funzionato e cosa migliorare rispetto ad un arco temporale trascorso (iterazione o sprint). L’output di una retrospective è una lista ordinata per priorità delle azioni di miglioramento che può attuare immediatamente. Il risultato atteso dall’implementazione delle azioni è l’effettivo miglioramento in termini di efficacia ed efficienza.

Sprint Retrospective: perché non funziona?
Può stupire ma questo evento è molto delicato, frequentemente perde di efficacia sino ad essere abbandonato o svolto solo perché è scritto nella guida Scrum.

Che la Retrospective sia un momento ritenuto da tutti importante è un dato di fatto, banalmente ho potuto averne dimostrazione con un breve e semplice esercizio che svolgo in aula. L’esercizio consiste nel dividere in gruppi i partecipanti (3-5 persone per gruppo), dar loro i 12 principi dell’Agile Manifesto e chiedere di scegliere i 3 principi che ritengono essere i più importanti. Questo esercizio lo svolgo da oltre cinque anni, purtroppo non mi sono mai divertito a tirare giù una statistica, ma potrei iniziare a farlo. Ad oggi ho rilevato qualitativamente che il principio numero 12 ha un’elevata frequenza di scelta, una buona fetta delle persone ritiene che sia molto importante avere un momento durante il quale riflettere e migliorarsi, come dargli torto.

Cosa accade nella realtà?
Questo evento tende ad essere abbandonato o a non generare valore per il team.

Quali sono gli anti-pattern della retrospective?
Ovvero, quali dinamiche riconoscibili emergono da un’esecuzione disfunzionale della retrospective?

Stefan Wolpers fa un elenco completo nella sua Guida agli Anti-Patterns di Scrum, di seguito riporto un estratto di alcuni anti-patterns:

  • #NoRetro: lo Scrum Team chiede di eliminare o non tiene più la retrospective.
  • Dispensable buffer: la retrospective viene cancellata per completare il lavoro necessario a raggiungere lo Sprint Goal.
  • Rushed retrsospective: lo Scrum Team alloca meno di 60 minuti per l’evento.
  • Someone sings: quanto viene condiviso nella retrospective viene raccontato a stakeholder esterni, violando la regola: “quanto si dice nel team resta nel team”.
  • Extensive whining: l’evento diventa un momento per lamentarsi e per fare le vittime.
  • UNSMART: lo Scrum Team sceglie azioni di miglioramento non misurabili e poco chiare, ad esempio: migliorare la comunicazione, ridurre il numero di bug, ecc. Un’azione SMART è Specifica, Misurabile, Attuabile, Rilevante e Temporalmente definita. Ad esempio: invece di “migliorare la comunicazione”, è meglio “accendere tutti le webcam”.
  • #NoAccountability: le azioni di miglioramento non hanno un responsabile.
  • What improvement: lo Scrum Team non verifica lo stato dei miglioramenti emersi nelle precedenti retrospective.

Se interessati ad approfondire gli anti-pattern, consiglio di completare la lettura scaricando la guida gratuita messa a disposizione da Stefen Wolpers.

Sprint retrospective: come funziona?
Bene, è giunto il momento di condividere suggerimenti utili per migliorare le nostre retrospective.

L’esperienza mi ha insegnato che per iniziare a rendere funzionali le retrospective è utile porre attenzione su alcuni aspetti in particolare:

  • Evitare la noia e la ripetitività: ogni retrospective va progettata rispetto a quanto il team ha esperito durante lo Sprint, selezionando strumenti che riteniamo possano aiutarlo nella riflessione. Piccolo sfogo, finiamola di utilizzare sempre e solo uno strumento come lo Stop/Start/Continue o similari (mongolfiera, barca, ecc.); liberiamo la nostra creatività e divertiamoci.
  • Webcam accesa: se lo Scrum Team lavora da remoto è necessario sensibilizzare le persone a tenere accese le webcam, questa è sempre una buona abitudine, a maggior ragione durante la retrospective. Vale il principio numero sei: “una conversazione faccia a faccia è il modo più efficiente e più efficace per comunicare con il team ed all’interno del team”. Ovviamente non è un obbligo, non sempre è possibile accenderla, l’aspetto importante è far emergere il bisogno e la dimostrazione della sua efficacia nella comunicazione.
  • No finger point: creare un clima sicuro e sereno dove sia in discussione il lavoro e non le persone, rinforzare l’atteggiamento di astensione dal giudizio.
  • Risoluzione di conflitti: è impossibile evitarli, è necessario gestirli sin dai primi segnali, lo Scrum Team deve sviluppare la capacità di affrontare i conflitti e risolverli senza spargimenti di sangue.
  • Intelligenza emotiva: chiedere frequentemente alle persone cosa hanno provato, come si sono sentiti in determinate situazioni, condividendo emozioni positive e negative. Anche questo è un aspetto su cui le persone hanno bisogno di allenarsi e acquisire consapevolezza.

Questo elenco non è esaustivo, sicuramente ciascuno di noi ha altre esperienze e aspetti che può integrare, leggendo la guida agli anti-patterns emergeranno altre strategie per evitare situazioni disfunzionali.

Come strutturiamo a questo punto la retrospective?

Nel mio caso mi sono stati d’aiuto due elementi:
- La struttura in cinque fasi suggerita nel libro Agile Retrospective 
- Gli spunti per personalizzare i diversi giochi forniti da Retromat e FunRetrospective 

La struttura della retrospective proposta nel libro di E. Derby e D. Larsen è composta da cinque fasi:

  • Set the stage: ha come obiettivo quello di aiutare le persone a concentrarsi, deve creare un’atmosfera confortevole dove le persone sentano di poter parlare apertamente.
  • Gather data: l’obiettivo è quello di creare una rappresentazione condivisa di quanto accaduto durante l’iterazione, sono raccolti eventi, fatti, osservazioni e risultati.
  • Generate insights: il team ricerca e discute sulle possibili cause, i dati raccolti durante la fase precedente vengono valutati e se ne ricava una visione significativa.
  • Decide what to do: l’obiettivo è quello di spostare l’attenzione dall’iterazione appena conclusa, alla prossima iterazione. Si decide cosa e come cambiare, sono identificate e ordinate per priorità le azioni di miglioramento, i responsabili e le metriche per determinare il raggiungimento dell’obiettivo.
  • Close the retrospective: è un’opportunità per riflettere su cosa è accaduto durante la retrospective, elencare le decisioni prese, ed è anche un momento per riassumere ciò di cui il team è grato.

Per ciascuna delle fasi è possibile utilizzare delle attività differenti, le attività possono essere selezionate rispetto al livello di maturità del Team (5 fasi di Bruce Tuckman) e, ovviamente, possono essere personalizzate per aderire pienamente con lo spirito del team.

Non elencherò tutte le attività possibili, sono consultabili sui siti di Retromat e FunRetrospective. Per approfondire e vedere un esempio di applicazione di quanto scritto, suggerisco di leggere gli articoli del mio collega Riccardo Ciocci:

Un breve viaggio tra le sue prime retrospective e la loro progettazione decisamente originale, raccontato anche nel webinar The sprint retrospective show.

Libera la tua creatività progettando la tua prossima retrospective.
Se ti va di condividere con me la tua esperienza non esitare a scrivermi.

Se vuoi sviluppare le tue competenze nel facilitare le retrospective e gli altri eventi Scrum, potrebbe interessarti il corso di certificazione ICAgile Agile Team Facilitation.

Per restare aggiornati su nuovi articoli e webinar puoi seguirmi sui social (link nel footer) e sul sito Agile Made in Italy.

Utili consigli per prepararsi alla certificazione Scrum Master PSM I™

Sei alla ricerca di utili consigli per prepararsi alla certificazione Scrum Master PSM I™?

L'Agile Mindset e il framework Scrum sono i protagonisti della trasformazione Agile. Lo Scrum Master è considerato tra i ruoli chiave di questa trasformazione che non è solo fare Agile ma soprattutto essere Agile.

Sono molti i professionisti che hanno iniziato a utilizzare il framework Scrum in azienda e tanti altri si stanno avvicinando. Tutti hanno in comune il desiderio di approfondire il suo funzionamento con casi pratici e ottenere un riconoscimento delle competenze acquisite.

Visto l'importante cambio di paradigma introdotto da Agile, il tempo da dedicare allo studio e il livello di difficoltà dell'esame, sono in molti a cercare suggerimenti e consigli per ottimizzare il tempo e aumentare le probabilità di superare dell'esame.

Così mi sono detto, perché non condividere gli utili consigli per prepararsi alla certificazione Scrum Master PSM I™ di chi ce l'ha fatta?
Questo articolo nasce con l'obiettivo di condividere le loro lesson learned, con lo scopo di aiutare chi sta preparando l'esame di certificazione a ottimizzare il proprio studio.

Di seguito sono riportate le recenti esperienze di chi ha da poco sostenuto e superato l'esame PSM I.  

Vuoi saperne di più? Iscriviti al webinar gratuito.

Utili consigli per prepararsi alla certificazione Scrum Master PSM I™.

Il mio viaggio verso la certificazione PSM I
Utilizzo metodologie Agile da diversi anni ma ritenevo importante partecipare ad un corso che mi desse la possibilità di estendere le mie conoscenze e capire come altri – sul campo - avessero gestito e superato alcune tematiche relative all’utilizzo del framework scrum.

Nel corso Professional Scrum Master ho trovato esattamente quello che stavo cercando. Sviluppo dei concetti teorici di base con ampio spazio ad esercitazioni in gruppo per “provare sul campo” i concetti toccati.

In particolare sono risultate molto utili le numerose esercitazioni pratiche in quanto hanno permesso di fissare i concetti principali ed allo stesso tempo di metterli in pratica.

Avendo come secondo obiettivo l’ottenimento della certificazione Scrum Master, ho poi proceduto ad integrare il corso con altri elementi che mi permettessero di approfondire a sufficienza il tema; quindi :

  • Studio della scrum guide
  • Studio del glossario
  • Open Assessment “Scrum Open” (dal sito ufficiale Scrum.org)

E con questo, alla prova di esame svolta con il docente l’ultimo giorno del corso sono arrivato a rispondere correttamente all’85% circa delle domande.

Nei giorni successivi ho rivisto gli argomenti su cui ero risultato particolarmente debole e mi sono nuovamente confrontato con:

  • Le domande fatte durante la sessione di simulazione di esame del corso (raggiungendo circa il 100% nei tempi massimi previsti)
  • Open Assessment “Scrum Open” (raggiungendo il 100% in modo costante)
  • Test gratuito online relativamente alla certificazione Scrum Master messo a disposizione da “Mikhail Lapshin” (raggiungendo il 100% nei tempi massimi previsti)
  • Question Bank di Sidharth Bathia

Importante sottolineare che tali test di esame NON sono dei dump dell’esame, pertanto hanno il solo scopo di far comprendere il livello a cui si è arrivati e fare emergere gli argomenti su cui è necessario fare approfondimenti.

L’esame richiede di rispondere a 80 domande in 60 minuti ed il minimo richiesto per passarlo è l’85% di risposte esatte. Dato il tempo molto limitato e la percentuale alta di risposte esatte da dare è importante rimanere concentranti e se per alcune domande non si è sicuri della risposta, rispondere con ciò che si pensa sia corretto e “markarle” in modo da rivederle con calma alla fine. Le domande sono un mix tra domande dirette in cui è necessario solo avere studiato (e qui è importante guadagnare tempo) e domande situazionali in cui è necessario avere compreso i concetti (in quanto viene chiesto di dare la/le risposte che riteniamo “più giuste”).

Next step verso la certificazione PSPO I
Dopo aver superato l’esame PSM I, ho seguito il consiglio del docente che durante il corso ci aveva accennato che la PSM I poteva fungere come base di conoscenza per poi affrontare la PSPO I.

Tale certificazione è certamente più complessa ed ampia della PSM I; mi sono quindi affidato ai consigli che venivano dati nei vari blog creandomi il mio percorso di studio; lo riepilogo :

  • Ripasso di tutto quando studiato per la PSM I
  • Studio aggiuntivo :
  • Prove di esame :
    • Tutti gli assessment svolti per la PSM I
    • Open Assessment “Product Owner Open” (raggiungendo il 100% in modo costante)
    • Open Assessment “Evidence Based Management Open” (raggiungendo il 100% in modo costante)
    • Test gratuito online relativamente alla certificazione PSPO I messo a disposizione da “Mikhail Lapshin” (raggiungendo il 100% nei tempi massimi previsti)

Anche in questo caso, è importante sottolineare che tali test di esame NON sono dei dump dell’esame, pertanto hanno il solo scopo di far comprendere il livello a cui si è arrivati e fare emergere gli argomenti su cui è necessario fare approfondimenti.

Come per la PSM I anche l’esame della PSPO I richiede di rispondere a 80 domande in 60 minuti ed il minimo richiesto per passarlo è l’85% di risposte esatte. Quindi i consigli dati per la PSM I rimangono validi. Aggiungo però che il livello di difficoltà è sicuramente superiore in quanto il numero di domande situazionali è molto più ampio, lo stesso vale per gli argomenti da conoscere. Per questo motivo, consiglio di sostenere l’esame solo quando si è certi di avere bene compreso tutti gli argomenti oggetto dell’esame.

Premessa: ho seguito alcuni corsi tenuti da Alessandro Ingrosso nell'ambito del framework Scrum pur non avendo all'inizio alcuna nozione in merito. Fin dai primi momenti mi sono sentito molto coinvolto sia per la modalità in cui Alessandro tiene i suoi corsi sia per le logiche Scrum che si vestivano molto bene con il mio modo di lavorare. Ho iniziato fin da subito ad applicare alcune nozioni apprese durante i corsi vedendo nell'immediato, seppur piccoli, dei risultati.

Certificazione: l'ultimo corso seguito era proprio mirato alla certificazione PSM I al quale ho partecipato con la convinzione che mai avrei comunque conseguito la certificazione stessa. I miei dubbi erano legati alla non perfetta conoscenza del framework ed al fatto (mia lacuna) che dovendo sostenere l'esame in inglese avrei avuto ulteriori difficoltà. Sia l'esame PSM I e PSPO I sono entrambi composti da 80 domande in inglese a cui rispondere in 60 minuti. Per superarli è necessario rispondere in modo corretto all'85% delle domande. Al termine del corso Alessandro è riuscito a trasmettermi la sicurezza necessaria per provare almeno a fare un tentativo. Questa sicurezza non era dovuta solo da un ottimo insegnamento/apprendimento tecnico delle regole Scrum, ma soprattutto dalla giusta comprensione delle logiche dietro al framework Scrum. Concludendo: non solo ho preso la PSM I ma anche la PSPO I.

Meriti: non posso che riconoscere che il merito di Alessandro nel conseguimento delle due certificazioni non sia legato solo alle sue competenze e conoscenza del framework Scrum,ma piuttosto alla sua capacità di trasmettere in modo chiaro e comprensibile le logiche dietro al framework stesso. Sono pienamente convinto che l'aver frequentato i suoi corsi e le successive certificazioni mi permetteranno di avere una visione totalmente differente della gestione dei progetti.

Grazie Alessandro.

Quale ruolo consiglieresti tra Scrum Master e Product Owner?

Quale ruolo del framework Scrum consiglieresti di scegliere tra Scrum Master e Product Owner?
Questa domanda mi è stata fatta infinite volte in aula, recentemente ho pubblicato la mia risposta su Quora. Ho ritenuto utile riportare anche qui la risposta, così da condividere più possibile le differenze che esistono tra Product Owner e Scrum Master.

Product Owner e Scrum Mater sono due ruoli molto diversi.

Nella Scrum Guide il Product Owner è definito come:

Il Product Owner ha la responsabilità di massimizzare il valore del prodotto risultante dal lavoro svolto dal Team di Sviluppo. Come questo è fatto può variare di molto secondo l’organizzazione, gli Scrum Team e gli individui.

Il Product Owner è l’unica persona responsabile della gestione del Product Backlog.

In altre parole il Product Owner si potrebbe vedere come un imprenditore, la sua preoccupazione è soddisfare i bisogni del cliente rilasciano rapidamente e frequentemente valore (vedi articolo HBR sulla piramide del valore). Il principio è quello di trovare la soluzione ad un problema del cliente (customer-centred), e non creare un problema al cliente per vendergli la soluzione (product-centred).

In generale sono necessarie competenze di business, valutazioni su investimenti, marketing, design thinking, ecc. Il Product Owner non è responsabile della soluzione tecnologica di responsabilità del Team di Sviluppo, pertanto non è necessario abbia competenze di sviluppo software.

Lo Scrum Master è definito come:

Lo Scrum Master è responsabile di promuovere e sostenere Scrum come definito nella Guida a Scrum. Gli Scrum Master fanno questo aiutando chiunque a comprendere la teoria, le pratiche, le regole, ed i valori di Scrum.

È un leader a servizio (servant-leader) dello Scrum Team. Lo Scrum Master aiuta coloro al di fuori dello Scrum Team a capire quali delle loro interazioni con lo Scrum Team sono utili e quali no. Aiuta tutti a modificare queste interazioni per massimizzare il valore creato dallo Scrum Team.

Lo Scrum Master non è responsabile della soluzione né in termini di business (Product Owner) né in termini tecnologici (Team di Sviluppo). Si assicura che l’Agile Mindset espresso nei suoi valori e principi sia stato compreso e venga praticato quotidianamente. Si assicura che il framework Scrum sia applicato in modo prescrittivo, facilita gli eventi e le interazioni tra i membri dello Scrum Team. Ha competenze di comunicazione e risoluzione dei conflitti, supporta i membri dello Scrum Team nell’allenare la propria intelligenza emotiva. Rimuove ostacoli e il suo obiettivo è portare il lo Scrum Team ad essere un team ad alte prestazioni (vedi anche articolo sulle fasi di Bruce Tuckman).

Come si può vedere i due ruoli sono molto diversi e richiedono competenze differenti.
Quale ruolo consiglieresti tra Scrum Master e Product Owner?
A questo punto per scegliere è sufficiente stabilire in quale dei due ruoli pensi di poterti divertire nell’accrescere le tue conoscenze e la tua esperienza professionale.

Panoramica certificazioni Agile

Una mappa mentale che rappresenta una panoramica non esaustiva delle certificazioni Agile.

Negli ultimi anni c'è stata una rapida  crescita nel numero di certificazioni Agile, Scrum e framework per far scalare Scrum nelle grandi organizzazioni. Sono sempre stato curioso di mappare lo stato attuale, identificando i principali enti di certificazione, i differenti percorsi, i livelli di certificazione, i requisiti di accesso, i costi, ecc.

Questo primo articolo (è mia intenzione pubblicare altri dettagli) ha come obiettivo quello di fornire una panoramica dell'offerta disponibile. L'articolo non entra nel merito qualitativo di ciascuna certificazione,  è solo un'istantanea dello stato attuale.

Nel rappresentare la panoramica delle certificazioni Agile e non solo ho utilizzato una mappa mentale navigabile. Ciascun nodo è anche un link che punta ai contenuti di approfondimento pubblicati nelle pagine dei siti ufficiali.

Gli enti e le certificazioni riportate potrebbero non essere tutte quelle esistenti. Inoltre rispetto alla data di pubblicazione dell'articolo potrebbero in futuro esserci ulteriori variazioni. Cercherò di mantenere più possibile aggiornata questa pagina, tuttavia se dovessi accorgerti dell'assenza di importanti enti o certificazioni, o riscontrassi errori puoi inviarmi una segnalazione e provvederò ad aggiornare rapidamente i contenuti.

La mappa mentale è navigabile, ed è possibile spostarsi al suo interno, ingrandirla o ridurla. Da questo link puoi scaricare la versione PDF della mappa mentale. Se hai trovato utile questo articolo puoi condividerlo sui tuoi canali social. In fondo alla pagina puoi lasciare i tuoi commenti.

Potrebbe anche interessarti questo articolo: Quale certificazione Agile scegliere?

Quale certificazione Agile scegliere?

Certificazioni, Experto
Certificazioni Agile e Scrum

Quando si parla di Certificazioni Agile ci sono sempre molti dubbi e soprattutto indecisione su quale sia la scelta migliore. Questo perché il panorama delle certificazioni è molto vasto, ma esiste una certificazione migliore delle altre? Quali criteri utilizzare per scegliere la certificazione Agile?
La scelta dipende da una serie di fattori tra cui il contesto lavorativo, le esigenze professionali e il tipo di utilizzo che si vuol fare della certificazione. A tal fine può essere utile una panoramica generale delle certificazioni Agile più diffuse e riconosciute sul mercato.

Vuoi partecipare ad un webinar gratuito sulle certificazioni Agile e Scrum?
Vai alla sezione webinar gratuiti.

Certificazione PMI Agile Certified Practitioner (PMI-ACP)®

La certificazione PMI Agile Certified Practitioner (PMI-ACP)® ha come obiettivo quello di certificare l’esperienza acquisita nell’utilizzo di Metodologie Agili. Anche se non abilita ufficialmente alla professione di Agile Coach, la certificazione ACP® conferma le competenze acquisite dal professionista.

Si tratta di una certificazione che affronta in linea generale tutti gli argomenti che fanno parte delle metodologie Agili e certifica le competenze globali sui temi dell’Agile Project Management. Per sostenere l’esame di certificazione PMI-ACP® è necessario soddisfare i seguenti prerequisiti:

  • Si richiedono 21 contact hours in ambito formativo: è necessario certificare la partecipazione a seminari/corsi in Agile Project Management per un totale di almeno 21 ore.
  • Esperienza lavorativa nella gestione dei progetti: occorre dimostrare con autocertificazione di aver gestito dei progetti per almeno 2000 ore (nell’arco di 2 anni). Questo requisito è automaticamente soddisfatto se si è già in possesso della certificazione PMI-PMP®.
  • Infine, è richiesta esperienza lavorativa nella gestione di progetti Agili: occorre di mostrare con autocertificazione di aver gestito progetti con metodologie Agili per almeno 1500 ore.

Se si è in possesso di questi 3 requisiti si può compilare l’apposito formulario e richiedere l’eleggibilità per l’iscrizione all’esame finale di certificazione. Il costo dell’esame di certificazione ACP® è di € 365 per i membri del PMI ed € 415 per i non membri. Ai costi di iscrizione all’esame devono essere sommati i costi di eventuali corsi di formazione e materiali didattici.

Maggiori dettagli sui costi e sulle modalità di iscrizione sono disponibili sulla pagina dedicata alla guida all'esame.

Certificazione Certified Scrum Master (CSM)®

La Certificazione Certified Scrum Master (CSMdi Scrum Alliance (Certified Scrum Master) è specifica sul framework Scrum, ed è rivolta a chi intende ricoprire o ricopre il ruolo di Scrum Master. Tra tutte le certificazioni è dal 2016 una delle più popolari e richieste in Italia.
Per poter ottenere la certificazione CSM® non ci sono dei prerequisiti specifici e non si devono dimostrare esperienze pregresse. Tuttavia, è obbligatorio partecipare ad uno dei corsi periodicamente svolti in Italia o all’estero della durata di tre giorni. Al termine del corso è prevista un esame online costituito da 40 domande, e della durata di 1 ora. Il costo complessivo del corso è di circa 1.699€ (corso + esame finale).
La certificazione CSM® è ideale per chi ha intenzione di cogliere nuove opportunità di lavoro e valuta di spostarsi all’estero, spesso è un requisito richiesto in fase di selezione.

Certificazione Professional Scrum Master (PSM)®

Anche la certificazione Professional Scrum Master (PSM)® di Scrum.Org è specifica sul Framework Scrum e non ha prerequisiti. Per ottenerla non è obbligatorio seguire corsi formativi, se si hanno già delle solide conoscenze ed esperienza, ci si può preparare in completa autonomia.
L’iscrizione all’esame può essere effettuata in qualsiasi momento, è sufficiente acquistare online il voucher del valore di € 150. L’esame è composto da 80 domande a risposta multipla, ha una durata di 1 ora e si supera con l’85% di risposte esatte. La certificazione PSM dal 2017 è in forte crescita in Italia, è di fatto equiparabile alla certificazione CSM® in termini di valore, ed è vantaggiosa in termini economici. Inoltre, rispetto alle certificazioni ACP® e CSM®, la certificazione PSM è perpetua, una volta ottenuta non è necessario far fronte a costi di rinnovo.
Particolarmente utile il simulatore gratuito dell’esame, disponibile sul sito, che permette di esercitarsi con 30 domande casuali selezionate tra quelle dell’esame.

Vuoi partecipare ad un webinar gratuito sulle certificazioni Agile e Scrum?
Vai alla sezione webinar gratuiti.

Quale certificazione Agile scegliere? Conclusioni

Quale certificazione Agile scegliere? Non esiste una certificazione migliore dell’altra, dipende tutto dai tuoi obiettivi personali e dal budget.

Spero che questa breve panoramica sulle certificazioni di tipo Agile sia stata abbastanza chiara ed esaustiva, così come spero ti possa aiutare ad effettuare la scelta giusta.

Quali criteri utilizzare per scegliere la certificazione Agile?
Se hai bisogno di ottenere una conoscenza più ampia e generale delle metodologie Agili suggerisco di optare per la certificazione PMI-ACP®.
Se invece hai intenzione di cambiare lavoro e spostarti all’estero, un investimento ragionevole è quello di scegliere la certificazione CSM®, ancora molto richiesta e conosciuta sul mercato.
Infine, se hai intenzione di cogliere nuove opportunità in Italia, allora la scelta può essere quella della certificazione CSM® o PSM®.

Se vuoi avere una panoramica completa delle certificazioni agile attualmente presenti sul mercato consulta anche l'articolo Panoramica certificazioni Agile.

Ricorda sempre che queste certificazioni riguardano principalmente la conoscenza di metodi di gestione dei progetti, la capacità di utilizzarli in modo consapevole può dartela solo l’esperienza. Quindi, insieme alla certificazione è altrettanto importante utilizzare realmente metodi Agili nei progetti di tutti i giorni.

Potrebbe anche interessarti questo articolo nel quale sono messe a confronto tre certificazioni Scrum Master.

In questo articolo credi mi sia dimenticato di qualche certificazione? Scrivimi, potrei pubblicare un approfondimento nei prossimi articoli.

Esistono contratti Agili? Quali sono i rischi?

Contratti Agili
Businessman pressing contract on a digital screen, concept about agreement in business

La situazione sui contratti Agili

Il Framework Scrum si sta rapidamente diffondendo nei reparti di sviluppo software delle aziende italiane. Spesso le aziende si rivolgono all'esterno per lo sviluppo del software, per questo motivo in aula mi viene posta sempre la stessa domanda: Esistono contratti Agili?

Ad oggi, in Italia, non sembrano esistere ancora dei modelli contrattuali Agili legalmente riconosciuti. È possibile fornire informazioni sui contratti Agili in generale, ma non supportati da un parere legale.

In Italia, al momento, possiamo  utilizzare tipologie contrattuali che possono essere adattate ad un contesto Agile.

L’assenza di modelli contrattuali Agili può essere un ostacolo è un problema che alcune aziende stanno affrontando in questo momento. Molte vorrebbero affidare esternamente lo sviluppo del software, potendo così beneficiare di processi Agili per la creazione rapida di valore.

Tipologie di contratti internazionali e soluzioni nazionali

All'estero sono già presenti forme contrattuali specifiche per progetti che adottano processi Agili.

Tra le prime organizzazione che hanno sviluppato modelli contrattuali agili è possibile trovare l'Agile Business Consortium. Questo il link per scaricare il modello: Agile Project Framework Contract Template. Ovviamente per utilizzarlo in Italia, oltre alla traduzione, è necessario un adattamento attraverso una consulenza legale.

Esistono anche altri modelli contrattuali di riferimento:

Per ora questi contratti possono essere utili come fonte di ispirazione per adattare contratti legalmente riconosciuti.

Nell'attuale contesto italiano i contratti che meglio possono adattarsi al framework Scrum, e in generale ad Agile, sono il Time & Material e il contratto a rimborso. Nei contratti può essere determinato un tetto massimo di costo, la durata del progetto e la durata di uno Sprint senza necessità di determinare nel dettaglio l’ambito del lavoro. Lo Sprint avrà così sempre lo stesso costo. Sarà necessario porre particolare attenzione al valore che si intende produrre in ogni Sprint, per evitare di spendere più del valore che si otterrà in cambio.

Cosa rende critico un contratto Agile?

L'aspetto considerato critico in un contratto Agile è la potenziale completa assenza di un ambito dettagliato. Oggi è frequente la possibilità che un progetto venga avviato a partire da un’idea e bisogno non ancora tradotti in requisiti tecnici e funzionali.

Una delle caratteristiche del progetto, infatti, potrebbe proprio essere quella di esplorare e apprendere qualcosa di nuovo. I processi e le pratiche Agili sono particolarmente efficaci in progetti complessi. Il modello Agile prevede che a fronte di un ambito poco o per nulla definito, si fissino due variabili : il tempo e il costo. Allo scadere del tempo e del budget, si restituisce ciò che è stato realizzato fino a quel determinato momento. Vi sembra folle? Non lo è, vediamo perché.

Alcune ricerche hanno messo in evidenza che il numero di funzionalità utilizzate da un utente in un prodotto è nettamente inferiore rispetto al loro numero totale. Semplificando potremmo dire che: il 20% delle funzionalità di un prodotto costituisce l'80% del suo valore.

Quindi possiamo affermare che: il costo di ciò che è stato prodotto, è sicuramente minore del valore creato in termini di business (profitti e/o riduzione dei costi).

Pertanto in un progetto non è necessario realizzare tutto, ma tutto ciò che ha valore.

Oggi è ancora particolarmente difficile trovare aziende disposte a fare un contratto su un ambito poco definito.

Ad esempio, cliente e fornitore si accordano per un valore economico e temporale fisso, a fronte di un ambito poco chiaro. In caso di contestazioni su cosa ci possiamo basare?

La trasparenza e la frequente comunicazione tra le parti diventano un elemento centrale per sviluppare fiducia nella collaborazione. Citando il terzo valore dell'Agile Manifesto: "La collaborazione col cliente più che la negoziazione dei contratti". Questo aspetto, a mio parere, non credo sia un elemento gradito ad un ufficio legale e non solo.

Vuoi saperne di più? Inviami le tue domande, ti risponderò nei prossimi articoli.

Cos’è il Framework Scrum? Come funziona?

Scrum
Scrum è un termine mutuato dal rugby.

Che cos'è Scrum e perché si chiama così?

Scrum è il più diffuso tra gli approcci Agili di Project Management, è un  Framework presentato per la prima volta nel 1995, che è stato creato per semplificare la gestione di progetti complessi ed innovativi. Scrum, parola inglese che letteralmente vuol dire “mischia”, è un termine mutuato dal rugby, sport dove tutti i giocatori formano un unico gruppo che spinge e fa forza per raggiungere un obiettivo comune.
Così come nel Rugby, l’obiettivo di Scrum è proprio quello di far convergere le forze di tutti i membri del team per “spingere” in un’unica direzione, affinché siano sempre coesi per raggiungere il risultato finale, produrre il massimo valore e ridurre al minimo i rischi e le perdite.

Questo vuol dire che i membri del Team lavorano per convergere su idee comuni ed essere sempre d'accordo sulle azioni da svolgere nel breve termine.
Il Framework Scrum crea le condizioni affinché le persone si sentano coinvolte nel progetto e lavorino in modo coeso durante tutte le fasi, comunicando tra loro e avendo sempre a mente l’obiettivo finale. La coesione e la comunicazione riducono al minimo l’inefficienza e le pratiche sbagliate.

Lavorare in un team spesso vuol dire far fronte quotidianamente a tante idee e tante proposte diverse, e quando si deve portare avanti un progetto ognuno ha il suo modo di vedere le cose. Gestire un progetto vuol dire raggiungere gli obiettivi attraverso uno o più risultati, e soddisfare le diverse aspettative degli stakeholder spesso non allineate fra loro. Questo, nel Project Management può portare all'insorgere di conflitti, ad un aumento dei costi, a ritardi nella consegna e a volte anche al fallimento del progetto stesso, perché ognuno segue una direzione diversa e alla fine ci si dimentica dell'obiettivo finale. Scrum aiuta a ridurre questi rischi.

Scrum non è una metodologia, è un framework

Scrum è un framework, non è una metodologia. Ma qual è la differenza tra Scrum è una metodologia classica?
Quando parliamo di metodologia ci riferiamo a un qualcosa di predefinito e strutturato, e soprattutto definitivo, che va seguito alla lettera e non prevede modifiche. Il framework è stato creato con l’idea di fornire un processo e dei ruoli ben definiti pur lasciando completa libertà alle persone di modificare gli strumenti in base all'obiettivo e alle tecniche che funzionano di più. Per questo motivo Scrum si può definire un framework aperto, senza strumenti o pratiche predefinite, a differenza delle metodologie tradizionali che sono pensate per progetti predittivi e sono ben definite e strutturate, ma soprattutto più rigide.

Vuoi saperne di più? Inviami le tue domande, ti risponderò nei prossimi articoli.