Scrum: cosa succede se il Product Owner ha dei compiti?

Ho appena iniziato a lavorare con una squadra che ha acquisito alcuni aspetti di Scrum (timebox di due settimane) ma non altri (la squadra non è attualmente d'accordo su tutte le stime o sul numero di punti in uno sprint, ma cambierò questo presto.) Il proprietario del prodotto è anche una risorsa tecnica (scienziato) con un background di sviluppo.

È opportuno che i compiti del proprietario del prodotto (che coinvolgono principalmente la ricerca) si mescolino ai compiti del team (alcuni dei quali sono ricerca e sviluppo).

Gli esperti di Scrum sono fermi nell'affermare che il Product Owner e Scrum Master dovrebbero essere due persone diverse. Tuttavia, non esiste una regola del genere che non sia esclusa dal team di sviluppo. Nota nella guida Scrum :

Dimensione del team di sviluppo

La dimensione ottimale del team di sviluppo è abbastanza piccola da rimanere agile e abbastanza grande da completare un lavoro significativo. Meno di tre membri del team di sviluppo riducono l'interazione e si traducono in minori incrementi di produttività. Squadre di sviluppo più piccole possono incontrare vincoli di abilità durante lo Sprint, impedendo al team di sviluppo di fornire un incremento potenzialmente rilasciabile. Avere più di nove membri richiede troppo coordinamento. I team di sviluppo di grandi dimensioni generano troppa complessità per la gestione di un processo empirico. I ruoli Product Owner e Scrum Master non sono inclusi in questo conteggio a meno che non stiano anche eseguendo il lavoro di Backlog Sprint.

Il corollario di quest'ultima riga sarebbe che, se il Product Owner sta eseguendo il lavoro dello Sprint Backlog, viene conteggiato come membro del Team di Sviluppo.

Detto questo, fai tutto il possibile per fare bene il tuo lavoro.

Il Product Owner è responsabile della massimizzazione del valore del prodotto e del ritorno sull'investimento. Potrebbe sembrare semplice ma di solito è un ruolo a tempo pieno e molto impegnativo - probabilmente il più difficile di Scrum. Implica un sacco di lavoro strategico di alto livello e compiti di livello inferiore, dall'analisi delle opportunità di mercato e alla consultazione delle parti interessate e degli utenti del prodotto per prendere le giuste decisioni, a mantenere sempre aggiornati la roadmap e l'arretrato del prodotto, partecipare alla pianificazione e rivedere le attività, rendendosi disponibile per la squadra per rispondere alle loro domande, ecc.

Se l'OP è responsabile di altri compiti oltre a quello, li vedrei solo marginali nella maggior parte dei casi. Quindi la mia risposta sarebbe sì, creare attività per l'OP se davvero lo si deve e se contribuiscono direttamente alla produzione dell'incremento del software dello sprint, ma non vedo che ciò accada spesso nel progetto Scrum medio.

Scrum si occupa principalmente di comunicazione e di svolgere un lavoro pertinente e tempestivo. Tutto ciò che serve per raggiungere questo obiettivo è OK se questo è ciò che consente alla tua squadra di essere più produttiva.

È difficile fare bene, tuttavia. Ora sono in quella posizione e trovo difficile dedicare un adeguato periodo di tempo come proprietario del prodotto, lasciando comunque tempo per lo sviluppo. Tuttavia, l'accordo funziona bene per questo specifico team in questo momento. Rivederemo la decisione per me di fare il doppio dovere quando le nostre prestazioni diminuiranno, ma fino ad allora continueremo a lavorare in questo modo.

Quindi, provalo. Fai delle retrospettive per migliorare continuamente il tuo processo. Non lasciare che attenersi in precedenza a una metodologia interferisca con la produttività del tuo team.