È una buona idea nominare un membro del team di Scrum o uno Scrum Master come Product Owner?

Ultimamente abbiamo avuto un progetto, in cui il cliente era impegnato in tournée. Come al solito è stato formato il team di scrum, la direzione ha deciso di nominare il nostro analista come Product Owner poiché il Cliente non sarà in grado di partecipare attivamente. L'analista è stato colui che ha lavorato a stretto contatto con il cliente per l'analisi dei requisiti e la redazione delle specifiche.

Il cliente non ha il tempo di rivedere le prime due versioni. Tutto è andato liscio fino a quando, il client ha visto la terza versione; non era soddisfatto di alcune funzionalità, e quelle sono state introdotte da Make Shift Product Owner (il nostro analista).

Ci è stato detto di aspettare che il team di progettazione finisse il modello di tutte le pagine e il cliente avesse controllato ciascuna di esse e approvato per continuare a lavorare. Il team Scrum è lì, ma senza sprint: abbiamo finito di lavorare quasi come il classico metodo a cascata.

È una buona idea nominare un membro del team di Scrum o un master come product owner? Dobbiamo seguire la mischia in assenza della partecipazione del cliente / proprietario del prodotto?

Solo poche settimane fa Mike Cohn ha scritto sul suo blog la combinazione dei ruoli di scrum master e di product owner. Non credo di poterlo mettere meglio di lui, ma il mio breve riassunto del suo post è questo:

• è una cattiva idea
• SM e PO svolgono tipi di compiti molto diversi ("compiti da protagonista" e "compiti da tutore" nelle parole di Cohn)
• è improbabile che la persona che combina i due ruoli sia adatta a tutti i compiti coinvolti in entrambi i ruoli
• la squadra può essere ferita dall'SM / PO combinato trascurando i compiti in cui non è il migliore.

Penso che non ci sia nulla di male in sé nel prendere qualsiasi membro di una squadra di mischia e trasferirlo al Product Owner. Ma devi capire che è come una promozione o un trasferimento interno; crea un buco nella squadra e il buco deve essere riempito. Forse la squadra può "riorganizzarsi" per riempire il buco; forse ha bisogno di assumere un nuovo dipendente per riempire la posizione vacante.

Il tuo processo mi sembra perfetto. Non l'hai descritto in dettaglio, ma almeno i ruoli sono rispettati (questo è importante).

Tuttavia, con i pochi dettagli che ho, posso vedere qualche problema a livello di proprietario del prodotto.

Deve garantire che il cliente sia adeguatamente informato dell'avanzamento. Sembra che stia facendo "cascata" esternamente con il cliente e "mischia" internamente con te.

Risultato : la cascata vince poiché il cliente è re. Anche se in questo caso, il cliente ha la sua responsabilità ...

Il tuo attuale team (incluso Scrum Master), dovrebbe concentrarsi sulla consegna del backlog dello sprint. Tuttavia, il proprietario del prodotto (analista) dovrebbe assicurarsi che ciò che è nel suo backlog rifletta ciò che il cliente desidera. Dovrebbe anche assicurarsi che la comunicazione sia buona e che il cliente partecipi.

Possibile soluzione : inviare il proprietario del prodotto (analista) a un corso Scrum Product Owner o farlo leggere (e comprendere) questo libro: Agile Product Management with Scrum .

Scrum funziona al meglio con un cliente reale sul posto. Ci sono un paio di sfide reali nel trattare con clienti che non sono abituati alla progettazione iterativa del prodotto.

• La sindrome del foglio bianco
• Sindrome del cliente spaventato

Le fasi di progettazione con un foglio bianco tendono ad andare in cielo molto rapidamente e in genere vanno in profondità su un paio di problemi laterali e non abbastanza in profondità sulla funzionalità di base necessaria. Hai davvero bisogno di un uomo di paglia che il cliente scelga per gli incontri di design per andare a buon fine. Concentrandoti su un solo aspetto alla volta, stai aiutando il tuo cliente ad apprendere la progettazione iterativa.

I clienti spaventati (come hai fatto con la tua esperienza) non si rendono conto che i progetti agili prevedono una certa quantità (controllata) di rilavorazione come parte del processo. Quello che fanno fatica a capire è che man mano che lo sviluppo del prodotto avanza, ci saranno meno momenti "Oh mio dio". Ancora più importante, la parte con cui la maggior parte dei clienti si trova in difficoltà è che i momenti "Oh mio dio" non richiedono un sacco di soldi da risolvere a causa del breve tempo tra i cicli di revisione / pianificazione.

Gestire le aspettative dei clienti è molto difficile. È un buon equilibrio tra educazione del cliente, placating e persino imparare a dire "no". Il cliente non può sempre venire settimanalmente o due volte alla settimana. A volte possono venire solo una volta al mese. Va bene. Finché mostri loro cosa hai fatto per affrontare le loro preoccupazioni il mese precedente, quindi ti concentri sul lavoro di questo mese, farà molto per rendere il progetto più fluido. In conclusione, in assenza del cliente hai qualcuno che può formulare raccomandazioni ragionevoli per alcune domande. Deve essere qualcuno che abbia familiarità con gli obiettivi che il cliente sta cercando di raggiungere.

Idealmente, il proprietario del prodotto ha un certo livello di autorità e conoscenza del progetto. La stessa cosa sarebbe potuta accadere se il cliente avesse assegnato un dipendente di livello inferiore che era stato poi sovrastato in una fase successiva, richiedendo di ricominciare da capo.

Grazie per il tuo post. Mi rendo conto che è vecchio, ma penso che tu abbia sollevato un ottimo caso e qui ci sono i miei $ 0,02:

Problema 1: nominare l'analista come PO nel tuo caso cortocircuita gravemente il quadro della mischia. Perché? Perché solo l'OP può esprimere giudizi di valore, valutazioni del ROI, priorità e scelte decisive che derivano dall'azienda, non dalla tecnologia, nemmeno dalla familiarità con il prodotto. Sono sicuro che il tuo sr. l'analista ha fatto un lavoro fantastico imitando il PO, ma alla fine ha dovuto indovinare i desideri, i valori, le scelte che sarebbero venuti dal tuo PO. rif http://kenschwaber.wordpress.com/2011/01/31/product-owners-not-proxies/ . A meno che al tuo analista non sia stato concesso il POA dal cliente (improbabile), non sarebbero in grado di accettare o rifiutare nulla durante la revisione dello sprint.

Questo approccio potrebbe forse funzionare? Sì, ma dovrebbe esserci un trasferimento totale di responsabilità mentre il cliente era fuori. Il capo del tuo cliente dovrebbe accettare il surrogato e che nessuna decisione ragionevole presa sarebbe annullata. Sembra probabile? È più probabile che tu riceva un PO temporaneo dall'organizzazione del tuo cliente (che non è certamente senza il suo rovescio della medaglia!) Ma se il tuo sr. l'analista ha lavorato con il PO temporaneo, qualsiasi decisione errata verrebbe dal business, mantenendo così puliti i ruoli del team.

Problema 2: "il client non ha tempo di rivedere". Grande problema (e uno che mi sono imbattuto anche di recente). PO deve essere presente per accettare il prodotto. Nessun altro può "firmare l'assegno". L'assenza di OP significa insoddisfazione in seguito, potenzialmente più rielaborazione e perdita di fiducia. Più fondamentalmente sto percependo che il cliente non è attivamente impegnato nel tuo progetto: non c'è tempo per lo standup quotidiano, non c'è tempo per rispondere alle domande, ecc.

Problema 3: "ci hanno detto di aspettare che il team di progettazione finisse il modello". E ora sono completamente fuori mischia. Le persone che fanno il mock-up dovrebbero far parte del tuo team interfunzionale. Non so dire se ciò sia causato dalla mancanza di comprensione da parte del management della mischia o da una reazione di shock alla tua terza versione.

Domanda: dov'era il tuo maestro di mischia in tutto questo? Il SM riconoscerebbe normalmente il pericolo del conflitto di ruolo e la mancanza di partecipazione dell'OP, entrambi gli ostacoli / i pericoli da affrontare.