Tag: product owner

Pubblicato il

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 I – Inspearit

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 Owner – Scrum 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.

Pubblicato il

La vera storia dietro a Super Mario

Ricordate il Product Management Day dello scorso novembre? Ne ho già parlato qui.
Ecco, oggi voglio segnalarvi quello che a mio avviso è stato il miglior intervento della giornata.

Si intitola “La vera storia dietro a Super Mario” ed è il talk di Lorenzo Cassulo, ex-collega, amico  e da sempre magnifico storyteller.

Lorenzo ci accompagna in una storia che parte dal lontano 1889 nel magazzino dell’azienda giapponese Nintendo. E’ un excursus nell’evoluzione del mercato dell’intrattenimento che passa dalle prime carte con disegni, ai giochi clandestini, fino ai primi cabinet da bar. 

Nel ‘79 il flop del gioco Radar Scope sul mercato americano mette Nintendo a rischio ma è proprio dalla difficoltà di avere magazzini pieni di videogiochi invenduti che nasce l’idea di utilizzare i cabinet già sdoganati, sostituire il gioco all’interno e cambiare gli adesivi esterni.

E’ in quell’occasione che nasce l’iconico personaggio di Super Mario per mano di Shigeru Miyamoto.
E’ il racconto di come opera un designer: reinventa i protagonisti di una saga, aggira i limiti tecnici del tempo attraverso la creatività, cambia lo scenario con un gioco multi livello, costruisce una storia in grado di fare la differenza tra il fallimento e un successo planetario, quello dei famosissimi Mario Bros.

Lorenzo ci parla di creatività, passione per il prodotto, ricerca di nuove opportunità e di soluzioni innovative, capacità di visione… tutte quelle caratteristiche che rendono i Product Owner veramente tali. 

“Le opportunità sono sempre intorno a noi, basta saperle vedere”

E’ con questa prospettiva che voglio iniziare il nuovo anno, con un talk che parla di prodotto attraverso i ricordi della nostra infanzia e adolescenza.
Godetevi questo grande affabulatore e guardatevi intorno… tante opportunità ci aspettano!

Pubblicato il

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?

Proudly powered by WordPress