Agile: come gestire le approvazioni del collo di bottiglia al di fuori di SCRUM?

5

Esiste un termine Agile per quando c'è uno stakeholder che funge da collo di bottiglia saltando solo occasionalmente per superare le decisioni prese collettivamente dal team? (cioè, i dirigenti che non partecipano mai al processo, ma occasionalmente riesaminano il lavoro e decidono che non gli piace)? Conosco Pig e Polli. Sarebbe semplicemente un "tipo di pollo"?

Esiste qualche tecnica Agile per gestire questo tipo di persona? C'è un ruolo particolare nel team di Agile che dovrebbe essere responsabile della gestione di questo tipo di problema?

Un esempio potrebbe essere che il proprietario del prodotto è felice, che l'IT è felice, UX è felice, i vari ruoli aziendali sono felici e gli sprint sono in corso, ma all'improvviso il capo del boss di qualcuno ha deciso di volere tutto messo in un mazzo PPT per loro per 'approvare' dove siamo.

    
posta DA01 10.04.2015 - 23:36
fonte

2 risposte

9

Questo è il lavoro del proprietario del prodotto.

L'intero punto del proprietario del prodotto è quello di fungere da punto di contatto tra tutti gli stakeholder (incluse persone come il capo del boss di qualcuno) e il team stesso. In teoria, il resto del team dovrebbe sempre solo avere a che fare con il Product Owner. Il Product Owner va e fa tutto il lavoro di parlare con i vari stakeholder, mette insieme le storie, e poi la squadra lavora su di loro in ordine di priorità impostata, e ignora chi ha richiesto cosa. (In pratica, non funziona mai in questo modo, ma abbastanza vicino.)

Tuttavia, è anche importante ricordare cos'è uno stakeholder. Uno stakeholder è la persona che scrive gli assegni. Il team ottiene un elenco di requisiti aziendali e li soddisfa. A volte ottieni stakeholder che vogliono qualcosa di stupido o che cambiano idea più e più volte. Questa è, sfortunatamente, la loro prerogativa, dopotutto, il punto di agilità è lasciare che le parti interessate cambino spesso idea e prendere decisioni stupide più velocemente. Idealmente, è soprattutto il Product Owner che si occupa dello stress di tutto ciò mentre la squadra prende le storie come vengono. In realtà, il punto di agilità è che le parti interessate capiscano che a loro non piace qualcosa e in realtà vogliono qualcosa di diverso.

Ora sono tutti requisiti aziendali. Se il capo di questo capo si muove con le decisioni tecniche, allora, tu hai la mia comprensione. Non esiste un vero termine Agile per questo diverso da "non agile". In Agile, il team prende decisioni tecniche, non le parti interessate.

TL; DR - Se uno stakeholder sta rovesciando le decisioni aziendali, questa è la sua prerogativa, ed è compito del Product Owner occuparsene. Se lo stakeholder sta ribaltando le decisioni tecniche , o ribaltando qualsiasi decisione nel mid-sprint, allora questo è qualcosa che il Product Owner e Scrum Master dovrebbero richiedere per fermare.

    
risposta data 11.04.2015 - 01:53
fonte
2

Altri esempi di interruzioni saranno utili per capire il ragionamento per cui il tuo skip manager o un altro stakeholder richiede "smetti tutto e fai questo" tipo di lavoro.

Perché " metti insieme un PPT per approvare ", potrebbe essere questa la mancanza di trasparenza su ?

Il tuo team invita tutte le parti interessate a partecipare alle dimostrazioni che mostrano lo stato / i progressi dei deliverable di sprint?

Qual è il risultato delle sessioni di pianificazione ? È qualcosa che solo la tua squadra possiede? Comunicate le storie e le priorità che avete concordato con il vostro top management (queste informazioni sono facilmente accessibili / individuabili?)

Sono d'accordo con Steven, se il cambiamento mid-sprint è guidato da una necessità aziendale o se il risultato di una micro-gestione sono due casi diversi.

Quando gli affari richiedono il cambiamento della direzione - questo è l'intero motivo per cui agisci allora. Se è così e pensi che succeda abbastanza spesso, considera accorciare le tue iterazioni o andare in Kanban in modo completo?

Se si tratta di un problema di microgestione, proteggi il tuo team, comunica le regole di base alla tua gestione: una volta che la pianificazione è terminata, nessun nuovo lavoro può essere iniettato in sprint - dovrà aspettare prossimo sprint. Di solito, se le iterazioni sono brevi - una settimana lunga - difficilmente qualcuno fa aspettare una settimana al massimo se ha una richiesta. Esegui il backup con i dati - mostra come soffre la velocità quando gli sprint vengono interrotti, spiegando come il cambio di contesto è inutile, ecc.

    
risposta data 12.04.2015 - 09:05
fonte

Leggi altre domande sui tag