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.

Dinamica del gruppo: le 5 fasi di Bruce Tuckman in uno Scrum Team

Creare le condizioni per avere un ottimo Scrum Team può rivelarsi un’operazione molto complessa, ma se si conoscono le dinamiche dei gruppi, c’è una maggiore probabilità di raggiungere un alto livello di collaborazione e di prestazione tra tutti i membri dello Scrum Team.

Nel 1965, Bruce Tuckman, professore di psicologia educativa alla Ohio State University, ha studiato l’evoluzione delle relazioni nei rapporti di gruppo in ambito lavorativo, elaborando un modello specifico. Tuckman ha individuato così le 5 fasi che scandiscono le dinamiche dei singoli gruppi. Analizziamole singolarmente calandole nel contesto dello Scrum Team.

FASE 1: Forming

Lo Scrum Team si trova in questa prima fase ogni volta che si verifica una di queste due situazioni: nuova costituzione dello Scrum Team o modifica con inserimento e/o rimozione di uno o più membri del team.

Le singole persone dello Scrum Team inziano a conoscersi, si sviluppa un senso di appartenenza tramite la condivisione dei valori. In questa prima fase ciascun membro del team cerca una figura di riferimento per acquisire le regole di comportamento. Potrebbe essere lo sponsor, il product owner o lo scrum master. Le persone appartenenti allo Scrum Team si osservano e si confrontano per orientarsi, non hanno ancora chiari i comportamenti consentiti, lo stile di comunicazione e le modalità di collaborazione. Da questa fase si transita verso la successiva in modo graduale con l’aumentare della pressione sul lavoro da svolgere. L’urgenza nel dover iniziare le attività porta il team a doversi organizzare rapidamente, causando inevitabili conflitti, e portando alla fase 2.

FASE 2: Storming

Nella fase di Storming (da “Storm” che significa tempesta) si presenta la situazione di conflitto. Il conflitto emerge in modo naturale quando il team deve svolgere attività con forti vincoli temporali. In queste situazioni è necessario che ogni componente del team, esca dalla propria zona di comfort per collaborare e raggiungere l’obiettivo comune. La figura dello Scrum Master è fondamentale, perché assume il ruolo di un coach. Tra i diversi eventi di Scrum questa è in particolare la fase dove valorizzare la Sprint Retrospective, questo evento fornisce supporto nel distendere le tensioni e risolvere i conflitti in modo collaborativo (win-win).

Durante la fase di Storming lo Scrum Team tocca il minimo della sua efficienza, i conflitti non risolti diventano dei veri e propri ostacoli al raggiungimento della massima prestazione possibile. Quante volte ci è capitato, o abbiamo sentito dire: “Preferisco fare io questa attività anche se non dovrei, perché è impossibile parlare con il collega e giungere ad un accordo.” Questo è proprio uno dei sintomi che segnalano la presenza di conflitti non risolti e bassa efficienza.

Come è possibile immaginare, i conflitti nello Scrum Team non termineranno mai, ciò che cambierà con l’allenamento, sarà la capacità di ciascuna persona di riconoscerli e risolverli immediatamente. Questa abilità che si andrà a sviluppare gradualmente nel tempo consentirà dapprima di passare alla fase 3 e poi alla fase 4 delle dinamiche descritte da Tuckman.

FASE 3: Norming

Quando lo Scrum Team diventa consapevole dell’esistenza dei conflitti, dell’importanza che ha la loro risoluzione in ottica collaborativa e non di compromesso, si passa gradualmente alla fase del Norming. In questa fase il team non padroneggia ancora le tecniche di risoluzione dei conflitti, ha ancora bisogno di allenamento, tuttavia ora il team ha reso pubblici i propri conflitti e la propria volontà di superarli insieme e questo è già un ottimo risultato in termini di clima di squadra. Superata la tempesta si rafforza il senso di unità e le singole persone iniziano a sentirsi parte di un team. In questa fase il team si autoregola e si chiariscono anche i contributi che ciascuno può dare allo sviluppo del lavoro. Aumenta il senso di trasparenza e di conseguenza la fiducia, si mettono a punto gli strumenti e le azioni per raggiungere l’obiettivo.

FASE 4: Performing

L’allenamento continuo nella risoluzione dei conflitti, il miglioramento continuo del modo in cui si lavora porta il team nella fase del “Performing”, ovvero della massima efficienza. Questi team sono stati definiti team ad alte prestazioni (High Performace Team o Swarm Team). Lo Scrum Team ora è in grado di auto-organizzarsi e riesce a gestirsi autonomamente, si adatta rapidamente ai cambiamenti e mantiene lo slancio nel processo di miglioramento continuo. In questa fase tipicamente lo Scrum Master può dare maggiore delega al team, in quanto ha maturato tutte le caratteristiche necessarie per aderire totalmente ai valori e principi agili. Nel team tra i membri si è consolidato un clima di sicurezza psicologica (Psycological safety), nessuno ha timori ad aprirsi completamente, condividere debolezze, avere coraggio nello sperimentare, si è raggiunto il massimo livello di collaborazione.

FASE 5: Adjourning

In questa ultima fase delle dinamiche identificate da Tuckman, il team si separa perché il lavoro è stato portato a termine.

In uno Scrum Team questo può accadere, ad esempio, in contesti in cui il team non è interno all’azienda. In una relazione del tipo cliente-fornitore dove al termine degli impegni presi, non essendoci più l’esigenza, le parti si separano per essere impiegate in altri lavori. Un’altra possibile causa di scioglimento del team può riguardare il ritiro di un prodotto dal mercato e dal portfolio aziendale.

Le dinamiche del gruppo
Le 5 fasi del gruppo, di Bruce Tuckman

Alcune considerazioni

Bruce Tuckman ha notato che, ogni qualvolta si aggiunge o si rimuove anche un solo membro dal team, si retrocede e si ritorna alla fase iniziale per passare rapidamente a quella di conflitto (Storming). Se lo Scrum Team è maturo può essere in grado di assorbire rapidamente un cambiamento di un membro del team, perdendo di poco efficienza e per un periodo molto breve. Emerge dunque che il turnover, ovvero il continuo cambiamento di risorse all’interno dello Scrum Team, non è mai positivo e porta quasi sempre ad un rallentamento o blocco del lavoro.

Assumendo uno Scrum Team maturo, e attuando il turnover solo quando strettamente necessario, è possibile ripristinare in tempi brevi la fase di massima prestazione (Performing). Il turnover in questi casi è quello dovuto a cause comuni, ad esempio persone che cambiano lavoro o che si spostano in altri team. Questa capacità rapida di recupero è un beneficio della dinamica di lavoro cross-funzionale dello Scrum Team. All’interno del team c’è la massima condivisione di conoscenza, la più ampia condivisione di competenze e non esistono membri indispensabili, ma tutti sono dispensabili.

Non possiamo a priori stabilire il tempo necessario ad attraversare ciascuna fase, ogni team è unico. Così come non possiamo prevedere con certezza se un team sarà in grado di raggiungere il massimo della sua efficienza. Lo Scrum Master deve essere un coach e supportare il team nel riflettere su quali possano essere gli ostacoli che lo bloccano dal raggiungere la massima prestazione, deve fornire loro le tecniche per superare i conflitti e dar loro autonomia decisionale sulle azioni da intraprendere.

 

 

I 4 valori del Manifesto Agile

I Valori del Manifesto Agile
I Valori del Manifesto Agile

Il Manifesto Agile si compone di quattro valori, ognuno dei quali rappresenta un bilanciamento tra due aspetti entrambi importanti. Non esiste un unico equilibrio tra le parti ma il contesto, gli obiettivi da raggiungere, la maturità organizzativa, la ricerca della creatività e dell’innovazione, generano differenti equilibri tra quanto è riportato a sinistra e a destra di ciascun valore.Non esiste una netta demarcazione tra giusto o sbagliato, ma il bilanciamento viene affinato rispetto al risultato ottenuto: ha funzionato o non ha funzionato.

Gli individui e le interazioni più che i processi e gli strumenti.

Oggi rispetto al passato ci troviamo spesso a lavorare su progetti che sono caratterizzati da un’elevata incertezza, e una forte spinta all’innovazione e alla creatività.
In contesti come questo cercare un processo predefinito e standardizzato per portare a termine un progetto non è mai la soluzione migliore. Siamo stati formati per cercare sempre l’unica soluzione ottima per raggiungere il risultato: analizzare, pianificare, eseguire, controllare e raggiungere l’obiettivo. 
Nella maggior parte dei casi si pretendono dei processi già pronti, preimpostati, ma di fronte all’incertezza e all’esplorazione di nuove soluzioni i team dovrebbero essere liberi di generare nuovi processi, di sperimentare ed essere aperti all’apprendimento.  

Piuttosto, i team dovrebbero creare i propri processi, trovando anche benefici da nuovi strumenti. Questo vuol dire che ogni singolo team può essere libero di utilizzare processi nuovi e personalizzarli in base alle proprie esigenze e obiettivi da perseguire. 

I membri di un team sono talmente abituati a ricevere processi e strumenti predefiniti da parte dell’azienda, che quando questo non accade, il lavoro rallenta o si blocca. 

La causa di tutto questo sono le abitudini e la cultura predittiva, che con il passare del tempo diventano sempre più stabili e ripetitive all’interno di un’organizzazione. Quando questo accade l’organizzazione non è più aperta all’innovazione, alla creatività e all’esplorazione.

Bisogna dunque bilanciare l’interazione tra individui e il rispetto dei processi mettendo al centro gli obiettivi del progetto.

Una domanda chiave può essere: quanto è importante avanzare nella scoperta di nuova conoscenza
Tanto più la nuova conoscenza genera valore e ci rende competitivi, tanto più dobbiamo liberare gli individui e rimuovere gli ostacoli che derivano da processi e strumenti predefiniti.

Il software funzionante più che la documentazione esaustiva.

Per software funzionante si intende un software completo, testato, integrato, che risponde ai requisiti di qualità che sono stati richiesti, e ultimo ma non meno importante, che generi valore per il cliente. 

Ma cosa significa nello specifico essere conforme agli standard di qualità? 

Va specificato innanzitutto che la qualità è soggettiva e può cambiare in base alle esigenze del momento. È necessario dunque specificare qual è il requisito qualitativo del prodotto che si richiede, ovvero la caratteristica principale su cui il progetto deve puntare. 

Ad esempio, non è sufficiente dire vorrei acquistare un abito di qualità

Cosa intendiamo di preciso per abito di qualità? Un abito di buona fattura, che vesta alla perfezione, o realizzato da uno stilista affermato?

Chi di noi acquisterebbe un abito di pessima qualità?

Occorre dunque specificare la qualità che si richiede in maniera chiara e misurabile. Nella sesta edizione del PMBOK la qualità è definita come “il grado a cui determinate caratteristiche sono conformi ai requisiti”. Il grado di qualità deve essere una metrica misurabile, o è DONE o è NOT DONE.

Per quanto riguarda la documentazione esaustiva invece, si intende tutto quel lavoro che non è consegnato al cliente perché privo di valore. L’investimento del cliente non deve essere sprecato per qualcosa che non gli verrà consegnato, perché questo non produce valore ai suoi occhi.

Questo approccio solleva un’altra domanda, come ci si assicura il trasferimento della conoscenza ad altri quando è necessario rendere efficienti i costi della documentazione?

Un documento cartaceo non sarà mai sufficiente a trasferire la nostra intera conoscenza a un’altra persona. Inoltre, va considerato che i singoli processi possono cambiare di volta in volta, perché è proprio la nostra conoscenza che ci fa cambiare comportamento, migliorare, ogni volta che ci troviamo in una situazione conosciuta. 

Questo perché la conoscenza acquisita porta sempre valore e ci permette di commettere meno errori e svolgere le attività in modo più efficiente. 

La soluzione ottimale è lavorare insieme in un team più possibile cross-funzionale.

Lavorare insieme condividendo gli stessi spazi fisici, è il modo migliore per condividere la conoscenza. Questo perché c’è meno necessità di documentare le attività, e perché il dialogo è il metodo meno costoso e più efficace per trasferire conoscenza.

Il limite importante è che la conoscenza non potrà mai essere trasferita facilmente in un altro gruppo, senza una forte interazione tra le parti.

Il lato positivo invece è che in questo modo si costruisce un team resiliente. Se sostituiamo un membro del team con un'altra persona, questa potrà integrarsi facilmente al gruppo, e acquisire conoscenza in tempi rapidi assorbendola dagli altri membri.

La collaborazione col cliente più che la negoziazione dei contratti.

Questo valore prevede la necessità di mantenere sempre una relazione collaborativa con i principali stakeholder del progetto, fortemente fondata sul concetto di trasparenza e fiducia.

La collaborazione è dunque un aspetto fondamentale, soprattutto di fronte alle numerose modifiche che ci saranno nel corso del progetto. È necessario dunque formulare dei contratti adeguati e non contratti ad ambito prefissato. I contratti a rimborso spese e i Time & Material sono quelli che si adattano meglio al Manifesto Agile. In questo mio precedente articolo puoi trovare un approfondimento specifico sui contratti Agili.

Rispondere al cambiamento più che seguire un piano.

In Agile non si utilizza il Gantt, ma questo non vuol dire che non si faccia alcuna pianificazione. Si procede piuttosto nell’esecuzione di una pianificazione di tipo adattativo, ovvero che accetta cambiamenti al progetto ed è flessibile. 

La pianificazione adattativa non prevede un percorso predefinito, perché ogni team deve trovare il proprio in base all’esperienza maturata e al contesto in cui si trova. Abbracciare il cambiamento è il modo migliore per far sì che tutto ciò avvenga.

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.

Quali sono i pilastri e le cerimonie di Scrum?

i pilastri e le cerimonie

I tre pilastri di Scrum

I tre pilastri di Scrum si basano sul processo di controllo empirico, e sono:
  • Trasparenza
  • Ispezione
  • Adattamento
Trasparenza. Scrum non prevede sorprese. Tutti gli stakeholder hanno una visione aggiornata su tutti gli aspetti del progetto. Gli stakeholder coinvolti:
  • aggiornano costantemente la business vision;
  • condividono lo stato di avanzamento del lavoro;
  • forniscono il supporto utile alla creazione di valore;
  • collaborano alla rimozione di ostacoli e impedimenti.
Necessità, adattamenti e criticità sono affrontate nel momento stesso in cui si manifestano, perché tutti hanno completa visibilità su tutto. L’ispezione è in altre parole il momento del feedback. Le cerimonie Scrum garantiscono una forma di monitoraggio e controllo. L'ispezione periodica e frequente, aiuta a far emergere le diverse criticità. Che possono riguardare aspetti tecnici, interpretazioni errate o miglioramenti di pratiche che non stanno portando i risultati sperati. Adattamento. A differenza degli approcci predittivi, che correttamente limitano la quantità di modifiche, gli approcci agili abbracciano il cambiamento. Sono pensati per adattare il progetto ai cambiamenti. L'acquisizione di nuove informazioni lungo il progetto, rende necessaria l'integrazione di modifiche, al fine di massimizzare il valore restituito al business.

Lo Sprint e le sue cerimonie

Gli Sprint sono il cuore di Scrum, ovvero le iterazioni che consentono l’attuazione, lo sviluppo e l’evoluzione di un prodotto. Lo Sprint è un periodo temporale predeterminato (che può durare da due a quattro settimane), al termine del quale vengono resi noti i progressi del progetto. Al termine dello Sprint si presenta il risultato del lavoro, ovvero un prodotto potenzialmente rilasciabile e utilizzabile (Potentially Shippable Product). Il risultato di uno sprint può anche essere considerato una sorta di "evoluzione del prodotto". Alcuni degli obiettivi di uno Sprint sono:
  • produrre costantemente valore
  • effettuare rilasci frequenti
  • intervenire con miglioramenti laddove necessario.
Per ogni Sprint lo Scrum Team definisce uno Sprint Goal. Lo Sprint Goal è un obiettivo ben preciso che deve portare valore e far avanzare il progetto in maniera costante. Il Framework Scrum è composto da 4 cerimonie:
  • Sprint Planning Meeting: è l’incontro di apertura di uno Sprint dove vengono chiariti i requisiti più importanti nonché l’obiettivo, lo Sprint Goal.
  • Daily Scrum Meeting: è un incontro giornaliero, che dura al massimo 15 minuti. Il team aggiorna e pianifica il lavoro da svolgere nella giornata lavorativa.
  • Sprint Review Meeting: è un incontro durante il quale il team presenta i risultati dello Sprint. I risultati vengono approvati o rifiutati e si collabora per definire i prossimi passi.
  • Sprint Retrospective: è l'incontro che chiude lo Sprint. Il team riflette su ciò che è andato bene e sui miglioramenti che si possono apportare nel prossimo Sprint. L’obiettivo è quello di ridurre i rischi e massimizzare i risultati finali. Durante lo Sprint Retrospective il Team si pone le seguenti domande:
  • Come sta procedendo il progetto fino a questo momento?
  • Quali sono le modifiche che possiamo apportare per migliorare i risultati?
  • Cosa sta funzionando e cosa invece si può eliminare?

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.