Quando intervenire sugli impedimenti?

A me sembra che tu stia trattando un regolamento di regole di stand-up un po 'troppo simile a una formula e nella tua formula ci sono due passaggi: 1) qualcuno dice di essere bloccato; 2) Devo fare X - aiutami a trovare X.

Le cose non sono così semplici. L'obiettivo di una riunione stand-up è che l'intero team si riunisca e condivida dove si trova, cosa ha fatto e dove sta andando. La regola # 3 è lì semplicemente per garantire che la riunione rimanga breve e diretta al punto. Il motivo è che fai riunioni quotidiane e se inizi ad avere discussioni ogni volta che qualcuno fa emergere un punto, finirai con riunioni di 1 ora + che diventeranno molto costose, molto veloci ... Sono stato in quelli, non sono divertenti.

Quindi, dal momento che stai cercando una formula, vorrei proporre una versione modificata in 3 passaggi di ciò che avevi:

1. qualcuno dice che sono bloccati
2. dopo l'incontro parla con SOLO persone alle quali bisogna parlare. Chiaramente la persona che è bloccata potrebbe voler elaborare quale aiuto ha bisogno. Forse un altro compagno di squadra o due vogliono essere coinvolti pure. C'è una buona possibilità, il 75% della tua squadra sarà in grado di tornare al proprio lavoro e continuare ad essere produttivo, motivo per cui il consiglio è di non avere discussioni in stand-up
3. Fai X - dove X è la conclusione da (2), non ciò che Internet ti dice di fare. E sì, sarà diverso per ogni situazione perché le persone vengono bloccate per ogni genere di cose diverse.

Poche altre parole di saggezza che volevo condividere ...

1. In qualità di scrum master, il tuo ruolo (ed è molto importante) è quello di assicurarsi che il tuo team funzioni nel modo più fluido possibile. Ciò non significa che non puoi avere una singola ruga e tutto deve essere tip-top. Ci saranno sempre blocchi di cui non puoi fare nulla. Significa solo, fai del tuo meglio per garantire che il tuo team rimanga produttivo. Quindi, una volta scoperto che qualcosa sta bloccando una storia, lascia che i membri del tuo team tornino al lavoro e si concentrino e dai un'occhiata per vedere se riesci a sbloccarli. A volte puoi, a volte non puoi.
2. L'errata stima non è la stessa cosa bloccata. Se qualcuno ha iniziato a lavorare su una storia e poi ha realizzato che implica 5 volte la quantità di lavoro. Sì, è un motivo di preoccupazione, ma in questo caso, in quanto scrum master, dovresti incoraggiare il miglioramento dei processi per migliorare la stima. Sfortunatamente, ci sarà molto poco che sarai in grado di fare nello sprint attuale. A volte le storie non vengono completate come pianificato. È la vita. La domanda chiave che dovresti porci a te stesso e al team è che stai facendo qualcosa di diverso / migliore per garantire che la successiva iterazione del team possa migliorare?
3. "assegna qualcuno per aiutare" - hai detto che due volte in poche righe di testo e in base a ciò, ho espresso un'opinione (forse non corretta) sul tipo di manager che potresti essere. Non gettare più persone, tecnologie, sedie a un problema ogni volta che ne sei costretto. CHIEDI IL TUO TEAM. Il punto non è chiedere alla tua squadra di alzarsi in piedi, ma nulla ti impedisce di avere una discussione una tantum e chiedere al tuo compagno di squadra bloccato se un'altra persona potrebbe aiutarti. In alcuni casi, un numero maggiore di persone potrebbe essere d'aiuto. In MOLTI casi, l'aumento dell'organico provoca più mal di testa, abbassa la qualità e il programma scivola ancora più lontano. In tutti i casi, la tua squadra saprà di cosa hanno bisogno, non noi.
4. Raccolta e analisi delle statistiche. Questa è una delle ragioni per cui Agile suggerisce brevi iterazioni. Quando facciamo la stessa cosa molte volte ancora e ancora. Ci dà la possibilità di migliorare noi stessi, ma solo se ci prendiamo il tempo per guardare indietro e vedere come stiamo andando. La tua squadra è troppo impegnata a fornire lavoro, ma puoi prendere un po 'di tempo e scrivere alcune informazioni. Quante volte sei stato bloccato per iterazione? C'è una persona che sembra essere bloccata più spesso di altre? Quanto scivoli di solito? (puoi compensare pianificando di meno nella prossima iterazione). Mostra questi dati al team e chiedi loro dove / come possono migliorare. Come suggeriva Euforico, un incontro retrospettivo alla fine di un'iterazione è un ottimo posto per farlo.
5. Scrum master NON è un manager o un overlord. Ricorda, non cercare di trovare una soluzione e restituirla alla squadra. Collaborare con il team e incoraggiarli a proporre la propria soluzione. Quindi fai del tuo meglio per aiutare il team a implementarlo.

So how would you, the average Scrum Master respond to such slippage?

Ci sono due parti a questo: impedimenti e slittamento.

Lo slittamento può accadere a causa di impedimenti, ma può anche accadere a causa di problemi imprevisti (che non devono essere impedimenti) o di qualcuno che si ammala o di qualcosa di semplice come un problema urgente sul campo. Quando perderemo i nostri obiettivi (o anche quando probabilmente non raggiungeremo i nostri obiettivi), lo comunicheremo ai proprietari dei prodotti e agli altri lead del team. Lo slippage accadrà, ma dove fa male lo sviluppo è quando le aspettative non sono impostate correttamente e le stime / processi non sono aggiustati per tenere conto delle cose che ti fanno scivolare. Ma non cambierei nulla a metà sprint, certamente non riassegnerei le persone ad aiutare. Gestisci il miglioramento della stima / processo nella tua retrospettiva & pianificazione sprint.

Gli impedimenti d'altra parte sono momenti in cui gli sviluppatori si imbattono in un roadblock ... uno strumento mancante, qualche codice prerequisito non c'è, qualcuno è fuori / manca / non aiuta. Hanno provato a risolvere il problema, ma non ci riescono. Questo è il tuo suggerimento da scrum master per immediatamente rintracciare la causa e sbloccarli. Non ci dovrebbe essere "tolleranza" per gli impedimenti.

Dovresti agire su tali impedimenti, ma solo per quanto riguarda la consulenza e l'orientamento. Dovresti chiedere loro se hanno bisogno di aiuto, magari negoziare con uno sviluppatore diverso se possono fornire aiuto. Ma non fornire aiuto senza il consenso dello sviluppatore. Avrebbero idea che stanno microgestionando troppo.

Ma è dato che quegli slittamenti influenzeranno il burndown dell'intero sprint. Quindi, se ti capita di sapere che ci saranno pochi giorni di slippage, dovresti discutere dell'aggiornamento dello sprint backlog con il proprietario del prodotto. Probabilmente causerà la caduta di alcune attività a bassa priorità.

Inoltre, durante la retrospettiva dello sprint, dovresti sollevare questo slittamento e calcolare la ragione per questo e cosa fare per non ripeterlo di nuovo. Forse il codice è un casino e richiede il refactoring. O forse i requisiti non erano abbastanza chiari e dovresti stare più attento la prossima volta. Oppure la libreria utilizzata dallo sviluppatore era poco conosciuta, quindi dovresti fornire più formazione. Etc ..