Certificarsi Product Owner

Periodicamente ripropongo questo post che suscita sempre un certo interesse vedendo le statistiche. Nell’ormai lontano 2015 scrivevo così…

Di ritorno da una 2 giorni londinese con Roman Pichler ho deciso di scrivere un post per tutti coloro che stanno meditando sul tema certificazione Scrum Product Owner.
A ruota libera seguono alcune informazioni pratiche e qualche consiglio di prima mano.

Quando fare la certificazione

Nel mio caso il corso di certificazione arriva dopo qualche anno che svolgo il ruolo di Product Owner.
Non sarò imparziale ma ritengo che per trarre il massimo da questo corso sia utile affrontarlo dopo aver svolto un po’ di esperienza sul campo ed aver toccato con mano quali possono essere i problemi più comuni nell’adozione di Scrum e nelle transizioni agili.

Durante il corso della durata di 2 giorni vengono trattati tutti gli argomenti relativi alla product ownership:

Oltre ad approfondire la teoria vengono chiariti dubbi tramite esempi ed esercitazioni in aula. E’ un’ottima occasione per mettere alla prova le vostre conoscenze e portare esempi di prima mano. Fate domande e confrontatevi con i vostri colleghi di corso. Solo così sfrutterete al massimo il corso (quando mai vi capita di ritrovarvi con decine di Product Owner a portata di mano?).

Dove trovare un corso valido

Ai tempi della mia certificazione la logistica non arrideva certo a noi italiani.
Sino al 2013 era quasi impossibile trovare un corso da Product Owner nel nostro paese, a differenza di quelli per Scrum Master per i quali c’era già maggiore offerta. Questo è il motivo per cui 5 anni fa ho scelto Londra per ottenere l’attestato di CSPO.

Fortunatamente oggigiorno il panorama è cambiato e la scelta è molto più ampia.
Online trovate pagine e pagine di annunci sui corsi di certificazione; ce ne sono così tanti che è davvero difficile orientarsi per chi è alle prime armi.
Quindi se nel post originario elencavo le poche alternative presenti, adesso mi permetto di suggerirvi le società che conosco personalmente, che hanno maggiore esperienza sul campo e sono veramente attive nella community Agile italiana (aka sanno perfettamente di ciò che parlano).
Ecco qui di seguito in ordine sparso i corsi che offrono.

Certified Scrum Product Owner®Connexxo

C’è un corso online in inglese tenuto da Pierluigi Pugliese verso la fine di gennaio e uno in lingua italiana all’inizio di febbraio. Di fatto trovate un corso di certificazione ogni mese quindi vi consiglio di tenere d’occhio il calendario.
Pierluigi è un trainer di grande esperienza che, oltre alle conoscenze teoriche, può trasmettervi consigli e suggerimenti per il lavoro sul campo.

Certified Scrum Product Owner®Agile42

Anche in questo caso parliamo di un corso remoto che consente di acquisire la certificazione CSPO di Scrum Alliance. I coach di agile42 che lo tengono sono Giuseppe De Simone e Roberto Bettazzoni. Il primo appuntamento è in programma per il 17 febbraio 2021 ma trovate anche date successive.

Professional Scrum Product Owner PSPO IInspearit

Tre date disponibili nel 2021 per la certificazione rilasciata da Scrum.org.
La formazione prevede molti workshop pratici e giochi per facilitare l’apprendimento dei concetti e per stimolare a proseguire con l’allenamento delle abilità dopo il corso.

Agile Reloaded

Agile Reloaded è una realtà tutta italiana che aiuta aziende, enti e organizzazioni ad applicare la metodologia agile per migliorare i processi, la collaborazione e il time to market. E’ un team di coach di tutto rispetto e anche se il sito non riporta in questo momento un elenco di corsi a catalogo vi consiglio di contattarli perché sanno la loro sul tema Product Ownership.

Sembra che nel nuovo anno tutta la formazione rimanga online per ora e – date le difficoltà attuali – va bene così.
Tuttavia quando la situazione tornerà normale considerate la possibilità di optare per i corsi in presenza perché ritengo parte fondamentale di questo tipo di training i role playing che avvengono in aula con il docente e con gli altri partecipanti (si possono fare anche con il supporto di tanti tool online, ma non è la stessa cosa).

Quanto costa certificarsi Product Owner

Una cosa è certa: non è regalato!
Se pianificate il corso con un certo anticipo e non avete particolare fretta di ottenere la certificazione potrete beneficiare di una tariffa scontata (la cosiddetta “early bird”) pari a ca. 1.000- 1.100 euro + IVA.
Il prezzo pieno più basso che ho visto parte dai 1.035 euro + IVA per corsi tenuti in Italia, la media è intorno ai 1.300 euro + IVA; più cari invece i corsi disponibili nel resto d’Europa (si va da 1.500 a oltre 2.300 euro).

In ogni caso non si tratta di una cifra banale, motivo per cui vi consiglio di tenere d’occhio con largo anticipo il calendario dei corsi e – se possibile – provare a proporre in prima persona questo percorso di formazione alle risorse umane. Chissà mai che ve lo accordino o lo prendano in considerazione come parte di un intervento più ampio di digital transformation … ;-)

Se invece dovete risparmiare a tutti i costi ma non volete rinunciare ad un attestato riconosciuto sappiate che i corsi online in modalità self-study hanno prezzi decisamente più contenuti (parliamo di circa 350 euro + IVA). E’ un’opzione anche questa, ma non mi sento di caldeggiarla.

Quale trainer scegliere

In tempi normali alcuni formatori sono inaccessibili per via della logistica ma dovendo andare online in ogni caso se non avete problemi con la lingua inglese scegliete tra i top di gamma.
Tenete presente in ogni caso che i trainer accreditati presso le maggiori organizzazioni che promuovono Scrum nel mondo offrono garanzie di professionalità e grande esperienza.

Se avete possibilità di scelta vi suggerisco di selezionare un  coach che non sia solo un esperto di metodologie agili e Scrum, ma che abbia una specifica esperienza sul campo come Product Owner. Sul sito di Scrum Alliance e Scrum.org, ad esempio, potete scegliere tra un numero elevato di trainer alcuni dei quali sono dei guru indiscussi della product ownership.

I motivi per certificarsi

Ho scelto di certificarmi perché mi piace portare a compimento quello che faccio e allo stesso tempo mettere in discussione le mie conoscenze.
Ho avuto la fortuna di accedere al corso a spese della mia azienda, ma sono stata io stessa a proporlo al mio responsabile come un importante gradino di crescita nel mio percorso professionale.
Ho avuto l’opportunità e l’ho presa, ma avrei sostenuto il corso a mie spese?

Sono realista: quando mi sono certificata in Italia la professione di Product Owner non era ancora così affermata.
Diverse aziende che cominciavano ad avvicinarsi alle metodologie agili decidevano di investire sulla figura dello Scrum Master ma non sentivano l’esigenza di assumere o far crescere un PO.

Dal post originale del 2015…
E’ questione di tempo. Mano a mano che lo sviluppo software adotterà sempre più pratiche agili anche le figure professionali legate a questa metodologia saranno più richieste.
A quel punto avere in mano una certificazione che è una rarità in Italia vi darà il vantaggio dei first mover!

Oggi alla fine del 2020 posso dire che si è davvero realizzato quello scenario; Linkedin indicizza 22.000 Product Owner in Italia.
Le aziende hanno compreso l’importanza di questo ruolo e cercano persone preparate che le aiutino nelle tante sfide digitali presenti e future.
Sono sempre di più le persone che si certificano, in alcuni casi senza neanche avere esperienza sul campo. A tutte loro auguro di incontrare favolosi mentor com’è stato per me e di non smettere mai di crescere nelle competenze della product ownership.

IAD 2019: la mia intervista con AgileForItaly

In occasione degli Italian Agile Days che si sono tenuti a Modena l’8 e il 9 Novembre 2019 ho avuto il piacere di fare quattro chiacchiere sul tema Impact Mapping con gli amici di AgileForItaly.

Li conosco da tempo e ammiro il gran lavoro che Tiziano, Pierpaolo e Davide  stanno facendo per diffondere in modo chiaro e divertente le tematiche Agili in Italia.
Ci accomuna la medesima passione e la voglia di non prenderci troppo sul serio ;)

Nell’intervista parliamo di temi che ho già avuto modo di approfondire in altri post:

Qui in particolare ci siamo soffermati su come applicare l’Impact Map ai progetti growth, come produrla in modo collaborativo all’interno del team di lavoro, come darne visibilità in azienda e ogni quanto aggiornarla. Ho aggiunto anche qualche trucchetto su come partire da 0.

Ecco qui l’audio.
Buon ascolto!

E se ancora non lo conoscete vi consiglio di dare quanto prima un occhio al sito di AgileForItaly. Troverete tante risorse interessanti.

LeSS (Large-Scale Scrum): 15 domande a Craig Larman

Craig_Larman

Questa settimana ho partecipato ad un Meetup con Craig Larman, uno dei pionieri nell’applicazione di Scrum in contesti allargati.
Larman era a Milano dal 4 al 6 Luglio per il suo corso di Certified LeSS Practitioner.
Durante l’incontro i partecipanti hanno avuto l’occasione di approfondire dubbi e questioni direttamente con l’autore di “Scaling Lean & Agile Development“.
Questa è una sintesi delle domande emerse nel corso della serata.

Cosa significa essere agili?

Significa essere flessibili, adattarsi al cambiamento.
Non a caso quando queste pratiche sono nate erano due le parole in lizza per descrivere il framework: agile e adaptive ed entrambe sottolineano questo concetto.
Diciamo infatti “essere agili” piuttosto che “fare Agile”.
Essere agili significa mettere da parte l’arroganza di conoscere e abbracciare l’umiltà dell’imparare.

Quali sono gli elementi caratteristici di LeSS?

LeSS prevede 3 ruoli: il Product Owner, responsabile di massimizzare il valore prodotto; da 2 a 8 team che hanno il compito di realizzare l’incremento di prodotto potenzialmente rilasciabile e gli Scrum Master ad agevolare il processo (di norma 1 Scrum Master ogni 3 team).
In LeSS esiste un unico Product Backlog per il prodotto.
Per quanto riguarda gli Sprint Backlog invece ogni Team ha il proprio che viene stabilito nel corso dello Sprint Planning.
LeSS prevede gli stessi eventi di Scrum, ma li declina diversamente per la presenza di più team.

Quanti sono i framework LeSS?

Large-Scale Scrum prevede 2 framework: LeSS e LeSS Huge
Il primo si applica a situazioni in cui è presente un Product Owner, 1 product backlog e da 2 a 8 team di sviluppo che lavorano sul medesimo prodotto.
LeSS Huge si applica in contesti ancora più ampi, dove un singolo Product Owner avrebbe difficoltà ad avere una visione complessiva dell’intero prodotto.

Ci sono delle pre-condizioni per adottare LeSS?

LeSS non è un framework che si presta ad essere adottato bottom-up; deve essere introdotto dall’alto, al senior level.
Necessita la presenza di un management evoluto perché richiede un profondo cambiamento del sistema. Stiamo parlando di eliminare tutti i component team, così come i progetti e i programmi.

Può essere utilizzato in realtà multi-site?

LeSS è stato implementato in molte realtà con persone che lavorano su diverse sedi.
Ma c’è un vincolo: all’interno di un singolo team le persone devono essere co-locate, non disperse. I diversi team possono invece essere sparsi su più sedi geografiche.

Come posso convincere il management ad adottare LeSS?

Non puoi convincerli. Non funziona la dinamica di convinzione.
Sono loro che devono arrivare a sentire davvero l’urgenza del cambiamento, perché le dinamiche di resistenza al cambiamento sono molto forti nelle organizzazioni.
L’idea di fondo è che le persone debbano arrivare a fare propria un’idea (own), invece che accoglierla da altri (rent).
Nel momento in cui la convinzione è una dinamica interna solo allora si crea davvero la possibilità per un cambio radicale.
Molte aziende hanno troppi soldi” dice Larman, quindi si possono permettere tante modalità disfunzionali e non hanno questo senso di urgenza. Mettono in atto solo “fake changes”.

Non c’è proprio nulla che posso fare per agevolare questo cambiamento?

Ciò che si può fare è cominciare a creare interesse e curiosità intorno a questo argomento.
Le possibilità sono tante: far circolare dei libri che trattano di LeSS presso persone chiave in azienda, inviare video, trovare degli sponsor interni all’organizzazione, crearsi degli alleati in questo percorso, promuovere eventi e incontri con esperti esterni all’azienda.

Come avviene lo Sprint Planning?

Lo sprint planning è diviso in due parti.

Nella prima parte sono presenti il PO ed i rappresentanti dei diversi team (è bene che ruotino da un planning all’altro).
Questa prima parte dura massimo 2 ore per uno sprint di 2 settimane, ma spesso si conclude in meno di un’ora.
In questa fase il PO presenta le user stories in ordine di priorità, viene definito lo Sprint Goal ed i rappresentanti dei team selezionano le attività sulle quali lavoreranno.

Nella seconda parte sono di fatto i team ad organizzarsi e più tavoli di discussione possono essere portati avanti in parallelo. In questo momento ogni team elabora il proprio piano per produrre l’incremento di prodotto. Il PO può chiarire eventuali dubbi in questo momento.

Come vengono assegnate le user stories ai vari team?

Le user stories non vengono “assegnate”.
In Scrum trattiamo le persone come adulti.
Sono i team ad auto-organizzarsi e a scegliere le storie da realizzare per poter produrre un incremento.

Che cosa si intende per integrazione continua?

Non parlo tanto di continuous integration ma di integrate continuously.
L’integrazione continua non è una questione di strumenti e tool, riguarda il comportamento e la forma mentis degli sviluppatori.

Si basa su 3 pratiche:

  • effettuare check in e check out del codice con cicli il più corti possibile (stiamo parlando di qualche minuto!);
  • evitare l’utilizzo di branches (tutti i team lavorano sul master);
  • utilizzare un sistema di continuous integration sempre attivo e dove i test girano continuamente.

Come è opportuno procedere quando non si hanno le idee chiare su quale architettura adottare?

In questi casi è bene utilizzare un processo di Agile Modeling in cui i diversi team si trovano assieme ed elaborano idee al fine di individuare la migliore soluzione al problema.
Vengono fatti sketches dell’architettura. Si tratta di prendere decisioni partecipate.

In fase di implementazione tuttavia solo uno dei team parte ad abbozzare la soluzione condivisa (è una questione di focus). Può così verificare se si tratta di un’idea valida o se è necessario apportare delle correzioni piuttosto che riconsiderare il tutto.

Le emerging architecture non funzionano bene in contesti large scale.

Ma in pratica per iniziare ad adottare LeSS come è bene partire?

All’inizio è bene evitare di avere un gruppo troppo piccolo (ad esempio 2 soli team) o troppo numeroso. Nel primo caso il test non è rappresentativo, nel secondo il livello di difficoltà è eccessivo.

Partite con questo set:

  • 50 persone circa
  • 1 solo prodotto
  • 1 unica sede
  • per un periodo di 6 mesi

E’ fondamentale costruire un’esperienza di successo, perché il codice funzionante è molto più convincente di qualsiasi power point. In questo modo (e solo in questo) si guadagna credibilità all’interno dell’organizzazione.

Come sono organizzati i team in relazione ai prodotti?

Da questo punto di vista LeSS è perfettamente in linea con Scrum.
Scrum è un modello product-centric.
I team devono essere disaccoppiati dal codice ma in relazione stabile con i prodotti.
Più team lavorano sempre su un determinato prodotto.
Quando l’organizzazione non è strutturata in questo modo non sto adottando un framework Agile, sto semplicemente tentando di migliorare l’efficienza nella gestione dei progetti.

Qual è il ruolo del Product Owner in LeSS?

Il ruolo del Product Owner in LeSS non cambia rispetto a Scrum e ai contesti non scalati.
Il PO è colui che gestisce il prodotto soddisfando i bisogni degli utenti finali, colui che comunica al team gli obiettivi e la vision di alto livello.
Il PO non è un Business Analyst; è un imprenditore, un innovatore, un pensatore a livello sistemico, di fatto un “mini CEO”.
In LeSS è previsto che un Product Owner possa gestire sino a 8 team (con il supporto di alcuni Scrum Master), per un totale di oltre 50 sviluppatori. Questo significa necessariamente adottare un modello di product ownership “diffusa”, dove i membri del team hanno un’elevata conoscenza del dominio e grande maturità professionale.

Quanto è grande un prodotto in LeSS?

La grandezza del prodotto dipende da diversi fattori: il numero di prodotti che un’azienda gestisce e la loro ampiezza.
Per intenderci Microsoft Word è un prodotto, un prodotto ancora più grande è MS Office.
Ad ogni prodotto corrisponde un product backlog e diversi team lavorano continuativamente sul medesimo prodotto.
Più l’azienda segmenta il prodotto e maggiore è la possibilità che diminuisca il valore delle singole user stories lavorate. Sta ottimizzando “localmente”, ma non a livello sistemico.
Per produrre maggior valore è bene avere prodotti di ampio respiro, più grandi e non più piccoli.