Può verificarsi il burnout quando si eseguono sprint Scrum continuamente? [chiuso]


93

Ho una startup piuttosto piccola e abbiamo iniziato a utilizzare una forma di ciclo di sviluppo Scrum / Agile.

In molti modi mi piace Scrum. Abbiamo sprint relativamente brevi (2 settimane) e mi piace il Burn Down Chart per monitorare i progressi della squadra. Mi piace anche il Feature Board, quindi so sempre cosa dovrei fare dopo. È bello togliere la carta di una caratteristica dal tabellone, completarla e poi metterla nella pila delle fiamme.

Tuttavia, ora stiamo entrando nel nostro 18 ° ciclo di rilascio Sprint e sto iniziando a sentirmi un po 'esaurito. Non è che non mi piaccia il lavoro oi miei colleghi, è solo che questi sprint sono ... beh, sprint . Dall'inizio alla fine mi sento letteralmente come se stessi correndo contro il tempo per mantenere la nostra velocità di sviluppo. Quando abbiamo finito con lo sprint, passiamo un giorno a pianificare il set di funzionalità e le stime dello sprint successivo e poi ripartiamo.

Per le persone che lavorano in un processo di sviluppo Agile / Scrum maturo, è normale? O ci manca qualcosa? Normalmente c'è tempo in un ambiente Scrum non assegnato / non tracciato per fare alcune cose minori e per schiarirti le idee?


Darei un'occhiata più da vicino al contenuto dello sprint che alla metodologia. Lo sviluppo puro (nessun test, picchi, revisioni del codice) può uccidere le persone dopo un po '. Inoltre, lo scrum master dovrebbe difendere la squadra da roadmap irragionevoli, stime di tempo da parte del team, ecc. Durante il calcolo della disponibilità, assicurati di tenere conto del 10-20% dei tempi non impegnati per tenere conto di riunioni non programmate, pause per il bagno, distrazioni, ecc. Quindi pianifica qualsiasi cosa durante le cerimonie. Alla fine tutto si bilancia.
Sinaesthetic

12
se questo non è costruttivo, dove sarebbe meglio collocarlo nell'ecosistema Stackexchange?
Ryan Schultz

2
Forse programmers.stackexchange.com ... non ne sono sicuro.
Kevin Krumwiede

22
Domanda con 53 voti positivi. Risposta accettata con 49. Chiuso in quanto non costruttivo. Chiaramente alcuni ipocriti "moderatori" hanno smesso di prendere le loro medicine. Ancora.
SzG

D'accordo, la domanda riguarda i requisiti per la pianificazione della capacità e così è la risposta selezionata
charo

Risposte:


68

Questo è relativamente normale e talvolta può essere una lamentela dei membri del nostro team se i progetti continuano per un lungo periodo di tempo.

La chiave di ciò di cui stiamo parlando qui è il ritmo sostenibile . Se tu e il tuo team siete in grado di sostenere il vostro ritmo a lungo termine, è eccellente: avete raggiunto l'iperproduttività a cui aspirano tutti i team Scrum.

In alternativa, se ti accorgi di sovrastimare quanto lavoro puoi effettivamente svolgere in un giorno, potresti dover rivalutare questo aspetto durante la tua retrospettiva. La quantità di tempo produttivo in un giorno che un team sceglie di riconoscere quando fa la pianificazione delle capacità per uno sprint viene definita fattore di focalizzazione .

Henrik Kniberg ha questo da dire:

Il focus factor "predefinito" che utilizzo per i nuovi team è solitamente del 70%, poiché è lì che la maggior parte delle nostre altre squadre è finita nel tempo.

http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf

Tuttavia, ciò di cui sembra che tu stia parlando è semplicemente lo slancio ininterrotto dello sprint dopo lo sprint, non necessariamente la tua produttività in un giorno. Ecco alcuni suggerimenti di cose che abbiamo cercato di affrontare con questo:

  • Termina lo sprint un venerdì mattina. Fai la revisione dello sprint e la retrospettiva al mattino e lascia che il team lavori su qualcos'altro per il resto della giornata per schiarirsi le idee. Riprendi con la pianificazione Sprint lunedì.
  • Abbiamo introdotto la nozione di "giornate di laboratorio". Sono intere giornate che il team viene sottratto al progetto e trascorre la giornata a lavorare per migliorare le proprie competenze tecniche attraverso la ricerca reciproca e la collaborazione su specifici argomenti tecnici. Il più delle volte non hanno assolutamente nulla a che fare con il progetto specifico e consentono ai membri del team di pensare ad argomenti più leggeri.

3
Kniberg stesso ha detto: "il focus factor è una delle cose che vorrei strappare dal libro. Ho smesso di usarlo subito dopo aver scritto il libro ..." - twitter.com/henrikkniberg/status/207853426967715841
MPV

24

Da Wikipedia sul burnout: "il burnout è in gran parte un problema organizzativo causato da lunghe ore, poco tempo di inattività e continua sorveglianza di pari, cliente e superiore"

Potrebbero anche avere un'immagine icona di Scrum accanto alla definizione di burnout.

Se pensi di poter mandare qualcuno su qualcos'altro per un breve diversivo per risolvere il burnout, ovviamente non ci hai pensato. Mai andare in vacanza dopo essere stato esaurito e tornare al lavoro pensando, Wow! Ora sono rinfrescato e pronto per altri 6 mesi di questa tortura fino a quando finalmente avrò di nuovo una pausa. No, quello che succede è che ti rendi conto, Wow! Il mio lavoro fa schifo. Ora posso davvero vedere come il processo di micro-gestione e sviluppo del mio stupido manager sia solo un altro modo per ottenere di più da me con meno e la vita è troppo breve per questo ... dovrei trovare qualcos'altro da fare o cambiare lavoro in qualcosa di meno stressante .

Secondo me, Scrum breve di 2 settimane dovrebbe essere proibito tranne che a piccole dosi, non più di 4-8 di fila. Usalo come strumento per cose eccezionali o critiche, non continuamente. Usa il senso comune.


3
Questo è un FUD ridicolo, Scrum non riguarda certo il fatto che le persone si esauriscano, gli sprint brevi non riguardano il lavoro 80 alla settimana.
Pascal Thivent

7
Questo è giusto nel segno. È divertente come gli amanti della mischia lo difendano con la favola di come dovrebbe essere fatto, ma la maggior parte degli sviluppatori sperimenta proprio ciò di cui parla l'OP.
kirk.burleson

2
Me ne sono reso conto negli ultimi due anni e sono completamente d'accordo con quanto è stato detto qui. Non vedo l'ora di smettere di lavorare in questo modo anche se potrebbe significare essere un barbone per un po 'e usare i risparmi. Per non parlare del temuto "alzarsi in piedi" ogni mattina. Mi sveglio e vorrei essere altrove, e sto lavorando per renderlo realtà.
Skill M2

5
Per me, la mischia causa il burnout. Il numero di ore che lavoro e la quantità di produttività che ho non cambia, ma il mio umore cambia. Senza mischia, ho finito il lavoro e mi sentivo bene a farlo. Quando abbiamo aggiunto il processo di mischia, ho svolto lo stesso lavoro allo stesso ritmo, ma costantemente preoccupato per le scadenze e gli incontri, quindi non mi è più piaciuto. Non goderti il ​​tuo lavoro è il percorso per smettere. Inoltre, il grafico burn-down può essere un sorprendente demotivatore quando uno sprint sta andando male.
orfdorf

3
Voglio dire che c'è una grande varietà di differenze tra le aziende che ho visto usare il termine scrum. Per le organizzazioni più pure, Scrum significa che fissano i loro risultati finali, consegnano in tempo e fanno molta pianificazione per assicurarsi che funziona in questo modo. Per le organizzazioni meno pure, Scrum significa che devi consegnare ogni due settimane, i requisiti sono costantemente in evoluzione e ogni mattina ricevi una riunione di microgestione. Direi che l'ultima versione di Scrum si verifica più spesso del primo e causa il burnout sopra descritto molto più velocemente.
Edwin Buck

14

Ti stai esaurendo dopo 36 settimane di duro lavoro; non è Scrum, è la natura umana! Scrum non è lì per farti lavorare di più, è lì per aiutarti a lavorare in modo più coerente e con maggiore prevedibilità. Vedo spesso persone che confondono i sintomi della normale gestione del progetto con ciò che percepiscono come sintomi di metodologie agili (cioè "il cliente continua a cambiare i requisiti - deve essere colpa di Scrum!"). È una distinzione importante però perché senza identificare la causa non è possibile trattare i sintomi. Personalmente cercherò dei modi per ridurre il burnout, come le tecniche di gestione dello stress. Ci sono un sacco di informazioni là fuori su come avere successo in un ambiente stressante.


11

Il team su cui sto attualmente lavorando risolve questo problema molto bene. Dopo tre sprint abbiamo una settimana in cui ogni sviluppatore può lavorare su ciò che vuole. Questi progetti collaterali dovrebbero essere collegati al valore aziendale, ma non c'è alcuna pressione per portarli a termine. È una misura che consente a noi sviluppatori di esplorare nuove tecnologie, ma ci offre anche una settimana di lavoro più rilassato e divertente.

Questo di sicuro mi aiuta a non bruciarmi.


10

Non importa quale processo di sviluppo stai usando, se il team si sta esaurendo qualcosa non va. Potrebbe essere semplice come le persone che non si prendono le ferie di cui hanno bisogno, o potrebbe essere nei dettagli di come gestisci i tuoi mischie. I team sono efficaci a lungo termine perché tutti hanno il resto di cui hanno bisogno lungo il percorso.


10

Uno Sprint non è uno scatto di 100 yard; è un miglio (casuale) in una maratona, cioè un ritmo che puoi sostenere indefinitamente.

Il tuo team sta conducendo retrospettive alla fine di ogni Sprint? Questa è l'opportunità per il Team di "ispezionare e adattare" il proprio processo? In qualità di ScrumMaster, chiedo regolarmente al Team di valutare come il Team come entità "si sente" e se si sta divertendo. Esploriamo perché o perché no e sperimentiamo aggiustamenti e alternative.

Nella mia esperienza, i membri del team godono (fino a un limite) della "pressione" che il timebox Sprint limita. La chiave è avvicinarsi, ma non superare, quella zona. Se necessario, calibrare quella zona è un punto di controllo fondamentale in una retrospettiva.

Per quanto riguarda "... il tempo in un ambiente Scrum non assegnato / non tracciato per fare alcune cose minori e per schiarirsi le idee", mantenere l'impegno del Team al x% della capacità disponibile (punti, preferibilmente, ma le ore possono essere utilizzate se necessario; in entrambi i casi ho trovato che qualcosa nella gamma del 60-70% sembra la norma) è la chiave per la sostenibilità all'interno di uno Sprint, e un occasionale "giorno di codice gratuito" funziona bene per gli Sprint esterni.


21
Forse allora non dovrebbero chiamarlo Sprint, eh? Dovrebbero chiamarlo un giro.
Alex Baranosky,

4
Sono convinto che lo chiamino Sprint per impedire alle persone esterne alla squadra di interferire. Uno Sprint suona come qualcosa che non dovresti interrompere.
Paul Tevis

Un giro non implica alcun obiettivo, è solo uno dei tanti altri, uno sprint definisce una "corsa verso un obiettivo" che in sprintdefinitiva è. La terminologia è corretta IMHO
Jakub

2
Usa semplicemente "iterazione". Per la maggior parte di noi, i termini sono già sinonimi, ma "iterazione" non ha tutta la connotazione "corsa fino a che non si esaurisce".
mindcrime

8

Una soluzione è ridurre il numero di ore della giornata trascorse sullo sprint.

Conosco alcune persone le cui giornate lavorative consistevano in sole due ore e mezza di sprint, con il resto della giornata concentrato su una serie di altre attività: supporto, alleggerimento del debito tecnico, ricerca, ecc. La loro velocità di sviluppo è stata impostata di conseguenza.

Può sembrare un po 'estremo, ma se non mi sbaglio era un'azienda redditizia fino a quando non ha colpito il recente shock economico diffuso.


1
Penso che in questo momento siamo fissati a 6 ore di sprint al giorno. Forse è solo un po 'troppo.
mmcdole

Potrebbe non sembrare molto, ma trovo che sia una corda abbastanza tesa da camminare. Se durante il giorno non emergono problemi reali, puoi mantenerlo bene, ma se incontri un intoppo distrugge la tua velocità per quel giorno.
mmcdole

Il mio team pianifica sulla base di 5 ore produttive al giorno. E TBH penso che 4,5 ore probabilmente ci andrebbero meglio. Quindi penso che 6 ore produttive al giorno siano molte.
John Rayner

6

Sei al tuo 18esimo sprint !?

Considerando 2 settimane per sprint, ciò significa 36 settimane di lavoro continuo allo stesso progetto. Commentate anche che lavorano circa 6 ore al giorno. Sembra molto!

Non so molto sulle metodologie agili (anche se in realtà stiamo usando Scrum nel nostro progetto attuale), ma c'è un principio sul tuo orario di lavoro (voglio dire, la quantità di tempo che dedichi a un'attività) dovrebbe essere del 60% ~ 70%. Ora, facendo di nuovo i numeri, se la tua giornata di lavoro dura 8 ore e trascorri 6 ore a lavorare, stai davvero spendendo circa il 75% del tuo tempo di lavoro. Questa potrebbe essere una piccola deviazione che ti ha finalmente fatto provare quella sensazione.

OTOH, credo che se il tuo progetto richiederà molto tempo per essere realizzato, gli sprint dovrebbero essere più grandi, non 2 settimane, ma non un mese. Considera una curva verso il basso sul grafico del burnout: inizia lo sprint con un normale compito bruciato e riduci l'attività negli ultimi 2 o 3 giorni prima della fine dello sprint.

Agile non è una pietra con l'incisione: "lavora più velocemente / più forte / meglio / più duramente", è più simile a un cielo blu con nuvole bianche che dicono: "lavoro bello, bello più produttivo". (un po 'di lol alla fine per gentile concessione di daft punk + radiohead).


6

Capisco perfettamente cosa stai dicendo. Per quelli di voi che dicono "il vostro ritmo è troppo veloce", non sono sicuro di essere d'accordo sul fatto che il ritmo sia sempre il problema quando le persone si esauriscono a causa di questo processo. Anche se tenere traccia di tutti i tuoi progressi È una buona cosa, può anche essere un fattore di stress (e anche non tenerne traccia), non solo perché il tuo capo / PM sarà su di te se vede che qualcosa non sta andando secondo i piani, ma per te stesso. Il solo fatto di avere queste informazioni registrate è qualcosa che farà lavorare la maggior parte delle persone solo un po 'più duramente di quanto faresti normalmente TUTTO IL TEMPO e non sono sicuro che dedicare più tempo alle tue stime di tempo risolverà questo per tutti. Non penso che un motivatore (come il tuo grafico bruciato) sia sempre positivo.

Alcune persone non si sentiranno in questo modo, altre sì. Non c'è UN solo modo di lavorare che si adatta a tutti. Non lo sarà mai, secondo me.

Inoltre, se dici che questi metodi e sprint agili non stanno diventando più efficaci / produttivi, perché lo stai usando? Perché pensi che le aziende vogliano utilizzare questi metodi? Non è perché sono divertenti ...

L'efficacia / produttività ha sempre un prezzo, secondo me. Non si apre dal nulla solo usando i metodi magici (se ottieni il mio punto).

L'unico modo per diventare più efficace (in termini di lavoro e di pressione) e fare meno lavoro è far fare il lavoro a qualcun altro o automatizzarlo.

A mio parere, si dovrebbe sempre rivedere i propri processi e vedere cosa può essere automatizzato e dedicare del tempo all'automazione dei processi. L'automazione ha il prezzo di fare un lavoro extra invece di fare "il vero lavoro", ma non importa quanto piccolo sia il compito automatizzato, ne trarrai sempre profitto nel lungo periodo. SEMPRE! Se non un giorno, in due. Non un mese, due. Non un anno, in due anni. Hai avuto l'idea.

Tuttavia, mi piace l'idea di avere del tempo libero per lavorare su progetti personali. Tuttavia, la maggior parte delle aziende non lo consentirà mai. Ma forse puoi convincere il tuo datore di lavoro a ottenere questo tempo per automatizzare i tuoi processi e questo lavoro potrebbe essere "al di fuori del controllo dello sprint" per consentire al tempo di cui parli di "riposare" e recuperare le energie per un nuovo sprint.

Quelli erano solo i miei 2 centesimi. Mi spavento un po 'quando le persone dicono che questi metodi non sono qui per renderci più efficaci e lavorare di più. Certo che lo sono! Quando non hai traccia di quello che stai facendo, riposerai quando il tuo corpo te lo dirà. Quando "tutto" che fai è tracciato, ti spingerai oltre. Oppure mi correggo, la maggior parte delle persone lavora in questo modo, alcune si riposeranno comunque.


2

Il ritmo sostenibile è un principio fondamentale dell'agile. Quando si eseguono le pratiche di gestione (SCRUM) insieme alle pratiche di ingegneria (XP), un team può fornire sprint dopo sprint a tempo indeterminato. Tuttavia, poiché si può non significa che si dovrebbe.

Sembra che tu abbia bisogno di un cambiamento rispetto alla serie infinita di sprint che vedi davanti a te. Possono essere offerte numerose opzioni. Ogni X numero di sprint, un membro del team (o una coppia) può uscire da un team. Durante la rotazione, puoi supportare la squadra di corsa, prendere una lezione, concentrarti su una serie di picchi, prendere una vacanza ecc.

Se la squadra ha 5 coppie, e fai ruotare una persona fuori dalla linea, una persona potrebbe effettuare una rotazione ogni 10 sprint (se una singola persona) o ogni 5 iterazioni (se una coppia). I problemi di budget e ritorno sull'investimento per le tue attività dovranno essere affrontati dalla tua leadership e / o dal partner commerciale. Ma chiaramente, avere un po 'di tempo per "affilare la sega" porterebbe beneficio al team, quindi il progetto. Mantenere la squadra fresca e concentrata è un'ottima cosa. Ma dobbiamo ricordare che veniamo pagati e dobbiamo portare valore per i dollari che guadagniamo.


3
Forse allora non dovrebbero chiamarlo Sprint, eh? Dovrebbero chiamarlo un giro.
Alex Baranosky

2

Penso che ti manchi qualcosa, ma non sei l'unico. Come dice Jim Highsmith: "La velocità viene sempre più utilizzata come misura di produttività (non la misura di calibrazione della capacità che avrebbe dovuto essere) che concentra troppa attenzione sul volume di story point forniti".

Immagino sia quello che sta succedendo alla tua squadra. Consiglio di leggere questo seminale post IMHO di Highsmith: Velocity is Killing Agility!

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.