Determinazione del costo degli impedimenti (rifiuti)

5

Da qualche tempo i nostri team Scrum hanno sperimentato ricorrenti impedimenti causati da fattori esterni alla squadra. Le squadre hanno discusso gli impedimenti nelle loro retrospettive e lo hanno anche portato su "Scrum of Scrums". Sembra che gli impedimenti possano richiedere il coinvolgimento del management in quanto richiede alcuni cambiamenti piuttosto significativi in quel modo in cui facciamo le cose e il modo in cui i nostri ambienti tecnici sono stati configurati. In un piccolo contesto, questo tipo di problemi sarebbe probabilmente stato facile da gestire perché il team avrebbe avuto un maggiore controllo, ma in questo contesto ci sono più team, parti interessate e parti. Mi piacerebbe sentire la tua esperienza nel rendere visibili i rifiuti e i costi. Semplicemente stimerai le ore sprecate per gli impedimenti ricorrenti (ad esempio, "sprechiamo 10 ore ogni sprint in attesa sul server di generazione) o hai un modo più sistematico di raccogliere e mostrare i rifiuti?

Vorrei raccogliere rifiuti basati su Six Sigma (e Lean Software Development) e stimare il costo dei rifiuti in termini di punti storia. Per esempio. ad ogni retrospettiva evidenzia i rifiuti in sette categorie con il numero di punti storia sprecati in ogni categoria. Le sette categorie sarebbero: Lavoro parzialmente eseguito, Funzioni extra, Riapprendimento, Trasferimenti, Cambio di attività, Ritardi e Difetti.

Alla fine della Retrospettiva, ci sarebbe quindi una chiara indicazione del costo degli impedimenti esterni a cui la direzione sarebbe facilmente in grado di agire. Cosa ne pensi?

    
posta Allan Lykke Christensen 02.06.2013 - 16:27
fonte

1 risposta

1

Forse avresti ottenuto più buy-in dal management se avessi completamente trasformato il tuo problema e lo avresti presentato in questo modo; "Se risolviamo questo problema, cosa possiamo ottenere ?". Affrontate il problema dal lato positivo e nella mia esperienza otterrete una migliore risposta a tutto tondo. Quindi, piuttosto che evidenziare i problemi (che tutti possiamo fare fino a diventare blu in volto), evidenziare soluzioni e vantaggi per il cambiamento.

Potresti creare un elenco delle cose che la tua squadra vede come ostacoli e creare un backlog di "miglioramenti" separato. Valuta ogni articolo come faresti con qualsiasi altra storia utente. Quindi nella tua riunione di pianificazione con i tuoi stakeholder, puoi presentare le tue varie proposte con un chiaro vantaggio in termini di costi per loro.

"Quindi Gary, se includiamo questa storia di 'fix the build server' in questa settimana sprint, che abbiamo stimato con 6 punti, pensiamo che in futuro, saremo in grado di migliorare la velocità di circa 4 punti per sprint. "

Un paio di note in più su questo approccio;

1) queste storie sono effettivamente crude che devono accadere (ho completamente dimenticato il termine 'scrummy' per questo); e i punti della storia non dovrebbero contribuire alla tua velocità di sprint, in quanto sono un costo, e di per sé non progredire nel vero progetto

2) se riesci prima con una piccola storia di impedimenti, potresti ottenere più buy-in per gli oggetti più grandi nella tua lista di impedimenti

    
risposta data 03.06.2013 - 12:34
fonte

Leggi altre domande sui tag