Agile Archives - Pagina 15 di 24 - Product Owner per caso

9 Giugno 201628 Gennaio 2022

Ho ereditato un product backlog… e adesso?

Sarà capitato anche a voi.
Non sempre si ha la possibilità di partire con un progetto da 0, avendo davanti una tabula rasa.
Spesso nella nostra professione si subentra al lavoro di qualcun altro ereditando gioie e dolori di progetti già esistenti.
Se avete sperimentato questa situazione sapete di cosa parlo.
Mi è capitato già due volte di ereditare un backlog creato da altri e siccome sono certa di avere fatto errori entrambe le volte e che avrei potuto fare di meglio, penso sia giunto il momento di tirare le somme. Magari il post consentirà a voi di risparmiare tempo prezioso.

Diciamolo francamente: ereditare un product backlog realizzato da altri con user stories annesse e connesse è un po’ come per i programmatori dover mettere le mani sul codice altrui.
Difficilmente sarete entusiasti di ciò che troverete.
Non perché il vostro predecessore abbia fatto necessariamente un cattivo lavoro, semplicemente il vostro modo di formulare le user stories, di suddividere i temi o di organizzare il tutto secondo epiche è semplicemente “vostro”, ovvero personale.
E’ un po’ come riempire una lavastoviglie: ognuno lo fa a modo proprio!

Che fare in questi casi? Come procedere?
Vi condivido alcune idee, che – col senno di poi – si sono rivelate utili.

Delimitare i progetti

Partiamo da un livello “macro”. Prima di tutto è opportuno suddividere le storie in base ai progetti a cui appartengono.
Magari sarete fortunati e avrete un unico grande progetto su cui lavorare, il più delle volte tuttavia erediterete di tutto un po’.
Partite dalle basi e verificate che ogni progetto abbia un ambito chiaro e ben definito, in caso contrario dovete poter arrivare a delinearne i confini. Quindi cercate di associare ogni item a un progetto di riferimento.
Se qualcosa non torna è un indizio da seguire. Ha senso mantenere quella storia? E’ ancora valida o può essere considerata superata?

Individuare le epiche

Che siano presenti esplicitamente nel backlog o meno, lo step di individuare le epiche e formularle in maniera comprensibile a voi e al team vi aiuterà molto a chiarire le idee.
Se, ad esempio, state iniziando a lavorare su un dominio nuovo il lavoro sulle epiche sarà il primo passo per organizzare le nuove conoscenze.
Potreste non avere le idee chiare sui dettagli, ma a livello più alto vi sarete fatti una visione a 360 gradi del progetto.
Createle ex-novo o modificatele secondo le vostre necessità, ma non saltate questo passaggio. Sarà più utile di quanto pensiate anche nella comunicazione con i vari attori.
Ricordate che anche a questo livello potete effettuare dei tagli.

Distinguere le user stories da storie tecniche… o altre amenità

Su questo punto ci sarebbe da scrivere un romanzo intero!
Chiariamo qualche presupposto: un titolo non è una user story, una soluzione tecnica non è una user story, la lista della spesa sulle modifiche al layout non sono storie, un componente applicativo non è il soggetto di una user story… non vado oltre.
Ciò che intendo dire è che il vostro backlog dovrà contenere per la maggior parte delle vere user stories, pensate e formulate secondo i canoni. Controllate che sia effettivamente così.
Poi ovviamente saranno presenti anche altre cose, non ultime tutta una serie di attività tecniche. Ma è opportuno che queste siano ben distinte dalle altre, anche per verificarne il peso complessivo e poter creare il giusto mix funzionale-tecnico ad ogni sprint.
Anche le storie tecniche devono avere un perché: migliorare le performance, risolvere un bug, rendere più facili gli sviluppi futuri, garantire la stabilità della piattaforma. Se il team non è in grado di individuarne il valore da solo educateli gentilmente a questa pratica. E’ utile per tutti.

Scartare le storie che sono già soluzioni

Almeno alcuni di questi esemplari li troverete sicuramente nel backlog in eredità (sono pronta a scommettere!).
Evitatele come la peste.
Apparentemente vi hanno già risolto un problema indicando la soluzione da adottare, in realtà nascondono spesso scarsa chiarezza sui bisogni ai quali rispondono.
Se trovate user stories che sono già la soluzione al problema procedete al contrario. Risalite la corrente e andate a verificare le necessità dalle quali hanno avuto origine. Cercate chi può darvi queste risposte e se non trovate nessuno o non è possibile risalire al reale bisogno buttatele nel cestino.

Associare le user stories alle epiche

Adesso che avete definito le epiche dei vostri progetti e avete distinto gli aspetti tecnici da quelli funzionali non vi resta che associare ogni user story alla relativa epica.
Questo passaggio potrebbe portarvi anche a riformulare le epiche secondo un nuovo schema. Poco male, purché veicoli una maggiore comprensione.
Nel caso in cui qualche storia rimanga “orfana” provate a chiedervi se avete dimenticato qualche parte del progetto non censito dalle epiche o se – piuttosto – sia la storia a dover essere riconsiderata (in molti casi si rivelerà materiale di cui potete fare a meno).

Individuare le user stories di maggior valore

Siam sempre lì.
Il nostro lavoro è la celebrazione dal principio di Pareto.
Ricordate l’idea dell’80/20 applicato al backlog? E’ proprio ciò di cui sto parlando.
Per ogni epica che avete definito dovreste riuscire ad individuare le user stories fondamentali. Di certo non avranno tutte il medesimo valore.
Ordinatele secondo questo criterio e abbiate ben chiare quali sono quelle chiave. Le altre potrebbero rivelarsi superflue strada facendo.

Chiedere, chiedere, chiedere

Fate una marea di domande ai vostri stakeholder e interlocutori. Avete tutto il diritto di non capire ciò che è stato sintetizzato da altri quindi vincete il timore di passare per stupidi e – piuttosto – siatelo. Finché non capite cosa vi stanno chiedendo di portare a termine e perché, non sarete in grado di fare il bene il vostro lavoro. Quindi mettete da parte ogni remora e fatevi sotto!

Fare declutter

Alla fine di tutto questo lavoro avrete comunque la sensazione che ci sia del superfluo e di sicuro… avete ragione! Ogni occasione è buona per fare pulizia nel backlog, ma l’occasione della “prima volta” non vi ricapiterà più quindi non fatevela sfuggire.
Non temete di essere troppo radicali, buttate!
Mal che vada se si tratta di cose fondamentali le richieste torneranno ad emergere. Ma nella maggior parte dei casi ciò che pensate non sia importante non sarà più sollecitato da nessuno.
Vi consiglio solo di fare questa operazione nel momento in cui vi sentite relativamente confidenti sul dominio. Avete scelto di fare dei tagli, ma lo avete fatto consapevolmente.

Puntare all’essenziale

Questo punto è un rinforzo del paragrafo precedente. Anche se temete di eliminare qualcosa che “prima o poi viene buona”, resistete alla tentazione del “non si sa mai”.
State per iniziare un lungo viaggio. Viaggiate leggeri.
Portate con voi l’essenziale perché inevitabilmente il materiale crescerà lungo la strada del progetto.
Se invece siete così abili da avere ridotto il vostro backlog a non più di una trentina di item, vi prego contattatemi. Voglio intervistarvi e imparare i vostri trucchi!
Se al contrario vi sentite troppo timorosi per effettuare tagli sfidate voi stessi: cosa succederebbe se di tutte le storie contenute nel backlog ne cancellassimo un quarto, un terzo, la metà?

Tenere sotto controllo la dimensione

Quanti item contiene il backlog che avete davanti?
30? 50? 100? Oltre?
Questo numero può darvi delle indicazioni importanti.
Se il backlog contiene più di un centinaio di storie è difficilmente gestibile e già 100 sono un numero oneroso.
Provate a verificare se qualcosa può essere cancellato o, nel caso, accorpato. Inutile avere dettagli minuziosi su attività che verranno portate a termine tra mesi. Concentratevi su ciò che dovrà essere lavorato nell’arco dei prossimi 2-3 mesi; il resto può essere sintetizzato in epiche o temi.
Un grande backlog fa rallentare, defocalizza il team e offusca i progressi. Al contrario un backlog troppo minuto è l’indizio che o non avete lavorato bene sul futuro più prossimo o è ora di andare a fare quattro chiacchiere con i vostri stakeholder.

Verificare gli obiettivi

Provate a guardare il vostro backlog dal punto di vista degli obiettivi, non delle epiche.
Quello che vedete è un’immagine coerente ed equilibrata?
E’ allineata con la fase del ciclo di vita del prodotto?
Questa è la “prova del 9” del product backlog.
Ci possono essere delle fasi in cui si punta maggiormente alla monetizzazione o alla riduzione dei costi, ma ci sono tanti altri criteri oltre al soldo che definiscono un buon prodotto e un’azienda vincente (market share, usabilità, scalabilità, branding, innovazione tecnologica, ecc.).
Se la quasi totalità delle vostre user story punta alla generazione di ricavi e dimentica tutto il resto è la spia che il backlog debba essere attentamente riconsiderato.

28 Marzo 20164 Ottobre 2020

Il primo Product Owner della storia

In questi giorni sto leggendo il libro di Jeff Sutherland “Fare il doppio in metà tempo: Puntare al successo con il metodo Scrum“.
Il volume racconta in maniera discorsiva come attraverso varie esperienze personali e professionali Sutherland – il padre fondatore di Scrum insieme a Ken Schwaber – sia arrivato ad elaborare il famoso framework.

Non mancano aneddoti divertenti sui progetti più disparati salvati dall’adozione di Scrum (dai sistemi di antiterrorismo sviluppati dall’FBI, ai primi ATM, agli applicativi per la gestione delle ricette online, ma anche ristrutturazioni edilizie e matrimoni).

Una delle parti più interessanti per me è il racconto di come è nata la figura del Product Owner e come se l’è immaginata ai tempi l’autore.

Tutto sta a mettere in ordine di priorità il lavoro da fare.
Come si fa? Beh, per prima cosa vi serve qualcuno che sia in grado di capire contemporaneamente qual è la visione e dove sta il valore. In Scrum lo chiamiamo “Product Owner”.

Il Product Owner decide quale dev’essere il lavoro. Gestisce il Backlog, i compiti che include, e soprattutto l’ordine in cui vanno messi in atto.
Nel 1993, quando ho avviato il primo team Scrum, non avevo un Product Owner. Facevo parte del gruppo dirigente e avevo tante altre responsabilità oltre a quella di capire esattamente cosa doveva fare il team in ogni Sprint.
Mi occupavo del management e del marketing, trattavo con i clienti e definivo la strategia. Ma in quel primo Sprint ho capito che potevo anche gestire il Backlog. Dovevo solo fare in modo di avere abbastanza “storie” e abbastanza caratteristiche su cui mettere al lavoro il team nello Sprint successivo.
Il problema era che dopo il secondo Sprint abbiamo introdotto il Daily Stand-up. La velocità è aumentata del 400% nello Sprint successivo, e il team ha portato a termine in una settimana il lavoro che avevamo preventivato su un mese.
Non c’era un altro Backlog su cui metterlo al lavoro! Avevo pensato di avere davanti un mese per creare altre “storie”.
È un problema che vorrebbero tutti, bisogna ammetterlo, ma andava comunque affrontato. Quindi ho ideato il ruolo del Product Owner e ho cercato di capire che caratteristiche dovrebbe avere idealmente chi è chiamato a ricoprirlo.

Mi sono ispirato al Chief Engineer di Toyota …
… ciò che non hanno [ i Chief Engineer] è l’autorità.
Nessuno riporta a loro, semmai sono loro che riportano ai propri gruppi.
I collaboratori possono dire ai Chief Engineer che sbagliano, perciò costoro devono accertarsi di aver ragione.
Non valutano la performance di nessuno, e non concedono né promozioni né aumenti, ma decidono la visione della nuova vettura, e stabiliscono come verrà costruita, con la persuasione, e non con la coercizione.
È questa idea che volevo incorporare in Scrum.

Già agli albori di Scrum sapevo di aver bisogno di qualcuno che conoscesse molto bene il cliente.
Il Product Owner doveva essere in grado di riportare al team il feedback del cliente a ogni Sprint. Doveva dedicare metà del proprio tempo a parlare con le persone che acquistavano il prodotto (ascoltandone le opinioni sull’ultima release incrementale e su come creava valore), e l’altra metà a sviluppare il Backlog con il team (spiegando ai suoi membri cosa apprezzavano e cosa non apprezzavano i clienti).
Ricordatevi che il “cliente” potrebbe essere il consumatore in generale, una grande banca, vostro marito o chi ha bisogno del vaccino contro il rotavirus e dipende da voi per ottenerlo. Il cliente è chiunque tragga valore da ciò che fate.
Però non volevo un manager. Volevo qualcuno in cui il team credesse e di cui potesse fidarsi quando metteva in ordine di priorità il Backlog. Perciò sono andato a prendere il più bravo di tutti nel product marketing; attenzione, non nell’engineering, ma nel marketing. Ed è così che Don Rodner è diventato il primo Product Owner.
Conosceva il prodotto che stavamo sviluppando non da un punto di vista tecnico – pur sapendone abbastanza da poter comunicare con gli ingegneri – ma piuttosto dal punto di vista del cliente.
Di che cosa avevano bisogno coloro che usavano effettivamente il prodotto? Quando siete alla ricerca di un Product Owner, scegliete qualcuno che sia in grado di mettersi nei panni di chiunque tragga valore da ciò che fate.

15 Marzo 201628 Ottobre 2020

Caro Product Owner, di cosa sei realmente owner?

Avete presente la differenza tra un prodotto, una specifica funzionalità ed un componente di prodotto?
Questa distinzione – magari non immediata per tutti – è alla base della classificazione che Roman Pichler adotta per chiarire l’ambito di intervento del Product Owner.
Ancora oggi infatti c’è una certa confusione su questa figura perché si tratta di un ruolo complesso, sfaccettato e che può essere applicato in modo differente a seconda dei contesti organizzativi e della dimensione dell’azienda.

Ma partiamo dalle basi…
Di cosa si occupa il Product Owner?
Il Product Owner è colui che gestisce il prodotto per conto dell’organizzazione.
Avrà quindi due referenti principali: da una parte gli utenti o clienti, dall’altra l’azienda stessa che commercializza il prodotto.
Il prodotto è un mezzo per creare valore.
Qualcosa in grado di risolvere un problema o generare un beneficio per gli utilizzatori e i clienti, ma anche un asset tangibile dell’azienda in grado di generare revenue o stimolare la vendita di altri prodotti/servizi.

Secondo questa definizione è legittimo chiedersi se il Product Owner gestisca uno o più prodotti e se ciò che gestisce sia davvero un prodotto.
L’ambiguità è data dal fatto che spesso le funzionalità e i componenti – che sono parti del prodotto – vengano considerati essi stessi prodotti, pur non essendo in grado di generare valore da soli.

Analizziamo più nel dettaglio questi concetti.
Una funzionalità è un attributo del prodotto con cui l’utente può interagire.
Parliamo ad esempio di una funzione di ricerca e navigazione, del log-in o del check-out per effettuare un acquisto.
Tutti questi sono step dello user journey, non prodotti essi stessi.
Il valore per l’utente è dato dall’esperienza complessiva, non dalla singola funzionalità (avete mai sentito discorsi di questo genere? “Non sono riuscito ad acquistare il prodotto che volevo, ma sono rimasto soddisfatto del semplicissimo processo di registrazione”. Mai visto!).
Colui che gestisce singole funzionalità di prodotto è un Feature Owner.

D’altra parte un componente è un building block del prodotto, un elemento della sua architettura come ad esempio un database management system, un data access layer o la user interface stessa.
Anche in questo caso si tratta di una parte del prodotto (uno strato a ben vedere), non del prodotto nell’accezione di veicolo di valore.
Qui il concetto nella testa dell’utilizzatore finale si fa sempre più labile. Come è organizzato tecnicamente il prodotto non ha alcun importanza per il cliente (“Basta che funzioni!”).
Chi gestisce singoli elementi dell’architettura del prodotto è un Component Owner e di norma ha un background tecnico dato l’ambito specializzato di intervento.

Anche a livello della product ownership vera e propria è possibile fare una distinzione.
Un conto è gestire un prodotto a livello strategico, altra cosa è gestirne l’evoluzione day-by-day.
Pur essendo questi due livelli intercomunicanti, le skill e le competenze richieste sono profondamente diverse.
Pichler parla in questo caso di “Big Product Owner” e “Small Product Owner”.

Il Big Product Owner è responsabile sia della strategia sia della tattica, ma delega l’esecuzione della seconda ad altre figure.
E’ colui che elabora la vision di prodotto e ne definisce gli obiettivi. Deve sapere come il prodotto crea valore, chi sono i clienti, qual è la sua value proposition distintiva e come si differenzia rispetto ai competitor.
Il Big Product Owner definisce la roadmap di prodotto, gestisce gli stakeholders, interagisce con i customer e gli user, produce forecast e tiene traccia delle performance.

Lo Small Product Owner è responsabile di attività di tipo tattico.
Gestisce e prioritizza il backlog, scrive le user stories, si occupa del release planning, partecipa alle cerimonie Scrum e lavora a diretto contatto con il team di sviluppo e lo Scrum master avendo prevalentemente a che fare con i vincoli di prodotto (tempi, costi e ambito).

Ovviamente il tipo di Product Owner adottato in un determinato contesto è in stretta correlazione con l’organizzazione dei team di lavoro e la dimensione dell’azienda.
Se l’azienda adotta component team avremo dei Component Owner, se utilizza feature team potremo avere sia Feature Owner sia Product Owner.
La differenza tra Big e Small Product Owner può dipendere anche dalla dimensione dell’azienda: in start-up, realtà medio-piccole e aziende grandi dove sono stati adottati framework di scaling sono più facilmente presenti Big Product Owner (figure più vicine all’ambito del product management classico); in realtà di medie dimensioni dove sono presenti più prodotti o prodotti maturi la responsabilità è più spesso ripartita tra Small Product Owner, mentre il vero controllo del prodotto è tenuto dal management o da figure dedicate (es. Head of Product, Business Owner, ecc.).

E voi che tipo di Product Owner siete? Avete sperimentato questi diversi livelli di gestione? Avete preferenze a riguardo? Mi piacerebbe confrontarmi con chi ha esperienze di prima mano su questo tema.

Per approfondimenti sull’argomento trovate a questo indirizzo la registrazione del webinar di Roman Pichler sul ruolo del Product Owner che ha ispirato questo post.