“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:
Vediamo perché.
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?”
La figura e il ruolo del Product Owner è una pessima idea per diversi ordini di motivi:
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.
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:
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.