Come fermare / evitare i tempi supplementari in una squadra di Scrum?

Francamente, quei "blocchi duri" che hai menzionato in # 2 sono la peggiore idea che abbia mai sentito da molto tempo. Cosa succede se un bug con priorità alta viene trovato alle 16.45 e il tizio che ha la capacità di ignorare i blocchi è malato? Per quanto riguarda il n. 3, stai suggerendo punire persone per che fanno i loro lavori .

Se il team lavora costantemente straordinariamente per completare gli sprint, allora entrambi hanno interesse a lavorare fuori orario - ad es. pagare gli straordinari o recuperare gli straordinari durante le vacanze o si stanno impegnando a fare troppo lavoro negli sprint.

Se hanno interesse a lavorare fuori orario, rimuoverlo . 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 il problema degli straordinari è il problema, sbarazzati di esso e migliora la paga base in modo da ottenere quello che vali.

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

1. Agli sviluppatori viene detto che cosa devono ottenere in uno sprint / non vengono consultati su ciò che è raggiungibile / vengono ignorati quando dicono che c'è troppo lavoro.
2. Gli sviluppatori stanno costantemente sottovalutando quanto tempo impiegheranno le attività / quante unità di lavoro saranno coinvolte in ciascuna attività.
3. Gli sviluppatori continuano a essere sottoposti a compiti che non fanno parte della mischia.

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

Se è il n. 2, la solita causa è l'inesperienza, sia con l'esecuzione di stime temporali, sia con lo sviluppo del sistema. Un buon modo per aggirare questo è smettere di fare stime di tempo e iniziare a stimare le "unità di lavoro". Usa qualche unità astratta, ma assicurati che non siano ore in tempo reale (in definitiva stai ancora rappresentando un intervallo di tempo, ma l'astrazione è importante!). Puoi quindi iniziare a calcolare quante unità di lavoro effettivamente vengono eseguite in una settimana, quindi impostare gli sprint utilizzando tali dati.

Se è il n. 3, in qualche modo devi iniziare a considerare queste altre attività. Se è coerente dovrebbe essere facile da spiegare (vedi # 2 sopra). Se è frequente ma imprevedibile, è molto più difficile da gestire. Dovresti dare un'occhiata al motivo per cui sta accadendo (per esempio gravi bug nel codice 'live' = > il tuo test è abbastanza approfondito?) Ma se ciò non può essere risolto allora alla fine scrum potrebbe non essere l'approccio giusto per te . La mia squadra è passata di recente a Kanban proprio per questo motivo ...

Modifica: ha chiarito le mie critiche alle idee presentate nella domanda.

Prima di tutto, sembra che abbiano lavorato troppo su uno sprint se devono fare gli straordinari per farlo. Sono registrati tutti gli orari? Se è così allora puoi contare quanto lavoro effettivo è un punto della trama e usare quel numero per calcolare il lavoro per il prossimo sprint.

È anche importante assicurarsi che il team capisca che si stanno facendo del male solo facendo troppo lavoro. Anche il manifesto agile parla del 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 indefinitamente." Il lavoro straordinario per tutto il tempo non è sostenibile.

Tutto sommato, suggerirei la comunicazione anziché la forza e le sanzioni. Immagino che ciò porti solo alla demoralizzazione della squadra.

Gli sviluppatori che fanno gli straordinari probabilmente rispondono a qualche incentivo, reale o percepito. L'obiettivo è rimuovere l'incentivo se è effettivo o comunicare che un incentivo percepito non è operativo.

Ciascun limite rigido suggerito presenta alcuni workaround o altri problemi. I blocchi di controllo del codice sorgente porteranno semplicemente gli sviluppatori a mantenere i loro commit fino a quando la finestra non si riapre. I blocchi della postazione di lavoro dovrebbero essere disponibili non appena ci fosse qualche problema di supporto o uno degli sviluppatori necessari per spostare le ore per qualche motivo. I sistemi di penalità porteranno solo a nascondere o seppellire ore di straordinario.

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

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

Dì semplicemente al team di non fare straordinari. Periodo.

Ciò potrebbe impedirgli di terminare il lavoro. Questo non è un problema, questo è 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 no, hanno un altro punto dati. Mescolare, sciacquare, ripetere.

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

Forse c'è una questione di non come "molto" stanno lavorando, ma quando. Questo può essere un problema quando c'è un giorno lavorativo programmato, ma gran parte delle ore normali sono costituite da riunioni e altre distrazioni sociali e personali. Stanno lavorando durante periodi di tempo eccessivo perché si sentono semplicemente 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 solo dire alla gente di andare a casa; Va tutto bene. Ci sono alcune culture aziendali che creano un ambiente in cui partire presto può portare un po 'di cipiglio.

Consiglio vivamente contro "blocchi rigidi". Tali controlli potrebbero essere percepiti come microgestione e potrebbero non riuscire a risolvere il problema sottostante.

Ti suggerisco di scoprire perché i programmatori stanno facendo gli straordinari. La risposta potrebbe sorprendervi. Sembra che tu sia un "outsider" (non un dipendente della società), e i programmatori potrebbero essere disposti a essere sinceri con te se li incontri in privato (uno contro uno).

Il motivo del lavoro straordinario è davvero il carico di lavoro, o è la ragione più legata alla cultura o alle aspettative?

I motivi del carico di lavoro potrebbero essere

• Il backlog impegnato è troppo grande
• I programmatori o il prodotto il proprietario è "placcatura in oro" (che rende le funzionalità più complesse del necessario)

Le aspettative potrebbero essere

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

Ho lottato con questo quando sono passato per la prima volta in mischia. È naturale desiderare uno sforzo supplementare vicino a una scadenza, ma la mischia ha scadenze ogni due settimane, quindi è un aggiustamento. Oltre al suggerimento che altri hanno fatto per ridurre i punti della storia impegnati ogni iterazione, suggerirei anche di assicurare che le storie siano suddivise abbastanza, in modo che ogni sviluppatore possa terminare almeno due o tre in una iterazione.

Questo garantisce non solo che ogni sviluppatore si senta come se avessero compiuto qualcosa in ogni iterazione, ma ti dà anche un po 'di flessibilità nel campo di applicazione. Quando il tuo burndown mostra che non sarai in grado di completare una storia, puoi estrarla e riallocare le persone alle storie che possono essere completate. Quando le persone vedono che lo scopo può essere regolato, saranno meno propensi a sottolineare le scadenze irrealistiche. Se inizi una iterazione con ogni storia in corso, non hai spazio per la regolazione.

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

Non sembra mai così perché in realtà è molto difficile scandire tutte le storie per finire l'ultimo giorno tenendo tutti occupati, ma è una buona regola. Se sei impegnato, l'area rossa sarà più grande e puoi rimuovere le storie. Se non sei impegnato, l'area blu sarà più grande e potrai aggiungere storie. Se le tue storie sono troppo grandi, l'area verde sarà più grande e dovresti dividere storie.

Per evitare gli straordinari, devi tagliare l'ambito del progetto.

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

Senoti,nellafasedidefinizionedelprodottoedeirequisiti,haiun'enormevarianzanellastimadellosforzo.Nonpuoiesserecertocheoccorreràunmeseoungiornoperimplementarelafunzione.

Scommettochenessunodeicompitiè fatto perché sono semplicemente troppo grande e non specificato e ce ne sono troppi.

Se il tuo team è in grado di gestire 10 biglietti in 5 giorni e ricevono 20 ticket, taglia quel numero verso il basso, prendilo dal proprietario del prodotto / project manager / manager / client e dì loro di dare la priorità.

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

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