Autore: Roberta Mazzotta

Di Marco Passarella

———

In questo articolo parliamo della prima puntata di “Sfatiamo i miti di Scrum”, la serie di webinar di Agile Made in Italy nata per tutti gli agilisti che stanno utilizzando il framework Scrum, ma incontrano difficoltà ad applicarlo concretamente e si stanno chiedendo come migliorare il loro approccio alle metodologie Agile, e in particolare all’utilizzo del framework Scrum.

Nel corso del webinar ho avuto il piacere di conversare con tre membri di Agile Made in Italy che hanno condiviso le loro esperienze: Alessandro Ingrosso, Agile Coach e Trainer con esperienza decennale nella collaborazione con importanti aziende italiane di formazione e settore IT; Riccardo Ciocci, Scrum Master e consulente presso la società di consulenza BIP Spa, che ha introdotto i concetti di Agile e Scrum in diverse aule e ha scritto articoli su argomenti correlati; e Sabrina Laterza, ex filosofa e marketer digitale, che attualmente lavora come Scrum Master presso l’azienda Progetti e Soluzioni Spa.

Ci siamo chiesti subito a che punto siamo con l’Agile? Abbiamo menzionato la sedicesima edizione del report “State of Agile”, un rapporto indipendente che fornisce dati sullo stato e l’andamento dell’Agile a livello globale, grazie ai dati provenienti da interviste a oltre 3200 Agile coach o scrum master.

L’89% degli intervistati ha espresso l’importanza dei valori centrati sulle persone e della leadership per ottenere benefici dall’approccio Agile. Inoltre, sottolinea come l’utilizzo delle pratiche agili migliori la collaborazione, l’allineamento con gli obiettivi aziendali e l’ambiente di lavoro. Infine, si è menzionato che Scrum è la pratica più adottata a livello mondiale, utilizzato da 9 su 10 intervistati. Kanban è risultato essere la seconda pratica più diffusa. 

Abbiamo dato uno sguardo anche a ciò che non sta funzionando bene: cultura, leadership e coerenza sono le tre sfide fondamentali. È emerso che spesso la leadership non comprende appieno l’Agile o addirittura mette ostacoli alla sua adozione. Altre sfide includono la mancanza di priorità chiare, la mancanza di una comprensione adeguata da parte dei team riguardo a cosa significhi Agile e come intraprendere il percorso correttamente.

L’Agile non è qualcosa che le aziende colgono intuitivamente. I coach e i consulenti Agile, ma anche gli scrum master che stanno lavorando per espandere l’adozione di Agile, devono continuare a lavorare per assicurarsi che il management e i team di lavoro cross-funzionali capiscano cos’è l’Agile e come influirà sul loro lavoro, poiché la statistica annuale mostra la necessità di migliorare la comprensione dell’Agile da parte delle aziende. 

Dopo questa panoramica generale sullo stato dell’Agile, l’incontro è entrato nel vivo dei miti di Scrum. Il primo mito che abbiamo preso in considerazione è “Basta vedersi ogni giorno per fare Scrum”. Capita frequentemente di incontrare persone orgogliose perché hanno iniziato a vedersi ogni giorno e sono centrate sulle cerimonie e su quello che è scritto nella guida Scrum. Ma questo da solo non basta. Sarebbe un po’ come andare ogni giorno in palestra senza usare nessun attrezzo e aspettarsi di mettere su massa muscolare o dimagrire. Abbiamo sottolineato come sia importante approfondire il contesto e comprendere che Scrum non è una soluzione magica per garantire consegne perfette e puntuali. Scrum non può compensare problemi strutturali o di pianificazione all’interno di un progetto.

Sebbene gli eventi Scrum vengano eseguiti regolarmente, potrebbero mancare la sostanza e il valore che dovrebbero fornire. L’aspetto formale delle pratiche agili può essere fuorviante se la sostanza e il mindset dietro di esse non sono presenti. Abbiamo ascoltato un’esperienza personale in cui un progetto è stato avviato seguendo le pratiche Scrum, ma il prodotto e le sue funzionalità erano già prestabilite e non richiedevano ispezioni, adattamenti o feedback continui. Questo ha portato a una situazione in cui gli eventi Scrum venivano eseguiti solo perché era richiesto, senza fornire il valore atteso. L’applicazione di Scrum richiede un mindset centrato sulle persone, il soddisfacimento del cliente e il valore che si intende offrire. Due segnali importanti per valutare se un progetto sta andando verso una direzione Agile sono la necessità di sperimentare e l’importanza dei feedback. Se un progetto è completamente pianificato e non richiede sperimentazione o feedback, allora potrebbe non essere necessario applicare Scrum. È importante considerare la complessità del contesto e adattare il mindset di conseguenza. Gli eventi di Scrum sono solo una rappresentazione visibile di tale mindset e non possono garantire il successo di un progetto se la sostanza e il contenuto non sono presenti. Questo mito perciò ci ha fatto considerare l’importanza del mindset e della cura delle persone come base per l’applicazione efficace di Scrum. 

Il secondo mito di cui abbiamo discusso è “Scrum consente di consegnare tutto e in tempo”. Questo mito è spesso alimentato da una mentalità di pushing dei requisiti all’interno dello sprint, senza considerare la creazione di valore e l’importanza dei feedback.

Lo sprint goal non può essere l’obiettivo di completare tutte le cose prese in carico durante lo sprint, altrimenti diventa micro waterfall e tutto perde di senso. Lo sprint è un’opportunità per fare un tentativo di creare valore, sperimentare e apprendere. È importante comprendere che Scrum è incentrato sulla creazione di valore e non sull’output numerico di caratteristiche o ticket risolti.

Durante questa conversazione è arrivata una domanda proveniente da LinkedIn riguardante l’aggiunta di requisiti non concordati durante lo sprint. Si è evidenziato che la risposta dipende dalla definizione delle user story, dai criteri di accettazione e dalla comunicazione con il cliente. È importante coinvolgere il cliente o il business per chiarire se la richiesta aggiuntiva è effettivamente un’aggiunta o un requisito mancante. Questa è stata l’occasione per ribadire l’importanza di coinvolgere il cliente per comprendere le sue esigenze e valutare l’aggiunta di requisiti non previsti. Il confronto e la negoziazione sono essenziali per gestire queste situazioni in modo efficace.

Spesso si sente dire: “lo scrum Master deve essere uno sviluppatore”. Abbiamo perciò discusso dell’importanza di comprendere le competenze e il ruolo dello Scrum Master al di là delle capacità tecniche.

Il ruolo dello Scrum Master va al di là delle competenze di sviluppo software. Lo Scrum Master deve concentrarsi sulla comunicazione efficace con il team, sulla gestione dei conflitti, sulla creazione di un ambiente di sicurezza psicologica e sul supporto alla padronanza del team. È un ruolo che richiede una visione d’insieme, competenze di facilitazione e la capacità di far emergere soluzioni attraverso domande potenti.

Abbiamo condiviso un esempio personale di un’esperienza come Scrum Master senza conoscenze tecniche approfondite. Anche in questo caso il focus deve essere sulle persone del team e sulla creazione di fiducia, piuttosto che risolvere direttamente i problemi tecnici. Abbiamo ribadito che Scrum può essere adattato a diversi ambiti e che il vero sviluppo professionale come Scrum Master consiste nel focalizzarsi sulle persone e non solo sulla soluzione del problema.

Infine, abbiamo accennato alla domanda frequente su cosa faccia lo Scrum Master durante il resto del tempo, sottolineando che il ruolo dello Scrum Master va oltre le attività di planning, daily stand-up, review e retrospective, e che è importante non sottovalutare le competenze richieste per facilitare il team in modo efficace.

Nell’ultima parte del webinar abbiamo affrontato alcune domande dei partecipanti. Una di queste ha riguardato come dovrebbe comportarsi uno Scrum Master quando si trova a dover affrontare compromessi forzati che portano a un modello ibrido di Scrum ed esecuzione.

Abbiamo sottolineato che Scrum è un mindset e non una metodologia rigida, e che ciò che conta è il valore e l’agilità del team, piuttosto che aderire rigidamente a quanto scritto nelle guide. Ogni persona ha la propria idea di cosa significhi Agile, e il ruolo dello Scrum Master è quello di essere un agente di cambiamento, aiutando le persone a sviluppare la loro consapevolezza e conoscenza gradualmente.

Un modello ibrido può sicuramente emergere e se sta funzionando, se porta risultati e le persone sono motivate, potrebbe non essere necessario forzare un approccio diverso. Al contrario, si può costruire intorno a ciò che sta emergendo e che funziona, e sperimentare eventualmente in seguito.

Spesso le divergenze sull’agilità derivano dalle diverse interpretazioni individuali del concetto. È importante allineare le diverse visioni e interpretazioni all’interno dell’organizzazione per evitare conflitti e favorire una comprensione condivisa di cosa significa essere agili.

L’ultimo mito della serata ha riguardato l’idea di cross funzionalità nei team e dei miti ad essa associati. Si afferma spesso che tutti i membri del team devono saper fare tutto, ma in realtà spesso si richiede l’aiuto di team esterni per competenze specifiche. Ciò può creare un disequilibrio nel lavoro e generare frustrazione tra i membri del team. Abbiamo commentato che la cross funzionalità vera e propria si raggiunge quando il team ha un’ampia gamma di competenze e quando c’è un’effettiva collaborazione e scambio di conoscenze tra i membri. Tuttavia, ciò può essere ostacolato dalle politiche e dalla cultura organizzativa che valutano le performance individuali solo in base al proprio lavoro anziché alla condivisione delle conoscenze. La soluzione è promuovere la formazione e la condivisione delle competenze all’interno del team, anche a discapito della velocità di consegna. La velocità, infatti, non dovrebbe essere l’unico obiettivo da perseguire, ma piuttosto la qualità e la crescita complessiva del team.

Questo primo incontro è stato un grande successo, ha fatto emergere contenuti molto attuali e ha spinto numerosi partecipanti ad entrare nel vivo della discussione e a proporre spunti nuovi, incoraggiando noi di Agile Made in Italy proseguire con questi incontri per sfatare altri miti.

Se anche tu hai in mente delle convinzioni errate su Agile e Scrum che vorresti approfondire, proponi il tuo mito! Scrivimi all’indirizzo m.passarella@agilemadeinitaly.com e capiremo insieme come inserirlo nei prossimi momenti di incontro. 

A presto con altri miti di Scrum!

Sfatiamo altri miti di Scrum – #2

Sfatiamo nuovi e altri miti di Scrum – #3

 

Di Marco Passarella

——–

Durante la prima edizione del webinar “Sfatiamo i miti di Scrum”, abbiamo ricevuto molte risposte positive. Questo ci ha spinto a ripetere l’esperienza, poiché abbiamo raccolto molte domande scottanti sull’argomento. 

Continua perciò la nostra serie sulle convinzioni errate che circolano a proposito di Scrum, dove cerchiamo di aiutare gli agilisti che si stanno chiedendo come migliorare il loro approccio alle metodologie Agile.

Sabrina Laterza, una Scrum Master della nostra comunità di pratica Agile Made in Italy, ha condiviso un’interessante analogia: avete mai provato la sensazione di vedere una foto perfetta della Fontana di Trevi sui social media, ma poi sperimentare la realtà affollata e caotica quando si è lì di persona? Lo stesso vale per Scrum: può sembrare perfetto durante lo studio, ma applicarlo nella vita reale può essere un’esperienza molto diversa!

Dunque, per affrontare alcune di queste difficoltà, ho avuto il grande piacere di conversare con Anna di Girolamo, Agile Coach e formatrice, fermamente convinta che Agile non sia solo per l’IT e che governare la complessità sia innanzitutto un fatto di mindset, e con Orazio Sarno, informatico nerd con esperienza internazionale nei ruoli di Agile Coach, Scrum Master, Product Owner e Developer, che sta supportando la  trasformazione digitale Agile e DevSecOps di clienti della PA in questa sfida epocale. 

 

Mito #1 – La daily e la retro si possono anche non fare

Secondo la guida Scrum, sia la Daily Scrum che la Retrospective sono eventi essenziali e dovrebbero essere fatti, ma spesso si sente dire che questi eventi possono essere trascurati o addirittura evitati. 

Nella sua esperienza come Agile Coach, Anna ha notato che spesso il primo evento a essere saltato è la Daily Scrum, seguito poi dalla Retrospective. Questo indica una disfunzione all’interno del team. Spesso, questo è il risultato di una mancanza di comprensione del mindset Agile e del valore degli eventi. Alcuni segnali di allarme includono la mancanza di tempo per dedicarsi a tali eventi e una focalizzazione eccessiva sull’output e sui task operativi a scapito della condivisione, dell’apprendimento e del miglioramento continuo.

È important che il team capisca il valore degli eventi e il loro significato. Lo Scrum Master svolge un ruolo cruciale nel trasmettere l’importanza degli eventi e nel creare un ambiente sicuro e motivante per la Retrospective, in cui il team può affrontare i problemi e migliorare continuamente.

La Retrospective dovrebbe essere un momento atteso e desiderato dal team, in cui si esprimono apertamente i problemi e si cerca di migliorare. Molto importante è anche variare le modalità delle retrospettive per mantenerle interessanti e coinvolgenti.

Questo primo mito ha scaldato gli animi dei partecipanti, che hanno condiviso alcuni commenti interessanti riguardanti la Daily Scrum e la Retrospective. Hanno sottolineato l’importanza di non trasformare la Daily Scrum in un momento inquisitorio, ma piuttosto di concentrarsi su quale problema sta avendo ciascun membro del team e come gli altri possono aiutarlo. Inoltre è stato aggiunto che piace molto sentire le persone condividere i problemi che stanno incontrando e come il team possa supportarle.

Un partecipante ha anche sollevato il problema della trasparenza durante le retrospettive. Alcune persone possono tendere a nascondersi e questo può rendere difficile ottenere una piena trasparenza. Questo è un problema comune e la trasparenza richiede una grande onestà intellettuale e un ambiente psicologicamente sicuro. Ci vuole tempo per costruire la fiducia reciproca all’interno del team, ma è un processo essenziale per ottenere una retrospettiva efficace. 

Orazio ha suggerito alcune tecniche per favorire la partecipazione durante le retrospettive, come chiedere feedback anonimi scritti su post-it e introdurre le webcam accese in modo graduale per consentire a tutti di sentirsi più a proprio agio nell’esprimersi.

Anna ha sottolineato l’importanza della comunicazione non verbale, consigliando di lavorare come se le persone fossero nella stessa stanza, anche se in modalità remota, per aiutare a creare un ambiente di collaborazione e connessione più forte.

In conclusione, sia Anna che Orazio hanno evidenziato l’importanza di costruire un ambiente di fiducia e sicurezza psicologica per favorire la trasparenza e il coinvolgimento durante le retrospettive. La trasparenza e l’apertura sono fondamentali per affrontare i problemi e migliorare continuamente come team.

 

Mito #2 – in Scrum la qualità non conta

Un altro mito frequente è che in Scrum la qualità non conta. Invece, la qualità è un elemento fondamentale nello sviluppo Agile e Scrum. Non solo, è anche uno degli elementi invariabili tra la metodologia Waterfall e Agile. Anche se Agile è basato su pochi principi, la qualità rimane un pilastro essenziale.

Il developer, secondo la Scrum Guide, ha il ruolo principale di infondere qualità in tutto ciò che fa. La professionalità di uno sviluppatore è legata alla qualità del lavoro che produce. Una mancanza di qualità può influire sulla capacità di andare a dormire sereni, sapendo di aver consegnato qualcosa che non è adeguato.

La Scrum Guide stessa menziona la qualità in diversi punti e un artefatto che parla di qualità è la Definition of Done (Definizione di Fatto). Questa definizione specifica cosa deve essere fatto affinché un elemento di backlog sia considerato completato e consegnabile. È responsabilità del team garantire che la Definition of Done venga rispettata.

La qualità è un aspetto cruciale anche durante le retrospettive. Questi eventi consentono al team di riflettere sulle prestazioni passate, individuare punti di forza e debolezza e identificare miglioramenti per fornire un lavoro di qualità sempre maggiore.

Alcune tecniche per garantire la qualità sono l’uso di metriche per misurare e valutare il codice o la code review, che aiutano a migliorare la qualità del prodotto e a fornire valore al cliente.

Inoltre, è stato menzionato che a volte in azienda si può confondere l’agilità con la “quick and dirty”, cioè rilasciare rapidamente qualcosa senza prestare attenzione alla qualità. Questo è un grave malinteso, poiché l’agilità non significa affrettarsi, ma piuttosto consegnare qualcosa di valore al cliente con la massima qualità possibile.

In conclusione, la qualità è un elemento insostituibile nell’Agile e nello Scrum. Non si tratta solo di rispettare standard e procedure, ma di sviluppare una mentalità che valorizzi la qualità in ogni aspetto del lavoro. La Definition of Done è uno strumento importante per garantire la qualità del prodotto, ma è anche responsabilità di ogni membro del team, specialmente del Developer, contribuire alla qualità complessiva del lavoro consegnato.

 

Mito #3 – Lo scrum Master è il project manager

Non sono mai abbastanza le volte in cui ribadire con forza la distinzione tra il ruolo dello Scrum Master e quello del Project Manager. Sono due ruoli con competenze e responsabilità diverse.

Lo Scrum Master è il custode di Scrum, si occupa di far rispettare le regole del framework e di supportare il team nello sviluppo di un prodotto di qualità, incoraggiando la collaborazione, la fiducia e la trasparenza. La sua attenzione è incentrata sul processo e sul benessere del team.

D’altra parte, il Project Manager ha una visione più ampia del progetto, con un focus sul lato business, economico e organizzativo. Solitamente, utilizza approcci predittivi o adattivi per gestire il progetto e le risorse coinvolte.

La confusione tra i ruoli può verificarsi, soprattutto nelle organizzazioni che stanno adottando l’Agile per la prima volta. È importante educare le persone e far capire le differenze tra questi due ruoli. Uno Scrum Master non deve essere coinvolto nel controllo degli sviluppatori o nella produzione di Gantt, poiché queste attività non rientrano nei suoi compiti.

Il lavoro dello Scrum Master è fondamentale per creare un ambiente di lavoro in cui il team possa essere libero di concentrarsi sul raggiungimento degli obiettivi senza interferenze esterne. Mischiare i ruoli o chiedere allo Scrum Master di fare compiti di Project Manager può compromettere l’efficacia del team e la riuscita del progetto.

La Scrum Guide definisce chiaramente i ruoli all’interno di Scrum: Scrum Master, Product Owner e Development Team. Non c’è una figura del Project Manager tra questi ruoli, poiché Scrum è incentrato sulla self-organization e sulle responsabilità condivise all’interno del team.

In definitiva, educare l’organizzazione sulle differenze tra i ruoli e mantenere chiare le responsabilità di ciascun ruolo è essenziale per ottenere il massimo valore dall’adozione di Scrum.

 

Mito #4 – Scrum è semplice da adottare

L’adozione di Scrum può sembrare semplice inizialmente, a causa della sua struttura chiara e delle poche pagine presenti nella guida ufficiale. Tuttavia, la sua efficace implementazione richiede molto più di una semplice comprensione della teoria. La cultura e il mindset dell’organizzazione e dei suoi membri sono fattori cruciali per una corretta adozione di Scrum.

Cambiare la cultura e la mentalità di un’organizzazione è una delle sfide più grandi nell’adozione di qualsiasi approccio Agile. Senza una mentalità aperta al cambiamento e una passione per migliorarsi continuamente, qualsiasi framework, inclusi Scrum e SAFE, rischiano di non essere adottati in modo efficace.

Inoltre, adottare Scrum significa non solo implementare meccanicamente i ruoli, gli eventi e gli artefatti, ma abbracciare i principi e i valori alla base di questo framework. La cultura agile si basa sulla collaborazione, la fiducia, la trasparenza e la responsabilità. Solo con l’impegno e la dedizione di tutti i membri del team è possibile raggiungere i risultati desiderati.

Anche l’approccio adattivo e un impegno costante nel mantenere il focus sull’obiettivo finale sono fondamentali. Con Scrum, il team si avvicina gradualmente all’obiettivo, imparando e migliorando costantemente. Questo favorisce la motivazione, che cresce nel vedere progressi costanti e nel raggiungere risultati significativi ad ogni Sprint.

L’aspetto umano e la formazione del team sono essenziali per creare una cultura di collaborazione e fiducia all’interno del gruppo. La selezione delle persone per il team Scrum dovrebbe essere un processo oculato, dove si valutano non solo le competenze tecniche ma anche l’affinità mentale e la predisposizione al cambiamento. Un team Scrum dovrebbe avere una mescolanza di competenze diverse e una forte sinergia tra i membri per funzionare al meglio.

Inoltre, il processo di formazione del team è continuo. Gli Scrum Master devono lavorare costantemente per aiutare il team a migliorare le proprie capacità tecniche e sociali. L’approccio cross-funzionale è importante non solo per quanto riguarda le competenze tecniche ma anche per l’inclusione di diverse prospettive, sfumature e background culturali, che possono contribuire a una maggiore creatività e resilienza del team.

La costruzione di un team coeso richiede tempo e pazienza. Così come una squadra di calcio o una band musicale, il successo di un team Scrum non si ottiene improvvisamente, ma attraverso la pratica, il dialogo, la condivisione e il lavoro di squadra.

 

Proponi il tuo mito

Anche questo incontro è stato un grande successo perché ha portato alla luce contenuti molto pertinenti e ha spinto molti partecipanti ad attivare la webcam ed entrare nel vivo della discussione per fornire idee nuove; per questo motivo, noi membri di Agile Made in Italy siamo entusiasti di continuare a organizzare questi incontri per sfatare nuovi miti.

Se anche tu hai sentito dire qualcosa su Agile e Scrum che non ti sembra corretto e vorresti approfondire, proponi il tuo mito! Scrivimi all’indirizzo m.passarella@agilemadeinitaly.com e capiremo insieme come inserirlo nei prossimi incontri. 

A presto con altri miti di Scrum!

 

Sfatiamo i miti di Scrum – #1

Sfatiamo nuovi e altri miti di Scrum – #3

 

 

Di Marco Passarella

—-

 

Mercoledì 12 luglio è andata in onda un’altra puntata di “Sfatiamo i miti di Scrum”, la serie di webinar di Agile Made in Italy nata per coloro che stanno utilizzando il framework Scrum in azienda, ma incontrano difficoltà ad applicarlo concretamente e si stanno chiedendo come migliorare il loro approccio Agile. 

Abbiamo ascoltato l’esperienza sul campo dei membri di Agile Made in Italy: Vittorio Polizzi, Kanban Coaching Professional e Matteo Toto, CTO della startup Unguess e agilista di lunga data. Insieme a loro ho avuto modo di conversare su come superare alcuni degli ostacoli più comuni nell’applicazione di Scrum.

Il primo mito che abbiamo sfatato è “La velocity è la performance del team”. Partendo dal presupposto che la velocity è un indicatore interno al team, un numero empirico che ha senso soltanto all’interno dello sprint e ricavato semplicemente dalla somma degli story point, abbiamo concordato che non avrebbe senso prendere questa metrica come indicatore di performance del team. La velocity, infatti, può essere “sexy” quando si impenna, ma l’obiettivo deve essere la stabilità, segno che il team ha raggiunto un ritmo di lavoro sostenibile. Da qui l’importanza di valutare i trend: è l’andamento della velocity che ci deve interessare, e che può essere argomento di retrospective quando vediamo che la curva inizia ad avere dei picchi incontrollabili, sia in positivo che in negativo. 

Il secondo mito che è emerso dalla discussione è “In Scrum si rilascia solo a fine sprint”. La falsità di questo assunto è data dal fatto che Scrum nasce proprio per consentire rilasci di prodotto molto veloci. Per farlo però servono qualità, disciplina e coraggio. Rilasciare molto frequentemente consente di ottenere cicli di feedback più rapidi. Questo è molto vantaggioso, anche se, soprattutto all’inizio, questo può avere dei costi, soprattutto sul piano emotivo del team, che vive il momento di portare un incremento in produzione con l’ansia che qualcosa possa andare storto. Ma la verità suggerita dall’esperienza è che rilasciare frequentemente abbatte drasticamente il rischio. Un punto importante è legato alla competenza del team e alla propensione all’utilizzo delle tecniche di sviluppo più aggiornate. Se i developer utilizzano politiche di rilascio basate su automazione, continuous integration, continuous deployment, rilasci in produzione su subset di utenti, allora possono affrontare il delivery con maggiore tranquillità. Si è parlato anche di code review applicata al lavoro dei dev, non tanto come strumento di giudizio sull’operato del singolo, ma come salvaguardia del prodotto. In questo modo diventa un fattore di responsabilizzazione e di crescita per tutto il team. Queste pratiche vanno anche a far parte della Definition of Done, a conferma del fatto che la qualità del prodotto è sempre al primo posto. 

Infine, dall’ambito dello sviluppo, ci siamo spostati a quello del business, mettendoci dalla parte di un cliente con il mito “Se lavori Agile non so per cosa pago”. Il cliente può non essere disposto a pagare per un prodotto che ancora non sa quale direzione prenderà. La prima considerazione è che serve un allineamento culturale tra cliente e fornitore, che devono perdere questa connotazione e iniziare a sentirsi partner. Deve essere un rapporto in cui entrambi gli attori sono dalla stessa parte. Quando si crea questa alleanza, allora si comprende che è impossibile mettere nero su bianco tutto il dettaglio all’inizio. Si possono condividere gli obiettivi (outcome), ma poi per quanto riguarda le soluzioni tecniche (output) in Agile si può cambiare rotta anche di mese in mese. Un’esperienza emersa nella discussione ha di fatto evidenziato come una possibile soluzione sia quella di iniziare un rapporto di collaborazione riducendo al minimo il progetto. Se invece di concordare uno sviluppo di un anno o di sei mesi, si concorda di sviluppare un MVP (Minimum Viable Product), un mini prototipo funzionante, si ha la possibilità di vedere subito risultati concreti, di ottenere qualcosa di funzionante e di validare l’efficacia della metodologia di lavoro. In Italia c’è ancora molta diffidenza verso l’approccio Agile, ma molti segnali positivi stanno emergendo, e non solo nel privato, ma addirittura anche nella Pubblica Amministrazione. Abbiamo parlato infatti dell’esperienza di INPS, che ha rinnovato un servizio sviluppando in Agile e con un contratto del tipo “money for nothing, changes for free”: se nel tempo cambiano i requisiti, il cliente può chiedere di cambiare il prodotto, senza costi aggiuntivi (changes for free). Allo stesso modo, se lo sviluppatore raggiunge gli obiettivi prima del tempo, gli viene corrisposto l’intero compenso pattuito (money for nothing). La diffusione di questa mentalità è un ottimo segnale per il nostro Paese.

Come sempre in questi incontri, c’è stata una bella sinergia tra tutti i partecipanti, con interventi inattesi e di grande spessore. Noi di Agile Made in Italy continueremo a incontrarci regolarmente per sfatare altri miti, se anche tu hai in mente delle convinzioni errate su Agile e Scrum che vorresti approfondire, proponi il tuo mito! Scrivimi a m.passarella@agilemadeinitaly.com e capiremo insieme come inserirlo nei prossimi momenti di incontro. 

A presto con altri miti di Scrum!

 

Sfatiamo i miti di Scrum – #1

Sfatiamo altri miti di Scrum – #2

 

 

Di Anna Di Girolamo

————–

Qualche giorno fa ero in aula, con un gruppo di discenti particolarmente interattivo e ingaggiato, di quelli che ti fanno sentire proprio felice di fare questo lavoro.

Il tema era la motivazione e sono venute fuori delle osservazioni molto interessanti rispetto alla costruzione del team e a come ingaggiare i junior e i senior in una collaborazione maggiormente produttiva e stimolante; i presenti in aula – tutti senior – facevano notare che i junior, attualmente presenti in azienda, non pensano in alcun modo a votare la propria vita al lavoro e riportavano come le cose fossero profondamente cambiante rispetto a dieci-quindici anni fa.

Le osservazioni erano tutt’altro che negative, anzi i senior ammettevano, con molta onestà intellettuale, di avere molto da imparare dai loro colleghi più giovani rispetto al concetto di life-work balance e che avere una vita in sereno equilibrio ci rende non solo più felici ma anche più produttivi sul lavoro.

Finché non è stata messa sul tavolo una domanda: “Se pensiamo ai nostri ragazzi in senso lato, quindi ai nostri stageur in azienda, ai nostri studenti, ai nostri figli, siamo così sicuri che sia giusto non insegnare loro il senso del sacrificio? Sacrificarsi per ottenere qualcosa di più grande, di più importante, di più soddisfacente. Non dovremmo forse insegnare loro che il sacrificio è la strada per raggiungere obiettivi ambiziosi?”.

Credo che questa idea del sacrificio abbia molto a che fare con la cultura cattolica, ma lo dico da agnostica e quindi con un filtro all’ingresso piuttosto ingombrante, per cui lascio la considerazione sul tavolo come spunto di riflessioni future.

La domanda, a mio avviso, è sensatissima. E la risposta – netta – è NO. Non dobbiamo.

Il sacrificio è la cosa più anti-Agile che possiamo immaginare perché è la negazione della sostenibilità, e non serve un’Agile Transformation per capire che se insegniamo il valore del sacrificio stiamo implicitamente normalizzando la sopportazione di lavori che non ci piacciono, relazioni organizzative insoddisfacenti (quando non addirittura tossiche), nottate per consegnare i progetti in tempo ed e-mail a cui rispondiamo di domenica perché vedessi mai che il capo pensi che “c’ho ‘na vita”.

Pertanto, non dobbiamo in alcuno modo insegnare il senso del sacrificio: ne’ a casa, ne’ a scuola, ne’ tantomeno al lavoro.

Dobbiamo invece allenarci a sostituire la parola sacrificio con la parola impegno.

L’impegno implica attenzione, determinazione, dedizione, ostinazione persino. L’impegno, che prendo verso me stesso e nei confronti della mia squadra, è il carburante che alimenta l’autonomia diffusa e la responsabilità condivisa, è il patto di partnership che costruisco con il cliente, è la pienezza che conferisco alle mie giornate, in una logica di sostenibilità e appagamento sia nel lungo che nel breve periodo.

Impegnarsi è gratificante, è uno degli ingredienti del flow e nutre la motivazione intrinseca.

Non mi stancherò mai di raccontare l’importanza delle parole e del loro impatto sul nostro mindset. Per cambiare il modo di lavorare dobbiamo cambiare il modo di pensare e per cambiare il modo di pensare dobbiamo costruire un nuovo codice di comunicazione che ci aiuti a disegnare, nella testa prima e in azienda poi, uno scenario diverso.

Se volete team motivati, smettete di chiedere sacrifici per la causa e iniziate a dare loro motivazioni per impegnarsi nella costruzione di un progetto condiviso.

Di Anna Maria Pacileo

 

Ogni due anni il Project Management Institute (PMI) pubblica i risultati relativi allo stipendio medio dei Project Manager nel report Earning Power: Project Management Salary Survey. Siamo giunti alla dodicesima edizione e i dati di quest’ultima sono stati raccolti in 40 nazioni diverse da oltre 30.000 Project Manager, di cui 1.260 in Italia.

Incuriosita da questo report mi sono chiesta: ma quanto guadagna un Project Manager nel nostro Paese? Ho quindi estratto alcune informazioni a mio parere interessanti relativamente agli stipendi dei PM nazionali.

Prima scoperta, il compenso in questo settore dipende da una serie di fattori. Di seguito trovi alcune componenti dell’equazione retributiva:

 

Esperienza professionale

Ecco un estratto dei risultati relativi ai redditi in Italia riferiti agli anni di esperienza nel Project Management. In generale, più esperienza hai, più puoi aspettarti di guadagnare. Gli stipendi medi annui indicano un valore lordo, prima delle trattenute fiscali e sono riportati in Euro.

Certificazione

Un dato interessante estratto dal report è la differenza media di stipendio tra chi è certificato PMP® e chi non lo è: in Italia i partecipanti all’indagine certificati PMP® riferiscono di ricevere stipendi del 18% superiori in media rispetto ai Project Manager non certificati (16% è la percentuale calcolata sui 40 paesi intervistati).
Da notare che l’84% degli intervistati in Italia possiede una certificazione PMP®.
Ottenere una certificazione in questo campo, quindi, può aiutare a convalidare le tue capacità ed esperienze per i datori di lavoro. Questo può tradursi in uno stipendio più alto.

Fortunatamente non ci vuole molto prima che l’esperienza inizi a dare i suoi frutti in termini economici: Secondo il PMI, i Project Manager certificati con più di cinque anni di esperienza guadagnano uno stipendio base medio del 15% in più all’anno rispetto ai PM con esperienza inferiore.

Ruolo

Un’altra vista interessante è quella legata al ruolo: come era da aspettarsi, il range retributivo varia anche in base al livello di esperienza e di seniority nel ruolo che ricopri in ambito Project Management.

Industria

Il PM è una figura con competenze trasversali che possono trovare applicazione in molti settori. Ecco quanto guadagna un Project Manager italiano per settore, secondo il PMI.

Considerazioni finali

Lo stipendio di un Project Manager come avrai visto dipende da una serie di fattori, in questo articolo ne abbiamo evidenziati alcuni: l’esperienza professionale, il ruolo, le certificazioni, i settori industriali. Ma ci sono anche altri elementi che influiscono: le dimensioni della tua organizzazione, le dimensioni del team che gestisci, la complessità dei tuoi progetti in termini di budget. Tutti questi elementi possono influenzare il tuo reddito, così come il paese in cui decidi di lavorare. Ma quanto guadagnano i Project Manager nel mondo?
Secondo il PMI, i Project Manager guadagnano di più in Australia, Svizzera e Stati Uniti, con uno stipendio medio rispettivamente di $134.658, $133.605 e $108.000. Anche la Germania può essere una meta interessante con redditi medi annui di $107.000. All’opposto, i paesi in cui i Project Manager guadagnano meno sono Egitto, India e Cina, rispettivamente con $24.201, $27.052 e $27.156.

Se sei interessato a una esperienza all’estero oppure vuoi confrontare i dati italiani con quelli relativi ai 40 paesi intervistati dal PMI, ti invito a scaricare il report Earning Power: Project Management Salary Survey.

Buona lettura!

 

Di Marco Passarella

 

Da anni sentivo parlare di Agile, e mi aveva sempre incuriosito. Finalmente quest’anno, grazie a ContaminAction University, ho avuto la possibilità di conoscere da vicino questa metodologia di lavoro, frequentando il corso di Agile Made in Italy che mi ha preparato nel certificarmi come Scrum Master. Ho capito che Agile, prima che essere una metodologia è un modo di pensare. Più esploravo questo mindset insieme ad Alessandro Ingrosso, Riccardo Ciocci, Piero Mancino e Anna di Girolamo, più sentivo che molti dei concetti risuonavano profondamente dentro di me.

 

Dopo un po’ di tempo, in cui ho studiato, approfondito e riflettuto sui temi affrontati, mi sono fatto una mia idea sulle similitudini tra Agile e il Buddismo. Agile è figlio del pensiero Lean, e il pensiero Lean, che nasce in Giappone, ha un suo approccio culturale molto particolare, a volte difficile da capire per noi occidentali. Tuttavia il buddismo a cui faccio riferimento – il buddismo di Nichiren Daishonin, anch’esso sviluppato in Giappone – spiega con parole semplici il significato della vita e permette alle persone di diventare felici. È uno strumento molto potente per trasformare la propria vita e consente alle persone di esprimere il loro massimo potenziale per la creazione di valore per sé e per gli altri.

 

Educazione per la creazione di valore è l’espressione con cui Tsunesaburo Makiguchi (1871-1944) definisce la sua proposta per un “nuovo sistema educativo”. Educatore, scrittore e filosofo giapponese, maestro e preside di scuola elementare, intendeva riformare il sistema educativo giapponese della sua epoca che, secondo lui, scoraggiava il pensiero indipendente e soffocava la creatività e la felicità degli studenti. All’età di cinquantasette anni, Makiguchi incontrò il Buddismo di Nichiren Daishonin, trovando in esso una profonda visione della vita, perfettamente in accordo con la sua teoria della creazione di valore.

 

Secondo Makiguchi la felicità consiste nel creare valore. Individuare i valori e gli scopi verso cui orientiamo la nostra vita è un’azione di fondamentale importanza. Analogamente, Agile consente di definire le priorità e orientare esattamente tutti gli sforzi nella direzione in cui è possibile sviluppare il massimo valore per il cliente. Così come le persone trasformano la propria vita con il buddismo, anche le imprese trasformano il proprio business con Agile. Entrambe le discipline mettono al centro il cambiamento, esaltando il potere trasformativo insito nell’uomo e fornendo strumenti pratici per sostenere il miglioramento continuo. Nel 1930, insieme al suo giovane collega Josei Toda,fondò la Soka Kyoiku Gakkai: Società educativa per la creazione di valore. A poco a poco si trasformò in un’organizzazione che diffondeva gli insegnamenti del Buddismo del Daishonin.

 

Oggi la Soka Gakkai conta più di dieci milioni di fedeli in Giappone, è presente in 192 Paesi del mondo e in Italia vi aderiscono circa 70.000 persone, circa la metà dei buddisti italiani.

 

Così come le persone trasformano la propria vita con il buddismo, anche le imprese trasformano il proprio business con Agile. Entrambe le discipline mettono al centro il cambiamento, esaltando il potere trasformativo insito nell’uomo e fornendo strumenti pratici per sostenere il miglioramento continuo.

 

Nei prossimi articoli ti mostrerò altre analogie tra Agile e la filosofia umanistica buddista, non solo dal punto di vista dei valori, ma anche nelle pratiche.

 

“Chi possiede lo spirito di sfidarsi non conosce punti morti. Non è che camminiamo perché c’è la strada: in realtà poiché camminiamo, si costruisce la strada.” Daisaku Ikeda, Mappa della felicità, Esperia

Di Riccardo Ciocci

 

Cosa si intende per servant leadership?

“Una filosofia di leadership in cui l’obiettivo del leader è servire. Diversamente dalla leadership tradizionale in cui l’obiettivo principale del leader è la prosperità della propria azienda o organizzazione. Un leader servente condivide il potere, mette al primo posto le esigenze dei dipendenti e aiuta le persone a svilupparsi e ad ottenere prestazioni il più elevate possibile”.
Questa è la definizione di servant leadership data dalla pagina inglese di Wikipedia.
Appena si legge questa definizione il primo pensiero è “che bello sarebbe avere come capo una persona del genere”, il che rende la figura del servant leader simile a quella dello Yeti: tutti ne parlano, alcuni dicono di averlo visto, ma per la scienza non ci sono prove della sua esistenza.
E quindi la prima domanda che ci si pone è: il servant leader esiste?

 

Servant leader: un bisogno primordiale

Per rispondere a queste domande ci viene in aiuto un testo di Simon Sinek, scrittore, noto motivatore e consulente di marketing inglese: Leader at Least (Ultimo viene il leader) del 2014.
Il tema da cui partire è che il servant leader non è una scoperta, ma una riscoperta.
Sinek espone in maniera analitica quali sostanze producono piacere nella specie umana. Esse sono quattro, nell’ordine: endorfina, dopamina, serotonina e ossitocina.
Le prime due sostanze sono in comune con moltissimi altri esseri viventi e sono prodotte dai risultati che vengono raggiunti individualmente. Esse riguardano unicamente noi stessi e ci danno la forza di raggiungere degli obiettivi che ci prefiggiamo.
Le ultime due invece sono uniche della razza umana, si sono sviluppate insieme alla neocorteccia all’epoca degli homo sapiens e ci danno il piacere nello stare con gli altri. Ci danno la sensazione di essere gratificati dai complimenti dell’altro, e ci danno la soddisfazione di aver aiutato una persona cara.
Citando testualmente:
“L’ossitocina però non ha il solo scopo di farci sentire felici. È anche vitale per il nostro istinto di sopravvivenza. […] È grazie all’ossitocina se riusciamo a fidarci di un altro nel momento in cui costruiamo il nostro business, facciamo qualcosa di difficile, dobbiamo uscire da un momento di crisi. È grazie all’ossitocina se siamo sensibili ai rapporti umani e ci piace stare con quelli che amiamo. L’ossitocina fa di noi degli animali sociali.”
Queste parole ci danno la giusta dimensione di quanto lavorare in team con persone con cui abbiamo un rapporto di fiducia sia un bisogno insito nel genere umano. Spesso, infatti, chi lavora a contatto con il pubblico, una volta finito di lavorare preferisce passare del tempo in solitudine. Al contrario chi svolge un lavoro che manca di relazioni con altri, queste vengono ricercate fuori dall’ambiente lavorativo. È una questione di equilibrio tra le quattro sostanze.

 

Agile, Scrum e Servant leadership

Ci sono diverse realtà che cercano di seguire la rotta della leadership servente e Sinek ne illustra diverse che nel corso degli anni si sono distinte per questo nel panorama americano, ma possiamo fare un ulteriore passo avanti: l’apertura all’errore, la collaborazione, la condivisione delle conoscenze sono concetti molto familiari per tutte quelle aziende che stanno applicando l’Agile Manifesto e il Framework Scrum.
All’interno dello Scrum Team possiamo infatti rilevare la presenza dello Scrum Master, ovvero di un leader a servizio del team, che supporta la squadra senza acquisirne il comando lavorando sulla fiducia (del team e dell’organizzazione in generale), sulla gestione dei conflitti, sulla comunicazione, oltre che sulla diffusione della cultura Agile e del framework Scrum.
Non per questo dobbiamo essere indotti a pensare che un servant leader sia possibile solo attraverso i framework Agile.
Come detto tante aziende sono riuscite a creare un clima di fiducia reciproca anche senza l’utilizzo di Scrum.
Ma di sicuro ora possiamo dare una risposta alla nostra primissima domanda:
Sì, il servant leader esiste.

 

Creare il cerchio della sicurezza

Nel privato come nel lavoro c’è bisogno di instaurare dei rapporti autentici, relazionali e professionali; non si tratta di amicizia ma di ciò che Sinek definisce “cerchio della sicurezza”.
In un gruppo di gazzelle quando la prima gazzella avverte il pericolo di un leone che sta per attaccare e inizia a correre, tutto il branco inizia a scappare insieme a lei. Nessuna gazzella mette in dubbio il perché la prima ha iniziato a correre, ognuna sa che c’è un pericolo e si fida del comportamento della compagna.
In un “cerchio della sicurezza” le cose accadono allo stesso modo. Ogni elemento nel cerchio tutela se stesso e ogni altro membro del team, con la certezza che anche gli altri faranno altrettanto.
L’obiettivo è allargare il cerchio della sicurezza affinché non riguardi solo il team di lavoro ma possa includere l’organizzazione nella sua interezza.
Come fa il servant leader a lavorare al cerchio della sicurezza?

Mantenere il contatto con la realtà. Tenere unite le persone.
Per quanto possano essere utili e funzionali i contatti che manteniamo con chat o mail, niente può sostituire l’incontro faccia a faccia (sesto principio dell’Agile Manifesto).

Gestibilità. Obbedire al numero 150[1].
Ricordare che una persona non può mantenere dei rapporti basati solidi, basati sulla fiducia con più di centocinquanta persone. Il lavoro da remoto non aumenta questo numero[2].
Il top management se vuole che i dipendenti si sentano all’interno di cerchi della sicurezza nel proprio posto di lavoro, deve far in modo che il personale massimo in una sede non superi questo numero.

Incontrare le persone che si devono aiutare.
Incontrare personalmente i dipendenti o i membri del team contribuisce ad alimentare la motivazione.

Dare tempo e non solo soldi.
Un vero leader viene riconosciuto come tale quando è disposto a dedicare alla propria squadra l’unica risorsa che non può essere rigenerata: il tempo.
La riconoscenza e il senso di appartenenza di un membro rispetto al resto del team, sarà tanto maggiore quanto più tempo si sarà speso in tal senso.

Pazienza. La regola dei sette giorni e dei sette anni.
Quanto tempo ci vuole per creare il rapporto di fiducia tale da creare il “cerchio della sicurezza”?
Io non lo so, ma Sinek scrive che ci vogliono più di sette giorni, ma meno di sette anni.

La cultura aziendale gioca un ruolo determinante anche in termini di competitività e in un mondo sempre più complesso caratterizzato da veloci cambiamenti, chi di noi non vorrebbe un cerchio della sicurezza in cui lavorare?
Spazio quindi alle relazioni umane sane, solide e ben orientate: il leader che smette di guidare e si pone al servizio ha la grande opportunità di contribuire a costruire una nuova cultura organizzativa.

 

 

[1] Sinek riporta alla base la legge di Dunbar che riporta l’impossibilità dell’uomo di mantere più di 150 relazioni stabili. Citando testualmente: “Robin Dunbar, antropologo inglese e professore al Dipartimento di Psicologia sperimentale di Oxford […] ha dimostrato che una persona non è in grado di gestire più di centocinquanta relazioni dirette alla volta con I propri simili. ‘In altri termini’, come piace dire a lui, ‘si tratta del numero di persone con cui non vi sentireste imbarazzati a sedervi a bere qualcosa senza essere stati invitati se vi capitasse di incontrarle in un bar.”

 

[2] L’autore riporta le conclusioni di un esperimento fatto dal giornalista Rick Lax su wired.com nel marzo del 2012 raccontato in un articolo dal titolo: “Dunbar’s Number KIcked My Ass in Facebook Friends Experiment.”

Sinek scrive: “Molti hanno creduto che, con l’arrivo di Internet, il numero di Dunbar sarebbe diventato obsoleto. Che saremmo stati in grado di comunicare simultaneamente con tante persone e avremmo potuto gestire in modo efficace un numero superiori di relazioni. Ma I fatti dimostrano che non è così. La partita la vince di nuovo l’antropologia. Possiamo avere anche 800 amici su Facebook, ma è improbabile che li conosciamo tutti personalmente, così come è improbabile che tutti e ottocento ci conoscano personalmente. Se vi sedeste e provaste a contattarli uno per uno, come ha fatto Rick Lax, un giornalista di wired.com, vi accorgereste subito che il numero di Dunbar è sempre valido. Lax si è stupito nel constatare quanto fossero pochi, tra I suoi oltre duemila ‘amici’, quelli che effettivamente conosceva e che conoscevano lui.”

Di Riccardo Ciocci 

 

Nei precedenti articoli abbiamo sviscerato tutte le cause che hanno portato alla nascita delle retrospective a tema.

 

Tutto questo è nato dall’esigenza a primo impatto infantile, ma in realtà primordiale di divertirsi lavorando. Costruire le attività avendo quest’obiettivo comporta allo Scrum Master un effort maggiore. Infatti si tratta di un processo molto più complesso in quanto:

 

– astrarre le attività con una metafora può rendere meno chiare le consegne. Per questo bisogna avere l’accortezza di essere didascalici nello spiegare le attività durante la Retrospective;

 

– richiede conoscenza dei membri del team. Il tema deve essere comprensibile agli occhi dei partecipanti alla retro. Lo Scrum Master può essere autoreferenziale nella scelta degli argomenti, ma allo stesso tempo deve essere sicuro di rendere la metafora accessibile;

 

– rende l’attività difficilmente replicabile. Se un obiettivo è quello di avere delle attività pronte per essere riproposte in base agli eventi avvenuti in uno Sprint, le retro a tema complica sicuramente la vita.

 

Accogliendo questi effetti collaterali, le retro a tema sono delle opere uniche, sono il frutto di uno Scrum Master artigiano che dedica molto tempo alla cura del suo operato, piuttosto che alla sua riproducibilità in serie.

 

Di Sprint in Sprint le Retrospective a tema si stanno evolvendo, attraverso la sempre maggior conoscenza del team e all’utilizzo di nuovi strumenti.

Tutto questo per rendere l’evento stimolante e ludico senza perdere di vista il focus sull’obiettivo: incentivare il confronto.

Un confronto che oltre a essere efficace viene reso ricreativo e divertente.

 

Detto questo non mi rimane altro che concludere con un augurio, piuttosto che con un consiglio:

Buon lavoro e divertitevi!

 

Leggi gli articoli precedenti: 

 

Sprint Retrospective: le mie prime domande e risposte da Scrum Master

Sprint Retrospective: giocare per lavorare, la nascita delle board a tema

 

 

Di Alessandro Ingrosso

 

Tutti pazzi per Agile! L’interesse verso gli approcci Agile è ancora molto alto, sono molte in Italia le aziende che hanno avviato il processo di Agile Transformation. Ogni azienda ha scelto tra numerosi metodi, pratiche e strumenti Agile quello che ha ritenuto essere adatto ai propri bisogni e obiettivi. Alcune aziende hanno scelto un approccio top-down selezionando framework per la scalabilità di Agile e/o Scrum. Altre aziende hanno preferito un approccio bottom-up partendo da piccoli progetti di trasformazione per ottenere prove concrete di miglioramento. Altre aziende sono in balia delle scelte dei loro clienti, che talvolta chiedono approcci Agile e altre volte approcci predittivi o ibridi.

 

In questo scenario ancora in pieno fermento, tutti concordano che per avviare un percorso consapevole di Agile Transformation è necessario formarsi e acquisire delle certificazioni Agile. Sembra semplice, ma così non è, perché se stai leggendo questo articolo è proprio perché ti sei accorto che ci sono tanti enti di certificazione e tante certificazioni differenti, scegliere è veramente difficile ed è normale sentirsi confusi.

 

In questo articolo proverò ad aiutarti a prendere una decisione fornendoti maggiori dettagli e il mio punto di vista, quello di un professionista che ancora oggi quotidianamente si fa la stessa domanda: e ora, quale certificazione Agile scelgo?

 

Qualche anno fa ho fatto una ricognizione di tutti gli enti di certificazione Agile e su approcci Agile (es.: Scrum, Kanban, ecc.), vuoi sapere quanti sono? 10, sei sorpreso? E non credo siano tutti, di seguito il dettaglio:

  • Axelos
  • Exin
  • International Consortium for Agile
  • International Scrum Institute
  • Project Management Institute
  • Scrum.org
  • Scaled Agile Framework
  • Scrum Alliance
  • Scrum Inc
  • Scrum Study

 

Vuoi sapere complessivamente di quante certificazioni Agile stiamo parlando? 111 tipi di certificazioni (sicuramente ne ho dimenticata qualcuna). Un numero che personalmente reputo pazzesco, ma che è anche indice di quanto sia elevata la domanda del mercato in questo ambito.

 

Di fronte a questo scenario è normale porsi delle domande, a titolo esemplificativo e non esaustivo:

  • Con 111 certificazioni da dove si parte?
  • Quali criteri utilizzo per scegliere la certificazione che meglio si adatta al mio lavoro?
  • Quale certificazione mi consentirà di raggiungere i miei obiettivi?
  • Quale certificazione mi aprirà facilmente verso nuove opportunità di carriera e di lavoro?
  • Qual è la certificazione con il miglior rapporto costo/beneficio?
  • Qual è la certificazione che mi aiuta a crescere in azienda?

 

Non aspettarti che risponda puntualmente ad ogni singola domanda in modo predittivo.

Congratulazioni, sei appena entrato nel tuo percorso verso la mindfulness agile 🙂

 

Infatti, non c’è una soluzione uguale per tutti. Esiste la soluzione adatta a te, quella che funziona, ma l’unico modo che hai per scoprirla è sperimentare, ispezionare e adattare.

Personalmente ho un punto di vista molto forte sulla formazione e la preparazione alle certificazioni Agile, che potresti non condividere.

 

La formazione è l’acquisizione di nuove conoscenze, conoscenze che prima non avevi, e solo nel momento in cui le hai acquisite puoi decidere se si adattano alla tua persona e se liberano il potenziale che c’è in te. La formazione genera nuove opportunità, ti cambia la vita, ti migliora e accende nuove passioni motivandoti a cambiare. L’apice lo raggiungi quando vuoi raccontare ad amici e colleghi cosa hai imparato, che esistono modi di lavorare differenti e che vorresti sperimentare.

 

Questo è molto di più di una semplice certificazione, questo è l’inizio di un processo di miglioramento continuo di se stessi e di riflesso nelle persone che ci circondano.

Diversamente è solo un processo ripetitivo, dove il what vince sul why, che ci vede tutti diventare Scrum Master, Product Owner, o chissà cos’altro domani, perché ora è questa la certificazione che devi avere per vincere una gara.

Non fraintendermi, vincere le gare va benissimo, certificarsi va benissimo, ma al centro ci sei tu, una persona con ambizioni, motivazioni e sogni che vorresti realizzare in quel 1/3 della tua giornata per i prossimi 40 anni.

 

Se sei arrivato sin qui nella lettura del mio articolo, forse è perché senti che la certificazione è una cosa importante, non è una semplice pecetta. Sei curioso e affamato di conoscenza, e forse la tua prima certificazione Agile sarà solo l’inizio di un percorso che ti darà grandi soddisfazioni personali e professionali.

 

Spero che questa premessa ti abbia dato una prospettiva diversa nella tua ricerca della certificazione, le domande fondamentali a cui solo tu puoi rispondere sono:

  • Perché ti vuoi certificare?
  • Quale valore c’è per te nella certificazione?
  • Quale valore potrai generare nel tuo team o nel prossimo dove andrai a lavorare?
  • Quale valore potrai creare per la tua organizzazione?

 

Le certificazioni, specie quelle più conosciute e richieste, sono difficili da ottenere. Non è solo una questione di costo, che in alcuni casi è anche avvicinabile, ma solo una questione di tempo. Sì, il tempo, quello necessario a frequentare un corso, a studiare dopo le lezioni, a prepararsi per l’esame e a continuare a studiare per approfondire e diventare un professionista esperto della materia e con esperienza.

Già, non termina, tutto con la certificazione, spesso questa è solo l’inizio. Ad esempio, per diventare Master di Scrum, non basta solo la certificazione, è necessario esercitare il mindset, sperimentare, progettare gli incontri, leggere e continuare a farsi domande per migliorare. Non ci avevi pensato a questo, vero?

Ho visto tanti partecipanti iniziare corsi di certificazione per poi non certificarsi, proprio perché di fronte alle difficoltà nel bilanciare lavoro, famiglia e studio non ce l’hanno fatta.

 

Poi ovviamente esistono anche le certificazioni per questi casi, certificazioni che facilmente si riescono ad acquisire con le nozioni del percorso formativo e senza studio aggiuntivo. Tipicamente con soglie di superamento basse, domande semplici, tempi lunghi, open book.

Ma sono sicuro che se sei arrivato a leggere fin qui, tu ci tieni ad acquisire una certificazione di valore dimostrando a te stesso che padroneggi le conoscenze acquisite.

 

Ora sei pronto a scegliere il tuo percorso di formazione e crescita professionale, hai acquisito maggiore consapevolezza di te, dei tuoi obiettivi e delle tue aspirazioni.

 

Pubblicherò periodicamente un approfondimento per singolo ruolo Agile o per certificazioni.

Se vuoi restare aggiornato iscriviti alla newsletter qui sotto.

Torna la nostra rubrica con alcuni suggerimenti e trucchi per sostenere la preparazione e l’esame per la Certificazione PMP. Questa volta a darci alcuni consigli è Luca Fava, che, dopo aver seguito il nostro corso, ha superato con successo l’esame lo scorso 5 giugno 2022.

 

Quanto tempo hai studiato prima di sostenere l’esame per la Certificazione PMP?

Ho cominciato il corso a Novembre 2021 e sostenuto l’esame il 5 Giugno 2022

 

Come hai svolto la tua preparazione tra corso e studio personale?

Ho completato la preparazione del corso approfondendo le slide trattate durante le lezioni, esercitandomi con le domande di autoverifica e studiando il PMBOK

 

Quanto è importante frequentare il corso?

Lo considero molto utile perché rappresenta un’occasione di confronto che aiuta il candidato ad entrare nelle logiche del PMI attraverso il ragionamento ed i lavori di gruppo. Oltretutto è un’occasione di arricchimento per condividere esperienze e best practice con gli altri partecipanti.

 

Hai studiato individualmente o in gruppo?

Al di fuori del corso ho studiato individualmente

 

Come hai studiato sul PMBOK? Quali sezioni hai trovato più utili?

Ho letto il PMBOK sia nella versione 6 che la 7 e la Guida Agile provando a schematizzare le informazioni principali. La versione 6 è molto utile per avere una vista esaustiva dei processi delle varie Knowledge Area e degli elementi che li caratterizzano, mentre la versione 7 è più discorsiva e focalizzata sull’approccio.

 

Hai ampliato la preparazione con altre letture?

No.

 

Quanto è stato utile l’utilizzo del simulatore? Come funziona e quali sono le domande?

Indispensabile. Sia per evidenziare le aree che necessitano di ulteriori approfondimenti che per allenarsi rispetto alle tempistiche di esame.

 

Ti sei esercitato in qualche altro modo?

Con altri simulatori che ho trovato online.

 

Dopo quanto tempo, hai deciso di prenotare l’esame?

Ho prenotato l’esame ad Aprile.

 

Com’è andato l’esame e come si svolge? Hai avuto difficoltà con l’inglese?

Per chi come me lo svolge da remoto è importante non avere nulla sulla scrivania al di fuori dell’acqua e posizionarsi nell’ambiente più silenzioso possibile: anche un rumore esterno può generare interruzioni e richieste di verifica da parte degli addetti al controllo, che inevitabilmente comportano perdite di tempo. Dopo il check-in l’esame si compone di 3 blocchi di 60 domande al termine di ciascuno dei quali è possibile fare una pausa di max 10 min. (extra rispetto ai 230 min.). Prima della pausa puoi rivedere le 60 domande dopodiché non è più possibile. L’inglese mi è sembrato facilmente comprensibile ma può incidere sui tempi di risposta alle domande, quindi ho preferito svolgerlo in italiano per essere più rapido, limitando il check in lingua inglese ai casi veramente necessari.

 

Riassumendo, quali consigli indispensabili daresti a chi deve affrontare l’esame per la Certificazione PMP?

– Preparati al corso con Alessandro e Piero!

– Pianifica lo studio individuale prevedendo da subito dei check intermedi di autoverifica.

– Completato il programma fai challenge su contenuti e tempi di risposta con delle sessioni di simulazione, magari a lotti di domande di numerosità crescente, e rivedi le domande sbagliate per capire quali aree di conoscenza vanno migliorate.

– Never give up! A causa di diverse interruzioni durante i primi due slot di domande e di alcune risposte che hanno richiesto qualche ragionamento in più del previsto, mi sono ritrovato all’ultimo slot con soli 55 min. a disposizione (rispetto ai circa 76 min in media). Ho continuato ugualmente provando ad accelerare con l’obiettivo di non lasciare nessuna domanda senza risposta…risultato: Above the Target in tutti i domini.