Certificarsi Product Owner

Periodicamente ripropongo questo post che suscita sempre un certo interesse vedendo le statistiche. Nell’ormai lontano 2015 scrivevo così in tema di certificazione Product Owner…

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 aggiornate nel tempo 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 8 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

Ci sono 2 corsi online tenuti da Pierluigi Pugliese in lingua italiana a marzo e a luglio.
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 corsi remoti che consentono di acquisire la certificazione CSPO di Scrum Alliance. Il primo appuntamento è in programma per il 20 febbraio 2023 ma trovate anche un training a novembre.

Professional Scrum Product Owner PSPO IInspearit

Sessioni di giugno nel 2023 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).

Registered Product OwnerScrum Inc.

Il corso di certificazione per PO di Agile Education by Scrum Inc. è stato sviluppato direttamente dal co-creatore di Scrum, Jeff Sutherland. L’appuntamento è online dal 6 al 10 a marzo con un trainer veramente bravo (Paolo Sammicheli), tanti esempi pratici e tecniche provate per acquisire gli strumenti del mestiere.
Unico punto di attenzione: questa è una certificazione differente. Non ottenere l’attestato di CSPO bensì di Registered Product Owner (propria di Scrum Inc.).

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 posso dire che si è davvero realizzato quello scenario; Linkedin indicizza 7.700 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.

Il team player ideale

Oggi cambiamo topic, non parliamo di prodotto bensì di team e in particolare delle caratteristiche ideali di un team member.
Un amico mi ha segnalato questo libro – “Il team player ideale” di Patrick Lencioni – dicendomi che “gli ha aperto un mondo”.

E’ un Agile coach di grande esperienza e i suoi suggerimenti sono sempre preziosi per me quindi mi sono sparata la lettura in 2 giorni e vi condivido le principali riflessioni che mi sembrano interessanti.

Come scegliere il team player giusto?

Il libro parte da una domanda: le aziende che dicono di puntare sul lavoro di squadra come possono essere certe di selezionare e trattenere le persone giuste?

Jim Collins in “Good to Great” spiega quanto sia importante per le imprese di successo “imbarcare le persone giuste ”, ovvero assumere e poi trattenere in azienda dei dipendenti che sono allineati alla cultura aziendale, tenere nei posti chiave personaggi adatti alla cultura dell’azienda e far presidiare loro il processo di selezione dei nuovi candidati.

Ma quali caratteristiche definiscono esattamente un team player ideale?
Secondo Lencioni un vero team player è umile, appassionato e brillante. Vediamo cosa intende esattamente con queste qualità.

Le 3 qualità del team player ideale

Umiltà

L’umiltà è secondo l’autore il più importante e indispensabile attributo di un vero team player ma anche – sorprendentemente – l’aspetto più trascurato da così tanti manager che danno valore al lavoro di squadra.

Questa è la descrizione di umiltà che dà Lencioni:

“I team player migliori non hanno un ego ipertrofico e non danno importanza al proprio status. Sono rapidi nell’evidenziare i contributi degli altri e lenti nel sottolineare i propri. Condividono i meriti, elogiano la squadra molto più di se stessi e preferiscono parlare di successo collettivo anziché di successo individuale”.

Secondo l’autore ci sono due tipi di persone non umili che è bene individuare:

  • il tipo più ovvio è quello apertamente arrogante, totalmente concentrato su se stesso, che tende a vantarsi e ad assorbire tutta l’attenzione;
  • l’altro tipo sono le persone che mancano di fiducia in se stesse, pur essendo generose e positive nei confronti degli altri.

Questa seconda casistica mi ha spiazzato ma nella visione di Lencioni è chiaro perché si tratta di un problema: una persona che ha scarsa considerazione del suo valore nuoce gravemente ai team perché non sa sostenere le sue idee o non è in grado di attirare l’attenzione sui problemi che vede.

In sostanza l’insicurezza è sempre un problema nel lavoro in team sia che si vesta di presunzione sia nella svalutazione delle proprie capacità.

Passione

“Le persone appassionate non devono quasi mai essere spinte da un capo a lavorare più sodo, perché sono diligenti e trovano in sé la motivazione per svolgere i compiti loro affidati.”

La passione è la motivazione interna che spinge una persona a dare il massimo nel proprio lavoro perché questo è fonte di soddisfazione e di crescita.

Questa qualità più di tutte le altre può essere millantata durante i colloqui perché la maggior parte dei candidati sa come proiettare un’immagine di sé quale persona appassionata, tuttavia è una bugia con le gambe corte: è osservabile nel comportamento e spesso misurabile. Ecco perché nella vita lavorativa di tutti i giorni non si può fingere di essere appassionati quando questa motivazione interiore non c’è.

Qual è il risultato? Manager che finiscono per passare una quantità spropositata di tempo a cercare di motivare, punire o licenziare questo genere di collaboratori portati a bordo con poca attenzione.

Per evitare assunzioni di questo tipo Lencioni fornisce una serie di suggerimenti sul tipo di domande che potete utilizzare nei colloqui per “smascherare” finti appassionati.

Essere brillanti

Essere brillanti è – secondo l’autore – un concetto relativamente semplice e sensato, ma che viene spesso trascurato poiché molti dirigenti assumono personale guardando più alle competenze e alle abilità tecniche che alle cosiddette soft skills.

“L’essere brillanti significa semplicemente utilizzare il buon senso nelle relazioni con gli altri.”

Potremmo definire questa qualità come intelligenza sociale o intelligenza emotiva.

Quando una delle qualità manca

Il modello in oggetto prevede la compresenza delle 3 qualità “umile – appassionato – brillante” ma – parliamoci chiaro – sono poche le persone che incarnano la perfezione da questo punto di vista. La situazione più frequente che potete incontrare è una persona che non possiede tutte e 3 le caratteristiche allo stesso tempo o che ne presenta una sbilanciata rispetto alle altre.

Ecco cosa succede in questi casi:

  • Gli individui che sono umili e appassionati ma non brillanti sono spesso “involontariamente caotici”.
    La loro mancanza di comprensione del modo in cui le loro parole e azioni sono recepite dagli altri li portano senza volere a creare problemi nel team.
  • Chi è umile e brillante ma non sufficientemente appassionato viene classificato come “adorabile lavativo”.
    Non è alla ricerca di attenzione e lavora bene con i colleghi ma tende a fare solo ciò che è richiesto e niente più. Tuttavia dato che di solito sono positivi e amabili i responsabili tendono a trascurare i loro limiti.
  • Gli individui che sono appassionati e brillanti ma mancano di umiltà rientrano nella categoria degli “abili politici”.
    Sono persone intelligenti, ambiziose e disponibili a lavorare sodo, ma solo nella misura in cui ne possono trarre un beneficio personale. Purtroppo essendo brillanti sono in grado di presentarsi come collaboratori umili e può risultare difficile per i responsabili dei team notare i loro comportamenti distruttivi.

Selezione e feedback

Lencioni insiste sul fatto che se il lavoro di squadra è davvero un valore per l’azienda (e non semplicemente uno slogan su carta) è necessario mettere in atto un processo di selezione che vada ad indagare puntualmente i 3 aspetti del modello e non faccia sconti di sorta.

“In tanti cercheranno di ottenere il posto anche se non in sintonia con i valori dichiarati, ma pochi lo faranno sul serio quando comprenderanno che saranno ritenuti responsabili giorno dopo giorno dei loro comportamenti.”

Che fare però con le persone che sono già presenti in azienda?
In questo caso è opportuno fare un assessment interno ed intervenire laddove sono presenti situazione problematiche.

“Troppo spesso i manager sanno che una determinata persona non è in grado di far parte di un gruppo e che starebbe meglio altrove ma non agiscono per mancanza di coraggio e questo atteggiamento non è né saggio né virtuoso.”

Prendere il tempo per conoscere il proprio team in maniera approfondita è sempre un ottimo investimento; se poi doveste rilevare atteggiamenti non consoni potete fare leva sul feedback.

Il feedback è lo strumento più importante del processo di miglioramento e la parte che è più spesso mancante. ll manager in questo caso ha il dovere di “ricordare” in maniera costante al collaboratore che non sta ancora facendo ciò che serve all’organizzazione. Senza questo intervento non c’è alcun miglioramento.
Chi di voi non lo ha sperimentato? Vi ritrovate per l’ennesima volta a dover dire a una persona che non sta lavorando come dovrebbe o che il suo modo di interagire con i colleghi è inadeguato. Non potete credere di dover rifare ancora questa spiacevole conversazione…

Ebbene sì. È spiacevole e imbarazzante, ma Lencioni sottolinea come sia esattamente ciò che ci si aspetta da chi dirige un team o un’organizzazione perché l’assenza di feedback puntuali e immediati crea situazioni ingestibili.

Secondo l’autore de “Il team player ideale” chiarire i comportamenti che ci si attende dai collaboratori è persino più importante che porre obiettivi di performance.
Che dite? Siete d’accordo?

Chi scrive le user stories nel tuo Scrum team?

Se pensate che sia una domanda retorica ebbene non lo è!
E’ anzi un interrogativo su cui può essere utile mettere a confronto esperienze di vita diverse.
Questa riflessione nasce in seguito alla partecipazione ad un meetup di Pierluigi Pugliese intitolato “Stupidaggini che avete sentito su Scrum, Ep. 3: Le User Stories non si scrivono!”, organizzato all’interno del gruppo Milano Scrum/Agile User’s Group.

Il titolo – inutile dirlo – mi ha attirato ed ero sicura che potesse aggiungere spunti interessanti alle riflessioni su uno degli strumenti più utilizzati dai Product Owner.
Ma non parleremo soltanto di chi scrive le user stories, smonteremo anche alcune “leggende metropolitane” che derivano da cattive pratiche ed insegnamenti discutibili discussi durante l’incontro con l’Agile coach.

Inutile dire che molti di questi comportamenti errati li ho vissuti in prima persona e in alcuni casi so di esserne stata anche corresponsabile, quindi voglio fare la mia parte nel smantellarli insieme a voi.
Nella mia esperienza con diversi development team Scrum ho visto un po’ tutte le situazioni: dai team che non fanno partire lo sviluppo se non ci sono user stories super-dettagliate, al PO che si sobbarca l’intero onere della chiarificazione dei bisogni, ai team che che contribuiscono solo al livello degli acceptance criteria fino a quelli più navigati che sono in grado di scrivere storie end-2-end e spacchettarle a dovere.
Tutte queste situazioni – giuste e sbagliate – sono dei pattern ed è utile sapere come affrontarle.

Ma partiamo dalla prima di queste male pratiche…

Il minimalismo delle user stories

Le storie sono:

  • il valore di business che vogliamo generare per l’utente
  • una promessa di conversazioni
  • riassumono l’aspettativa di business
  • descrivono l’attività da fare
  • sono un elemento di pianificazione
  • non si scrivono

Vi ritrovate in queste affermazioni?
C’è forse qualcosa che vi stona?
Davvero le user stories non si scrivono? Cosa intende dire Pugliese?

Pierluigi con questa affermazione provocatoria vuole ribadire che le user stories non sono semplicemente un modo un po’ diverso di esprimere i requisiti, un altro tipo di formato, bensì piuttosto un modo minimalista per descrivere le funzionalità e di semplificare la parte burocratica.

Questo approccio minimalista funziona a patto che la conversazione tra stakeholder, sviluppatori e Product Owner avvenga davvero.
La scrittura è secondaria; la card riassume la conversazione e non ne contiene tutti i dettagli, solo ciò che serve al team per ricordarsi cosa deve fare.

Capite bene che questo approccio definito lightweight dagli agilisti (= leggero) sta in piedi se e solo se una reale interazione avviene.
Se non c’è un momento di confronto e di approfondimento qualsiasi user story sarà monca, una promessa (di conversazione) non avvenuta.
E a quel punto nascerà inevitabilmente la richiesta di una maggiore documentazione.
Infatti una cosa che mi è spesso capitato di notare è che quando i team sono meno maturi tendono a utilizzare le storie come copertine di Linus e chiedono al Product Owner di specificare e dettagliare molto di più.

Quando ravviso questo comportamento so che è il momento di alzare le orecchie.
Può essere un indicatore rilevante del fatto che:

  • il chiarimento non è ancora avvenuto (la card non serve a eludere la conversazione)
  • Il vero valore dello strumento user stories non è stato compreso (siamo di fronte a una trasposizione dei vecchi documenti di requisiti)
  • il team demanda in toto la chiarificazione al PO (di questo aspetto ne parliamo più in là…)
  • c’è scarsa fiducia tra gli interlocutori (questo – se vero – è l’aspetto più problematico che richiede attenzione immediata).

Le parole di Pugliese per me sono sempre illuminanti…

Senza la conversazione le user stories non hanno senso. Non sono una religione alternativa per scrivere i requisiti! Se usate in maniera stupida, meccanica, inutile e dannosa fanno spegnere il cervello agli sviluppatori

Chi fa la business analysis?

Chi è l’owner della business analysis? La domanda sembrerebbe retorica… in fondo esiste una figura professionale proprio per questo, tuttavia negli Scrum team come sapete non ci sono singoli “detentori” di attività.
E’ un punto importante spesso poco capito. Nel team ideale tutti fanno tutto, o meglio sono in grado di fare tutto. Nella realtà spesso non è così perché le competenze e le seniority sono diverse, ma pratiche come il peer programming e le pair review ci vengono in aiuto facendo sì che la conoscenza di tutto il team aumenti progressivamente con il tempo.

La stessa cosa vale per l’analisi dei requisiti.
Magari date per scontato che il momento della chiarificazione dei bisogni sia appannaggio del Product Owner e del business analyst (se avete la fortuna di averlo) ma non è così!

“Voglio che il team faccia business analysis” – ha insistito il coach durante il meetup – “Più persone possibili devono saper fare le domande giuste e ovviamente devono avere competenze di dominio sufficienti per fare le domande giuste”.

Ma a cosa punta questo approccio? La finalità è avere una responsabilità condivisa dell’intero Scrum team sul risultato finale. L’analisi è una premessa fondamentale per fare la modellazione di un sistema attraverso le user stories.
Per questo motivo secondo Pugliese è un’attività che può essere portata avanti direttamente dal team con gli stakeholder senza necessariamente la presenza del Product Owner (ricordate quando si diceva di “smettere di fare il piccione viaggiatore”?)

Il vero ruolo del Product Owner

Ma se il product owner non scrive le storie e non fa chiarificazione – ha chiesto un partecipante – qual è esattamente il suo ruolo?
Esattamente quello che prescrive la Scrum Guide: essere il responsabile di massimizzare il valore prodotto.

Il PO non fa chiarificazione, può partecipare a questa attività ma non è il suo focus primario. Il product owner regola il sistema dal punto di vista delle priorità; decide cosa fare del backlog (se una storia entra, non entra e con quale priorità). In questo modo fa strategia di prodotto.
Impiegarlo solo per spiegare o scrivere le user stories è di fatto svilire questa figura a un lavoro di segretariato, quando invece il suo vero scopo è capire cosa c’è di valore e come massimizzarlo.

Non possiamo pensare che gli stakeholder si mettano d’accordo sulle priorità perché hanno solitamente interessi troppo diversi. Il team può chiarire autonomamente cosa vuole ottenere lo stakeholder, ma poi è con il PO che ci si confronta sulle priorità.
Non è compito degli sviluppatori, dei designer o degli analisti decidere cosa è più importante e cosa no.

Detto questo vi chiedo: nella vostra esperienza quanta parte del lavoro del PO è focalizzato sulla massimizzazione del valore e quanto sulla scrittura e la chiarificazione? Adesso che sapete qual è l’approccio più produttivo ed efficace avete voglia di condividerlo con i vostri team?