Affinché Agile funzioni al meglio, deve esistere un unico "proprietario del prodotto", una singola persona o un team responsabile della generazione e della definizione delle priorità dei requisiti.
Nel mio ultimo progetto Agile, avevamo due proprietari di prodotti; due diverse aziende che sono venute da noi in coppia e hanno detto che volevano un nuovo software per sostituire un'applicazione che stavano letteralmente pagando ai loro concorrenti (parliamo di centinaia di migliaia di dollari al mese in tasse di licenza). Ha funzionato bene come tre entità aziendali possono lavorare, principalmente perché c'era uno spirito di cooperazione tra tutti i partecipanti. Anche allora, c'erano problemi; le responsabilità dei requisiti erano suddivise tra le OP, eppure entrambe le società dovevano contribuire a molte di esse. Ciò ha comportato una diversa qualità dei requisiti a seconda del PO che li ha generati, e spesso un lungo e lungo scambio tra le OP e le BA per appianare le incongruenze. I due PO hanno anche utilizzato l'applicazione con licenza in modo diverso, con diverse configurazioni, e quindi avevano aspettative diverse su come avrebbe dovuto funzionare la stessa funzionalità, sulla base di impostazioni che avevano dimenticato da tempo dal software originale.
Tu e la tua azienda affrontate una situazione ancora più difficile, in cui i vari stakeholder potrebbero essere in competizione tra loro giorno per giorno, e stanno mordicchiando e graffiando sotto la superficie per ogni vantaggio relativo che possono ottenere. Per una società ottenere una funzionalità specifica per l'azienda posta al di sopra del morso di un'altra azienda nell'arretrato è proprio un tale vantaggio, e non sarei sorpreso se un membro dell'organizzazione tentasse di utilizzare questo processo per seppellire un altro membro.
Mi avvicinerei a questa situazione in due modi:
-
Diventa il proprietario del prodotto per il gruppo di aziende. Ciò significa essere il mediatore, e possibilmente arbitro, delle controversie tra gli stakeholder in merito alla prioritizzazione del backlog e alla creazione di requisiti. Ciò avrebbe un valore significativo sia per le parti interessate che per le società di sviluppo con cui hai lavorato; diventi un "cuscinetto" tra le due parti, assumendo la non invidiabile posizione di isolare lo sforzo di sviluppo dalla politica della generazione dei requisiti. Per gli stakeholder, sei un consulente e guida attraverso il processo Agile, appianando i dossi della strada in modo da non far deragliare l'intero sforzo.
-
Organizzare lo sforzo di sviluppo in base agli stessi stakeholder. Se esiste un insieme "comune" di funzionalità su cui la maggior parte o tutte le parti interessate possono essere d'accordo, impostare un grande team "core" per creare il software di base. Quindi, se una società, o anche due o tre, ha bisogno di lavorare in un modo diverso per loro e il gruppo nel suo complesso non è disposto a sostenere lo sforzo, è possibile impostare o avviare team più piccoli che possono attaccare questi pezzi aggiuntivi di funzionalità secondo un backlog separato. Questi team specifici del cliente sono ancora soggetti al percorso critico del backlog di base; la creazione di funzionalità specifiche dell'azienda che è una modifica della funzionalità principale dipenderà sempre dalla funzionalità principale implementata per prima. Sicuramente assicurati che le funzionalità aggiuntive siano integrate in modo tale che il progetto passi ancora gli AT di base; quelli sono quelli per cui tu e gli sviluppatori otterrete la quota dei leoni del prezzo del contratto.