È una buona idea nominare un membro del team scrum o un mischia master come Product Owner?

È stato solo poche settimane fa che Mike Cohn ha scritto di combinare lo scrum master e i ruoli del proprietario del prodotto sul suo blog. Non penso di poterlo fare meglio di lui, ma il mio breve riassunto del suo post è questo:

• è una cattiva idea
• SM e PO eseguono tipi di compiti molto diversi ("compiti a stella" e "compiti di guardiano" nelle parole di Cohn)
• è improbabile che la persona che combina i due ruoli sia adatta a tutte le attività coinvolte in entrambi i ruoli
• la squadra potrebbe essere danneggiata dal fatto che l'SM / PO combinato trascuri i compiti che non sono i migliori in

Penso che non ci sia nulla di sbagliato di per sé nel prendere qualsiasi membro di un team di mischia e spostarlo nel 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ò "auto-riorganizzarsi" per riempire il buco; forse ha bisogno di assumere un nuovo impiegato per riempire la posizione vacante.

Il tuo processo mi sembra soddisfacente. Non l'hai descritto nei dettagli, ma almeno, i ruoli sono rispettati (questo è importante).

Tuttavia, con i pochi dettagli che ho, vedo alcuni problemi a livello di proprietario del prodotto.

Dovrebbe assicurarsi che il cliente sia correttamente informato dell'avanzamento. Sembra che stia facendo "cascata" esternamente con il cliente e "scrum" internamente con te.

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

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

Possibile soluzione : invia il proprietario del tuo prodotto (analista) a un corso Scrum Product Owner o fagli leggere (e capire) questo libro: Gestione prodotti agile con Scrum .

Scrum funziona al meglio con un vero cliente 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 paziente spaventato

Le fasi di progettazione con un foglio bianco tendono a scorrere rapidamente in cielo, e in genere vanno in profondità su problemi di coppia e non abbastanza in profondità sulle funzionalità di base necessarie. Hai davvero bisogno di un uomo di paglia per il cliente da scegliere a parte per le riunioni di progettazione per andare con successo. Concentrandoti su un solo aspetto alla volta, stai aiutando il tuo cliente ad apprendere il design iterativo.

I clienti spaventati (come hai avuto con la tua esperienza) non si rendono conto che i progetti agili anticipano una certa quantità (controllata) di rilavorazione come parte del processo. Quello che hanno difficoltà a cogliere è che mentre lo sviluppo del prodotto procede, ci saranno meno momenti "Oh mio Dio". Ancora più importante, la parte in cui la maggior parte dei clienti si diverte è che i momenti "Oh mio Dio" non richiedono un sacco di soldi da risolvere a causa del breve intervallo tra i cicli di revisione / pianificazione.

Gestire le aspettative del cliente è molto difficile. È un buon equilibrio tra l'educazione alla clientela, la placabilità e persino l'apprendimento di dire "no". Il cliente non può sempre arrivare settimanalmente o bisettimanale. A volte possono venire solo una volta al mese. Va bene. Finché mostrerai loro quello che hai fatto per affrontare le loro preoccupazioni il mese precedente, poi concentrati sul lavoro di questo mese, ci vorrà molto per rendere il progetto più fluido. In conclusione, in assenza del cliente, c'è qualcuno che può formulare raccomandazioni ragionevoli per alcune domande. Deve essere qualcuno a conoscenza degli 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 succedere se il cliente avesse assegnato un dipendente di livello inferiore, che in seguito sarebbe stato dominato in una fase successiva, richiedendoti di ricominciare da capo.

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

Problema 1: nominare l'analista come PO nel tuo caso seriamente cortocircuiti il framework scrum. Perché? Perché solo l'OP può esprimere giudizi di valore, valutazioni del ROI, priorità e scelte decisive che derivano dal business, non dalla tecnologia, nemmeno dalla familiarità con il prodotto. Sono sicuro che il tuo sr. l'analista ha fatto un lavoro fantastico imitando l'ordine di acquisto, ma alla fine ha dovuto indovinare i desideri, i valori, le scelte che sarebbero venute dal vostro PO. ref link . A meno che il tuo analista non abbia concesso il POA al cliente (improbabile), non sarebbero in grado di accettare o rifiutare nulla alla recensione di sprint.

Questo approccio potrebbe funzionare? Sì, ma sarebbe necessario un trasferimento totale delle responsabilità mentre il cliente era fuori. Il capo del tuo cliente dovrebbe essere d'accordo con la surrogata e che nessuna decisione ragionevole presa sarebbe annullata. Sembra probabile? È più probabile che tu ottenga un PO temporaneo dall'organizzazione del tuo cliente (che non è certamente privo di svantaggi!) Ma se il tuo sr. l'analista ha lavorato con l'OP temporanea, qualsiasi decisione errata sarebbe arrivata dall'azienda, mantenendo così i ruoli della squadra puliti.

Problema 2: "il cliente non ha tempo di rivedere". Grande problema (e uno che ho incontrato anche di recente). L'ordine di acquisto deve essere presente per accettare il prodotto. Nessun altro può "firmare l'assegno". PO assenza significa insoddisfazione che si verifica dopo, potenzialmente più rielaborazione e perdita di fiducia. Più fondamentalmente sto percependo che il cliente non è attivamente impegnato nel tuo progetto: non c'è tempo per la situazione quotidiana, non c'è tempo per rispondere alle domande, ecc.

Problema 3: "ci è stato detto di aspettare fino a quando il team di progettazione ha terminato il modello". E ora sono completamente fuori di mischia. Le persone che fanno il mock-up dovrebbero far parte del tuo team interfunzionale. Non riesco a capire se ciò sia causato da una mancanza di comprensione da parte della direzione della mischia o da una reazione shock alla terza versione.

Domanda: dov'era il tuo supervisore in tutto questo? L'SM riconoscerebbe normalmente il pericolo del conflitto di ruolo e la mancanza di partecipazione dell'OP, sia per quanto riguarda gli ostacoli / i pericoli da affrontare.