In Scrum, perché i ruoli Product Owner e ScrumMaster non dovrebbero essere combinati?

Nei progetti più tradizionali a cui ho lavorato, il project manager (e, su progetti più grandi, potrebbero esserci associati / vice / assistenti project manager qualora una persona non fosse disponibile) è la persona responsabile della comunicazione con il cliente, della ricezione del progetto aggiornamenti di integrità e stato, determinazione della pianificazione e del budget, gestione del processo, garanzia che il team disponga di ciò di cui ha bisogno per completare le attività e così via.

In Scrum, tuttavia, queste responsabilità sono suddivise tra il Product Owner e ScrumMaster. Il Product Owner è la voce del cliente. Interagiscono direttamente con il cliente, creano user story, organizzano e danno priorità al backlog del prodotto e ad altri problemi relativi a utenti / clienti. ScrumMaster gestisce il processo, supervisionando le riunioni (compresi la stima e la pianificazione), eliminando gli impedimenti e monitorando lo stato generale del progetto, apportando le modifiche necessarie.

Ho letto in più fonti, tra cui Wikipedia , che il ruolo di ScrumMaster e Product Owner dovrebbe essere ricoperto da due persone diverse. Non solo ho letto, ma ho lavorato a progetti di successo in stile "tradizionale" in cui le attività di entrambi erano gestite da un singolo individuo. In effetti, ha più senso che da una a tre persone siano responsabili della gestione dei progetti (compresi risorse umane / personale) e delle attività a livello di processo, poiché spesso vanno di pari passo. Le modifiche al processo hanno un impatto sulla pianificazione, il budget, la qualità e altri obiettivi a livello di progetto e le modifiche al progetto hanno un impatto sul processo.

Perché Scrum richiede di isolare queste attività in due ruoli? Quali vantaggi offre in realtà? Qualcuno ha partecipato a un progetto Scrum di successo in cui il Product Owner e ScrumMaster erano la stessa persona?

Possono (e spesso sono) combinati e fatti da una sola persona (non vi è alcuna regola contro questo (la sua mischia dopo tutto)).

MA devi bilanciare attentamente la responsabilità della differenza poiché i due ruoli hanno competizione e ordini del giorno (e ci vuole una persona speciale per essere in grado di fare entrambi contemporaneamente). Ho visto molti provare, ma pochi ce l'hanno fatta per un lungo periodo di tempo (è una posizione stressante).

• Per essere lo SM hai bisogno di più conoscenze tecniche rispetto all'OP (poiché aiuterai a organizzare il team di sviluppo). Ci vuole una conoscenza dettagliata del prodotto per essere in grado di estrarre le cose dal backlog del prodotto nel backlog di primavera (a volte non è possibile estrarre i primi 'n' articoli in quanto ciò può essere controproducente).

• L'OP richiede una maggiore comprensione dell'equazione dell'utente rispetto a quella SM. Questo non deve essere altrettanto tecnico, ma richiede la conoscenza di come il prodotto verrà utilizzato nel mondo reale e la direzione in cui il cliente vuole prendere il prodotto.

Se riesci a trovare una persona in grado di svolgere entrambi i ruoli, non vedo alcun motivo per impedirlo.

Potrebbero sorgere problemi quando l'OP viene trascinato dal cliente in una direzione che sta causando conflitti significativi agli sviluppatori (perché devono prima costruire qualche altra infrastruttura). Il compito di SM non è seguire i capricci del cliente ma proteggere gli sviluppatori dai loro capricci. Togliere questo obiettivo è difficile.

Non sono un esperto, ma penso che lo Scrum Master dovrebbe essere il difensore / facilitatore del team. La voce del cliente dovrebbe avere a cuore gli interessi del cliente. Lo Scrum Master dovrebbe aiutare il team a ottenere ciò di cui ha bisogno per avere uno sprint di successo.

Inoltre, tieni presente il più delle volte, non stai lavorando su 1 cliente alla volta. I proprietari dei prodotti possono gestire diversi clienti e concentrarsi su quella parte del business e ScrumMasters può concentrarsi sullo sviluppo del progetto.

Come molti hanno già detto, entrambi i ruoli hanno interessi distinti, ma un obiettivo comune e competenze diverse per acquisirlo.

Se la stessa persona rappresenta il team di sviluppo e gli utenti / clienti, l'unica risorsa che hai in una controversia è guardare il contratto. Anche se alla fine può arrivare a questo, stai meglio se un rappresentante di entrambe le parti con uguale potere può trovare un accordo.

Le persone nei ruoli di Product Owner e Scrum Master possono avere desideri, obiettivi, requisiti e vincoli contrastanti, più di 2 programmatori casuali. Gli esseri umani possono o meno essere in grado di valutare egualmente bene gli obiettivi in ​​conflitto e possono avere maggiori probabilità di commettere errori di giudizio di fronte a obiettivi in ​​conflitto. Due persone con focus o pregiudizi leggermente diversi potrebbero avere meno probabilità di fare insieme gli stessi errori o lo stesso grado di errori di giudizio.

Due persone possono anche assegnare più ore-uomo totali a concentrarsi su ciascun aspetto diverso del problema / progetto (ad esempio gli obiettivi dei 2 ruoli diversi).