Come guidare gli stakeholder (s) a non allontanarsi dalla visione di mischia?

Lo scopo principale della metodologia Agile e dello sviluppo di sprint è supportare i nuovi e mutevoli requisiti degli stakeholder. Se questo progetto fosse gestito in modo cascata, questo tipo di richiesta avrebbe minacciato il successo del progetto.

Se c'è una cosa che ho imparato, Non puoi combattere lo scorrimento del telescopio . È come nuotare contro la corrente di un fiume, puoi combattere, calciare e urlare tutto quello che vuoi ma alla fine il fiume ti porterà via. La linea di fondo è che le parti interessate vogliono ciò che dovrebbe essere consegnato o gli stakeholder saranno insoddisfatti.

Un ulteriore vantaggio della tua situazione è che non stanno cambiando i requisiti stabiliti, semplicemente espandendo l'ambito per includere funzionalità aggiuntive. Questo va bene fintanto che la scadenza si muove in avanti con la creep dell'oscilloscopio. Questo diventa solo minaccioso per un progetto quando viene fissata una scadenza fissa.

Per ogni nuova funzione, spiega che riporterà indietro la data di rilascio e aumenterà l'incertezza della data di rilascio. Il tempo è denaro.

"Sì, SIR, Mr. stakeholder." Certo, Mr. stakeholder, signore, ti consegnerò il mondo su un piatto d'argento e tutto quello che chiedo in cambio è che tu mi paghi per lavorare su questo progetto fino a che Sono 50. Perché è quanto ci vorrà. "

Potresti anche menzionare che ogni ora che le parti interessate trascorrono a martellare quali sono i requisiti sono circa 10-20 ore di sviluppo dopo che tutto è stato detto e fatto. Conoscere le esigenze in anticipo e pianificare per loro è più efficiente dal punto di vista del tempo, quindi imbullonare soluzioni sul lato di un progetto.

Penso che vada bene, purché tu stia rivalutando i nuovi obiettivi alla luce di quelli vecchi.

Direi che non appena il tuo stakeholder vuole un server di posta, il team potrebbe fare una delle due cose:

• controlla che un server di posta sia più importante con le funzionalità precedentemente definite nel backlog per l'app di dati finanziari. Se gli stakeholder della parte aziendale sono d'accordo, sono gli esperti nel dominio problematico.

• come una squadra, vedi cosa puoi fare oltre a sviluppare un server di posta - ovviamente questo è un esempio estremo - ma sembrerebbe intuitivo per host un server di posta che è già stato sviluppato e potresti avere ancora tempo nello sprint per procedere anche con gli obiettivi originali.

Conosco molte volte il desiderio di gratificazione immediata rispetto agli obiettivi a lungo termine. E penso che per grandi cose che non possono essere fatte in un singolo sprint, il team è decisamente sfidato a rompere le cose a lungo termine in modo che sembrino ancora allettanti rispetto ai facili addizioni a breve termine che sembrano importanti ma potrebbero non esserlo.

Perché le parti interessate stanno comunicando con il team piuttosto che con il PO. Comunque, ecco come penso che l'OP dovrebbe gestire questa situazione. Prima una citazione dal libro di Ken Schwaber "Agile Project Management with Scrum"

Un progetto Scrum inizia con una visione del sistema da sviluppare. All'inizio la visione potrebbe essere vaga, forse espressa in termini di mercato piuttosto che in termini di sistema, ma diventerà più chiara man mano che il progetto avanza. Il Product Owner è responsabile per coloro che finanziano il progetto per fornire la visione in un modo che massimizzi il ROI .

Quindi l'OP deve informare gli sponsor, cioè le parti interessate, in che modo la deviazione influirebbe (o ritarderebbe) il ROI. Se gli sponsor sono d'accordo, la squadra non può avere alcuna obiezione.

SCRUM blocca lo scope-creep durante lo sprint, ad esempio non durante il rilascio. In effetti, un buon PO garantirà che eventuali cambiamenti dei fattori esterni, incluso lo spirito dello sponsor, si riflettano correttamente nel backlog del prodotto al più presto.