Come fai a coinvolgere maggiormente il tuo product owner in progetti agili?

La presenza del proprietario del prodotto nelle riunioni obbligatorie (Sprint Review e Planning) è (dovrebbe essere) non negoziabile. Fai ciò di cui hai bisogno per negoziare un tempo che funzioni, quindi tieni assolutamente il proprietario del prodotto. Se si verifica qualcosa, rimandalo ma mantieni il responsabile del prodotto responsabile dell'interruzione dell'intera squadra.

Se il proprietario del prodotto è effettivamente (dal) cliente e non è disposto a partecipare a tale capacità, allora forse ha senso trovare un Product Owner interno che comunica con il cliente ma è in grado / autorizzato a effettuare alcune chiamate su proprio, per conto del cliente. Questa è l'impostazione tipica comunque, dal momento che ci sono alcune cose di cui un Product Owner è responsabile e che non dovrebbe davvero passare per gli occhi di un cliente.

Altrimenti, la tua unica scelta è sostanzialmente quella di abbandonare l'agilità. Non lo farai funzionare senza un PO in quelle riunioni.

Ogni giorno sembra molto per il proprietario di un prodotto. Indipendentemente dalla frequenza con cui sono richiesti, hanno bisogno di sapere che ci sono conseguenze per la loro mancanza o input ritardato. Se vogliono il progetto prima o dopo, possono sacrificare e prendere il tempo necessario.

Se sei venduto al 100% con un approccio agile e il tuo cliente è allo 0%, hai un deadlock. Qualcuno che è responsabile deve affrontare il fatto che gli affari finiranno fuori dalla porta senza bisogno di essere agili, non agili, solo Windows, solo Linux, solo web, solo incorporati, ecc.

Sto cercando di implementare il modo di ottenere un impegno dai proprietari dei progetti presso la nostra azienda. C'è stato un tempo in cui ogni singolo progetto a cui stavo lavorando, stava aspettando una recensione, un test, un'approvazione ecc. Da qualcun altro. Grazie a Dio per SO / SE.

Ovviamente una disponibilità abbondante è migliore, ma il processo di scrum fornisce al team molte opportunità per ottenere un feedback dal proprietario del prodotto se le riunioni periodiche sono svolte in modo appropriato dal supervisore.

Questo include sessioni di stima, pianificazione sprint, revisione sprint, retrospettiva.

Questo è già molto.

Se il tuo progetto è complesso e richiede una maggiore implicazione del proprietario del prodotto, il supervisore deve risolvere il problema per il team.

Un buon inizio sarebbe dire al proprietario del prodotto le esigenze del team.

Se il proprietario del prodotto è troppo occupato è disponibile per il team, ciò significa che non sono convinti che tale tempo non sia produttivo per il successo del progetto o che il proprietario del prodotto non si preoccupi del successo del progetto.

Presumendo il primo, è compito tuo mostrare al proprietario del prodotto quanto può essere reattivo un team agile ai suggerimenti del proprietario del prodotto. Se riesci a dimostrare le modifiche nel software che sono state in risposta ai suoi commenti e suggerimenti, potrebbe capire perché il suo coinvolgimento sia nel suo migliore interesse.

Soprattutto, non cercare di dire al proprietario del prodotto che questo è ciò che tu hai bisogno. Lo sviluppo agile riguarda la risoluzione dei suoi problemi, non lasciarlo pensare che per un minuto agile significa che deve risolvere i tuoi problemi.