Come fermare / evitare nel tempo un team Scrum?

In realtà, sto aiutando un piccolo negozio di software a implementare Scrum. Di recente lo Scrum Master mi ha segnalato che ha un problema perché il Team sta lavorando nel tempo per raggiungere lo Scope (Commlog Backlog). Quindi hanno una velocità irreale .

Le mie domande formali sono / sono:

1. Oltre a parlare della Riunione retrospettiva; pensi che sia una buona idea implementare alcuni blocchi per evitare nel tempo?

2. In tal caso, quali tecniche / strumenti suggerisci?

   • Sistema di controllo delle revisioni (SVN, GIT, HG, ecc ...), blocchi per ore (da 8 a 5)
   • Blocchi della stazione di lavoro per ore (da 8 a 5) o ore cumulative (fino a 8 ore al giorno)?
   • Altri)...

3. O, forse, non bloccare questo tipo di cose; ma implementare un "Sistema di penalità" per ore extra ingiustificate ?

@Baqueta (e altri con domande simili): No, non sono stati pagati per le ore extra. Il mio primo consiglio è stato quello di rivedere le loro stime perché forse stavano sottovalutando. Questo era il mio consiglio preferito:

Se hanno interesse a fare gli straordinari, rimuovilo. Lo sviluppo non è qualcosa che puoi fare per 60 ore a settimana e rimanere produttivo, e ci sono numerosi studi là fuori che lo dimostrano. Se la retribuzione degli straordinari è il problema, sbarazzarsene e migliorare la loro retribuzione base in modo da ottenere ciò che valgono.

Inoltre, penso che il problema alla radice (per questo team) sia una combinazione di quanto segue:

1. Agli sviluppatori viene detto cosa devono ottenere in uno sprint / non vengono consultati su ciò che è realizzabile / vengono ignorati quando dicono che c'è troppo lavoro.
2. Gli sviluppatori stanno costantemente sottovalutando il tempo impiegato dalle attività / quante unità di lavoro sono coinvolte in ciascuna attività.

Riepilogo: parlerò con il team per rivedere le loro stime e con l'OP perché ritengo che non vengano consultati in merito all'ambito, come hai detto.

Francamente, quei "blocchi" che menzioni nel n. 2 sono l'idea peggiore che ho sentito da molto tempo. Cosa succede se viene trovato un bug di massima priorità alle 16:45 e il ragazzo che ha la possibilità di scavalcare i blocchi è ammalato? Per quanto riguarda il n. 3, stai suggerendo di punire le persone per aver fatto il loro lavoro .

Se il team sta costantemente facendo gli straordinari per completare gli sprint, allora o sono interessati a fare gli straordinari - ad es. Retribuzione degli straordinari o tornare agli straordinari come vacanze - o si stanno impegnando a fare troppo lavoro negli sprint.

Se hanno interesse a fare gli straordinari, rimuovili . Lo sviluppo non è qualcosa che puoi fare per 60 ore a settimana e rimanere produttivo, e ci sono numerosi studi là fuori che lo dimostrano. Se la retribuzione degli straordinari è il problema, sbarazzarsene e migliorare la loro retribuzione base in modo da ottenere ciò che valgono.

Se c'è troppo lavoro in corso negli sprint, questo di solito è per uno dei tre motivi:

1. Agli sviluppatori viene detto cosa devono ottenere in uno sprint / non vengono consultati su ciò che è realizzabile / vengono ignorati quando dicono che c'è troppo lavoro.
2. Gli sviluppatori stanno costantemente sottovalutando il tempo impiegato dalle attività / quante unità di lavoro sono coinvolte in ciascuna attività.
3. Gli sviluppatori continuano ad essere coinvolti in attività che non fanno parte della mischia.

Se è il numero 1, stai sbagliando . Non ci sono due modi per farlo!

Se è il n. 2, la causa abituale è l'inesperienza - o nel fare stime del tempo, o con il sistema in sviluppo. Un buon modo per aggirare questo è di smettere di fare stime del tempo e iniziare a stimare "unità di lavoro". Usa qualche unità astratta, assicurati solo che non siano le ore in tempo reale (alla fine stai comunque rappresentando un intervallo di tempo, ma l'astrazione è importante!). È quindi possibile iniziare a calcolare quante unità di lavoro vengono effettivamente eseguite in una settimana, quindi impostare gli sprint utilizzando tali dati.

Se è il n. 3, è necessario iniziare in qualche modo il factoring in quelle altre attività. Se è coerente, dovrebbe essere facile spiegarlo (vedi sopra # 2). Se è frequente ma imprevedibile, è molto più difficile da gestire. Dovresti dare un'occhiata al motivo per cui sta accadendo (ad es. Bug gravi nel codice 'live' => il tuo test è abbastanza approfondito?) Ma se ciò non può essere risolto, alla fine la mischia potrebbe non essere l'approccio giusto per te. La mia squadra recentemente è passata a Kanban proprio per questo motivo ...

Modifica: chiarito la mia critica alle idee presentate nella domanda.

Prima di tutto, sembra che abbiano fatto troppo lavoro su uno sprint se devono fare gli straordinari per farlo. Tutte le ore sono registrate? In tal caso, potresti contare quanto lavoro effettivo è un punto della storia e utilizzare quel numero per calcolare il lavoro per lo sprint successivo.

È anche importante assicurarsi che il team capisca che si stanno facendo del male solo prendendo troppo lavoro. Anche l'agile manifesto parla di un ritmo sostenibile: "I processi agili promuovono lo sviluppo sostenibile. Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere un ritmo costante a tempo indeterminato". Il lavoro straordinario in ogni momento non è sostenibile.

Tutto sommato, suggerirei comunicazione invece di forza e sanzioni. Immagino che ciò porterebbe solo alla demoralizzazione della squadra.

Gli sviluppatori che lavorano fuori orario stanno probabilmente rispondendo a qualche incentivo, reale o percepito. È quello di rimuovere l'incentivo se è reale o di comunicare che un incentivo percepito non è operativo.

Ogni limite rigido suggerito presenta alcune soluzioni alternative o altri problemi. I blocchi di controllo del codice sorgente porterebbero gli sviluppatori a trattenere i propri commit fino a quando la finestra non si riapre. I blocchi di workstation dovrebbero andare non appena ci sono stati problemi di supporto o uno degli sviluppatori necessario per cambiare le sue ore per qualche motivo. I sistemi di penalità porteranno solo a nascondere o seppellire le ore di straordinario.

Penso che il problema sia più fondamentale: il team ha qualche incentivo (o ritiene di avere un incentivo) per fare gli straordinari.

Questo è ciò che deve essere affrontato. Le loro valutazioni delle prestazioni sono legate ai loro numeri di velocità? Il management fa gli straordinari? Le promozioni e i premi vengono assegnati a coloro che lavorano per lunghe ore? Sono appaltatori che vengono pagati per gli straordinari?

Dì semplicemente alla squadra di non fare gli straordinari. Periodo.

Ciò potrebbe impedire loro di finire un po 'di lavoro. Non è un problema, è un punto dati. Possono quindi utilizzare quel punto dati nella pianificazione dello sprint successivo. Ancora una volta, non lasciare che facciano gli straordinari. Che finiscano o meno, hanno un altro punto dati. Raccogliere, sciacquare, ripetere.

Non sono necessari limiti o trucchi. Basta non fare gli straordinari. Scopri quanto lavoro puoi realizzare e regola di conseguenza la pianificazione dello sprint.

Forse c'è un problema di non "quanto" funzionano ma di quando. Questo può essere un problema quando c'è una giornata lavorativa pianificata, ma gran parte del normale orario è costituito da riunioni e altre distrazioni sociali e personali. Stanno lavorando durante periodi di tempo perché si sentono solo più produttivi.

Riduci la quantità di lavoro nello sprint e inizia a lavorare sui tempi flessibili. Consentire loro di entrare più tardi. Il responsabile deve semplicemente dire alle persone di tornare a casa; Va tutto bene. Ci sono alcune culture aziendali che creano un ambiente in cui partire in anticipo può portare ad alcune sopracciglia.

Ho lottato con questo quando sono passato alla mischia. È naturale voler fare uno sforzo extra vicino a una scadenza, ma la mischia ha scadenze ogni due settimane, quindi è un adeguamento. Oltre al suggerimento che altri hanno fatto per ridurre i punti della trama impegnati ogni iterazione, suggerirei anche di garantire che le storie siano abbastanza suddivise, in modo che ogni sviluppatore possa finire almeno due o tre in un'iterazione.

Ciò non solo garantisce che ogni sviluppatore abbia la sensazione di aver realizzato qualcosa per ogni iterazione, ma ti dà anche un po 'di debolezza nel tuo ambito. Quando il tuo burndown mostra che non sarai in grado di finire una storia, puoi estrarla e riallocare le persone sulle storie che possono essere finite. Quando le persone vedranno che l'ambito di applicazione può essere adattato, sarà meno probabile che si preoccupino di scadenze non realistiche. Se inizi un'iterazione con ogni storia in corso, non hai spazio per la regolazione.

Un diagramma di flusso cumulativo ideale dovrebbe assomigliare a questo se tutti finiscono due storie per iterazione:

Non sembra mai così perché in realtà è molto difficile cronometrare tutte le storie per finire l'ultimo giorno mantenendo occupati tutti, ma è una buona regola empirica. In caso di sovraccarico, l'area rossa sarà più grande e sarà possibile rimuovere le storie. Se non hai un sottocomando, l'area blu sarà più grande e puoi aggiungere storie. Se le tue storie sono troppo grandi, l'area verde sarà più grande e dovresti dividere le storie.

Per evitare il lavoro straordinario, è necessario ridurre la portata del progetto.

Il seguente diagramma mostra dove si trova l'incertezza in un progetto:

Se noti, nelle fasi di definizione del prodotto e dei requisiti, hai una grande variazione nella stima dello sforzo. Non puoi essere sicuro che ci vorrà un mese o un giorno per implementare la funzione.

Scommetto che nessuno dei compiti è fatto perché sono semplicemente troppo grandi e non specificati e ce ne sono troppi.

Se il tuo team è in grado di gestire 10 ticket in 5 giorni e gli vengono assegnati 20 ticket, riduci quel numero, assegnalo al proprietario del prodotto / project manager / manager / client e digli di dare la priorità.

A questo punto è l'unico modo per salvare la squadra dagli straordinari. Non puoi consegnare tutto, ma qualsiasi cosa tu faccia consegnare avrà meno probabilità di avere bug.

Vorrei anche consigliare di cercare un nuovo lavoro e aiutare i compagni di squadra a fare lo stesso e sistemare i loro curriculum e portafogli professionali. Una società che si aspetta straordinari è una per cui nessuno dovrebbe lavorare e il software prodotto sarà pieno di errori.

Sconsiglio vivamente di "blocchi duri". Tali controlli potrebbero essere percepiti come microgestione e potrebbero non riuscire a risolvere il problema di fondo.

Ti suggerisco di scoprire perché i programmatori stanno facendo gli straordinari. La risposta potrebbe sorprenderti. Sembra che tu sia un "estraneo" (non un dipendente dell'azienda), e i programmatori potrebbero essere disposti a essere sinceri con te se li incontri privatamente (uno contro uno).

Il motivo del lavoro straordinario è veramente il carico di lavoro o è più legato alla cultura o alle aspettative?

Le ragioni del carico di lavoro potrebbero essere

• Il backlog impegnato è troppo grande
• I programmatori o il proprietario del prodotto sono "dorati" (rendendo le funzionalità più complesse del necessario)

Le aspettative potrebbero essere

• Una sorta di ricompensa finanziaria o di riconoscimento per il lavoro straordinario
• Paura di sbagliare. I programmatori hanno paura che sembreranno cattivi o puniti se non rispettano la scadenza
• I programmatori stanno sottovalutando gli effetti dannosi a lungo termine del lavoro straordinario.