Scrum: va bene che il responsabile dello sviluppo sia il proprietario del prodotto

In generale, la persona che sa di più sui requisiti dell'applicazione o che ha la responsabilità di interfacciarsi con il cliente è quella che dovrebbe essere il Product Owner.

Se i responsabili dello sviluppo nella tua organizzazione hanno la migliore conoscenza dei requisiti del prodotto, dovrebbero farlo dal Product Owner. Gli sviluppatori devono poter accedere al Product Owner per chiarire i requisiti e assicurarsi che ciò che stanno sviluppando soddisfi effettivamente i requisiti.

Per quanto riguarda l'auto-organizzazione, non credo che dovrebbe avere un effetto a meno che gli sviluppatori non riportino i responsabili dello sviluppo.

Se gli sviluppatori fanno riferiscono ai singoli responsabili dello sviluppo, le metriche delle prestazioni dello sviluppatore devono essere regolate in modo da non essere penalizzate se funzionano su requisiti di altri manager. Allo stesso modo, le regole devono essere messe in atto in modo che un particolare responsabile dello sviluppo non faccia leva sui propri dipendenti per ottenere priorità per lo sviluppo del loro prodotto a scapito di altri requisiti.

Potresti considerare di migliorare l'ambito dello ScrumMaster per assicurarti che i responsabili dello sviluppo non esercitino un'indebita pressione sugli sviluppatori al fine di modificare le priorità precedentemente concordate per le storie degli utenti.

Come @Contrarian menzionato , il Product Owner deve comprendere i requisiti ed è solitamente coinvolto in una prospettiva di business con clienti o Product Manager che influenzano le versioni generali del prodotto. Anche qui la priorità è una caratteristica chiave, quindi questa persona deve avere il potere di decidere in merito a cosa fare.

Nella maggior parte dei casi, un analista aziendale fa il salto a un proprietario del prodotto molto facilmente. Se attualmente hai qualcuno che gioca questo ruolo, fanno un ottimo PO.

In alcune organizzazioni, tuttavia, i requisiti vengono effettivamente chiariti al team da un architetto che ha una visione globale del prodotto o di un particolare modulo / componente del prodotto. Queste persone possono agire come Product Owner e possono aiutare con l'assegnazione delle priorità, anche se potrebbero non essere necessariamente coinvolte tradizionalmente nel lato business / client.

Per quanto riguarda l'utilizzo del responsabile dello sviluppo diretto di un team, vorrei mettere in guardia contro questo. Una cosa è avere un collega che ti informi delle priorità e che rappresenta i bisogni del cliente, e un'altra ancora che il tuo capo lo faccia.

Immagina che il tuo collega ti dica: "Jay, i pulsanti qui non funzioneranno per il cliente, ma non corrispondono alle linee guida per il branding". Puoi discuterne, tornare al tuo lavoro e spedire qualcosa di nuovo per una recensione.

Ora metti il tuo capo in quel posto. All'improvviso non si tratta più di una conversazione per ottenere il giusto risultato e ora si tratta di prestazioni. Eviterai di mostrare le cose in anticipo per ottenere un feedback perché potresti avere un brutto aspetto per il tuo capo. Non sarai necessariamente onesto riguardo a ciò che stai costruendo o quanto ti rimane. Una squadra agile deve essere trasparente l'una dall'altra in modo che possano reagire e adattarsi.

Detto questo, abbiamo inserito i responsabili dello sviluppo in alcuni dei nostri team, ma non come Product Owner. Li coinvolgeremo in qualità di membri del team che capita anche di fornire consulenza tecnica o supporto al Product Owner e allo Scrum Master. Ciò consente alle loro conoscenze e agli altri livelli dell'organizzazione di essere uno strumento che il team può utilizzare, senza che siano in grado di avere il controllo completo su tutti gli aspetti dello sprint.

Cerca la persona della squadra più strong in queste qualità:

1. Conosce il business generale (non solo l'attività del cliente)
2. Ha una relazione con il cliente
3. Buono a logicamente abbattere i desideri dei clienti in piccole storie orientate al valore aziendale (Praticamente la mentalità Agile BSA)
4. Ha capacità di miglioramento del processo
5. Ha capacità di gestione delle modifiche

Per quanto riguarda l'auto-organizzazione; un PO generalmente non dovrebbe avere alcun rapporto diretto sul team di consegna in quanto questo può essere un conflitto di interesse in termini di team che sfida l'OP su requisiti, priorità, ecc.

Un grande PO sarà un BSA a cuore, ma dovrebbe sempre prendere in considerazione il processo e modificare gli impatti della gestione che vanno insieme a fornire una soluzione tecnica. Dopo tutto, la creazione di una soluzione che non rientra in un processo attuale o futuro o che nessuno adotta non fornisce molto valore al cliente.