Utilizzo di Scrum su piccoli progetti in cui il proprietario non vuole essere coinvolto

Recentemente ho letto e imparato molto sulla mischia e mi piace molto. Tuttavia, ho un paio di scenari probabili nella mia testa in cui non conosco la soluzione. Quindi diciamo che potrei voler organizzare un team agile di (ad esempio) quattro sviluppatori web (uno dei quali UI / UX designer). Questa squadra opererebbe secondo i principi della mischia.

Inizialmente probabilmente lavoreremmo su progetti come landing page per le piccole imprese della gente comune, come affittare appartamenti, vendere biscotti ... Tali clienti semplicemente non possono essere impostati con il ruolo di Product Owner (IMHO), perché di solito si aspettano di assumere un'azienda , fornire loro l'obiettivo generale del progetto con alcuni dettagli e quindi aspettarsi che il lavoro venga svolto (incluso un sacco di decisioni) con il minor coinvolgimento possibile (a loro avviso, hanno cose più importanti da fare). Diciamo che mi piacerebbe impegnarmi in un ruolo di sviluppatore / scrum master (so che anche quello è discutibile, essere un membro del team e uno scrum master in una volta), quindi semplicemente non dovrei assumere il ruolo di proprietario del prodotto come bene.

Per quanto riguarda le mie domande: se sono il proprietario dell'azienda, devo semplicemente essere anche un proprietario del prodotto (questi ruoli si includono)? Posso assumere un addetto alle vendite che potrebbe avere il ruolo di proprietario del prodotto? Sarebbe meglio se fosse uno sviluppatore esperto invece di un addetto alle vendite? È anche una mossa intelligente? Infine, esiste un altro approccio agile che potrebbe adattarsi meglio alla mia posizione?

EDIT: Grazie a tutti per i buoni contributi. Ho aggiunto alcuni commenti, qualsiasi informazione aggiuntiva sarà molto apprezzata.

Penso che la tua situazione sia in effetti molto comune, molti clienti non devono essere coinvolti con il livello di dedizione di cui ha bisogno un ruolo di OP.

È molto usuale l'approccio del "proxy PO", questa è una persona della tua azienda che parla con il cliente e traduce i requisiti del cliente in storie utente per il team di Scrum. Ovviamente devi coinvolgere a poco a poco di più il tuo vero cliente nel tuo processo, ma questo non è sempre possibile e dipende molto dal tuo tipo di client, il "proxy PO" può essere una soluzione ragionevole nella maggior parte degli scenari .

Per questa posizione il migliore non è probabilmente uno sviluppatore, e probabilmente non un addetto alle vendite, il migliore è un esperto di dominio nel business del tuo cliente (allo stesso tempo può essere uno sviluppatore o un venditore, ma la sua abilità principale è quella di essere un esperto di dominio).

Un'altra cosa da considerare è se hai davvero bisogno di una persona a tempo pieno con questo ruolo, o se questo ruolo può essere condiviso con altre attività, questo dipende ancora molto dal tuo contesto particolare, puoi iniziare con un ruolo condiviso o a tempo pieno e "ispeziona e adatta" alle tue esigenze particolari.

Nella mia esperienza, se dici al cliente che sono il "proprietario del prodotto", tendono a ribellarsi alla responsabilità extra. Ma se dici che mostrerai loro i tuoi progressi ogni due settimane in modo che possano dirigere la squadra, sono bravi con questo. Per la maggior parte, è quello che fa comunque il proprietario del prodotto.

Direi che il tuo cliente esterno è un stakeholder e il proprietario del tuo prodotto dovrebbe provenire dalla tua stessa organizzazione.

Nella mia esperienza, il proprietario e il proprietario del prodotto raramente hanno lo stesso ruolo. Per verificare le competenze richieste a un Product Owner, nonché le loro responsabilità, non guardare oltre la Scrum Guide .

Scegli il proprietario del prodotto con cura. Avranno un impatto significativo sul modo in cui otterrai i benefici della mischia.

Sono stato in situazioni simili e non abbiamo mai dato la responsabilità del proprietario del prodotto al cliente. Come hai detto, il cliente non vorrà assumersi questa responsabilità. Richiede molti sforzi da parte loro e non è considerata la migliore pratica.

Dovresti avere un proprietario del prodotto che fa parte del tuo team e assicurarti che il team fornisca ciò che il cliente richiede. E ancora più importante, agisce nell'interesse della tua squadra. Dovrebbe avere abbastanza esperienza per capire il cliente e giudicare le priorità e l'importanza delle funzionalità richieste dal cliente.