“Penso che il Product Owner sia la cosa peggiore che scrum abbia introdotto nel mondo del software. Veramente una pessima idea” secondo Mary Poppendieck.
Non è l’unica a puntare il dito sulla figura del Product Owner, come si può evincere dai numerosi articoli pubblicati:
- Product Owners Suck
- Product Owner Why Your Scrum Doesn't Work
- Problems With Your Product Owner
- The Danger of a Proxy Product Owner
- Do We Really Need a Product Owner?
Vediamo perché.
Inizia ora il tuo primo video corso Agile gratuito
Chi é e che cosa fa il Product Owner
Il Product Owner è un ruolo specifico che è stato introdotto dalla metodologia Scrum per fare da interfaccia tra il team di sviluppatori e il cliente. A differenza del Project Manager il PO non interviene nelle decisioni del team sia a livello tecnico che nella suddivisione dei compiti da fare durante lo Sprint, il periodo di congelamento in cui il team porta avanti il lavoro deciso senza interruzioni da parte di figure esterne. Tecnicamente Scrum prescrive che il PO può fermare lo Sprint solo nel caso in cui il lavoro sia inutile o perché il cliente ha cambiato idea o perché non serve più portare avanti le user stories inserite nello Sprint Backlog. In The Scrum Handbook il ruolo del Product Owner viene descritto in questo modo: “Il Product Owner ha la responsabilità di massimizzare il valore del prodotto risultante dal lavoro svolto dal Team di Sviluppo. Come questo è fatto può variare di molto secondo l’organizzazione, gli Scrum Team e gli individui.
Il Product Owner è l'unica persona responsabile della gestione del Product Backlog”.
Di fatto, come afferma Poppendieck, “il ruolo del Product Owner è un delegato tra le persone che fanno il lavoro e le persone che hanno bisogno del lavoro fatto e questo causa ritardi, incomprensioni e gonfiano il processo di ingegneria del software.” Aggiunge Mike Cohn, firmatario del Manifesto Agile di sviluppo del software: “ci si aspetta dal team di prendere decisioni tecniche in modo collaborativo, quindi perché non fare lo stesso per le decisioni relative al prodotto?”
Scarica la Guida alle Metodologie Agile
Perché è una pessima idea
La figura e il ruolo del Product Owner è una pessima idea per diversi ordini di motivi:
- deresponsabilizza il team
- è un filtro tra il team e i bisogni del cliente
- è un collo di bottiglia che rallenta il processo
- ha un approccio PUSH e non permette che il lavoro sia PULL dalle esigenze del cliente.
- La modalità PUSH, tipica del ruolo del PO, lascia poche opportunità di innovare e sperimentare.
- decide le priorità senza consultarsi con il team (spesso con metodo dittatoriale)
- è un fattore demotivante per il team
- minano l’autonomia del team
- è focalizzato sulla delivery non sull’apprendimento
- non è chiaro il suo scopo al team, scopo spesso opaco e poco condiviso
- non è chiaro quale sia il valore che deve massimizzare, quello dell’azienda o quello del cliente
- spesso non può sapere quali funzionalità abbiano maggior valore né come debbano funzionare, non ha conoscenze tecniche specifiche per comprenderlo e non confrontandosi con il team non sempre è in grado di stabilirlo
- è una figura obsoleta per il cambiato contesto di sviluppo del software
In sostanza il Product Owner incarna la figura manageriale delle organizzazioni del XX secolo che non sono più attuali in nessuna organizzazione che voglia sviluppare un rapido adattamento ed evolvere in un contesto economico e sociale ormai molto differente. Di fatto la figura del PO è ormai obsoleta, il che vale anche per gli O&KRs perché è cambiato il modo di lavorare anche, e forse ancor di più, per organizzazioni di sviluppo software.
Che cosa è cambiato?
Siamo entrati nel XXI secolo, nell’epoca della Business Agility che consiste nella capacità di un’organizzazione di integrare l’eccellenza operativa, quindi velocità e qualità, con i flussi di informazioni che arrivano direttamente dai clienti, dall’utilizzo che fanno del prodotto, e attraverso l’analisi dei dati, spesso in tempo reale, adattare la risposta delle operation alle necessità e richieste dei clienti. Questo per lo sviluppo del software significa assumere almeno cinque caratteristiche:
- team integrato di sviluppatori, operation, sicurezza e collegato al business e ai suoi obiettivi (full stack)
- rilasci frequenti, almeno due volte al giorno. Gli Sprint sono troppo lenti. Amazon rilascia codice utente ogni 11.6 secondi
- molta sperimentazione con feedback frequenti che danno le indicazioni sulle cose nuove da sviluppare
- gli obiettivi arrivano direttamente al team dai dati, team che è in grado autonomamente, rapidamente e frequentemente di adattare il proprio lavoro
- l’organizzazione assume spesso la configurazione di un network di team indipendenti ma interconnessi
Naturalmente queste caratteristiche non appartengono solo al settore di sviluppo del software, sono tipiche delle organizzazioni Business Agile. Per sapere di più sulla Business Agility leggi l’articolo.