Kann Burnout auftreten, wenn Scrum-Sprints kontinuierlich durchgeführt werden? [geschlossen]


92

Ich habe ein ziemlich kleines Startup und wir haben angefangen, eine Form eines Scrum / Agile-Entwicklungszyklus zu verwenden.

In vielerlei Hinsicht mag ich Scrum. Wir haben relativ kurze Sprints (2 Wochen) und ich mag die Burn Down Chart, um den Fortschritt des Teams zu verfolgen. Ich mag auch das Feature Board, damit ich immer weiß, was ich als nächstes tun soll. Es fühlt sich gut an, die Karte eines Features vom Brett zu nehmen, sie zu vervollständigen und sie dann auf den Abbrennstapel zu legen.

Wir treten jedoch jetzt in unseren 18. Sprint-Veröffentlichungszyklus ein und ich fühle mich ein wenig ausgebrannt. Es ist nicht so, dass ich keinen Job oder meine Kollegen mag, es ist nur so, dass diese Sprints ... nun, Sprints sind . Von Anfang bis Ende habe ich buchstäblich das Gefühl, gegen die Uhr zu rennen, um unsere Entwicklungsgeschwindigkeit aufrechtzuerhalten. Wenn wir mit dem Sprint fertig sind, verbringen wir einen Tag damit, die Funktionen und Schätzungen des nächsten Sprints zu planen, und dann geht es wieder los.

Ist dies für Menschen, die in einem ausgereiften Agile / Scrum-Entwicklungsprozess arbeiten, normal? Oder fehlt uns etwas? Gibt es normalerweise Zeit in einer Scrum-Umgebung, die nicht zugewiesen / nicht verfolgt ist, um einige kleinere Dinge zu erledigen und den Kopf frei zu bekommen?


Ich würde mir den Inhalt des Sprints genauer ansehen als die Methodik. Reine Entwicklung (keine Tests, Spikes, Codeüberprüfungen) kann nach einer Weile Menschen töten. Außerdem sollte der Scrum Master das Team gegen unangemessene Roadmaps, Zeitschätzungen des Teams usw. verteidigen. Achten Sie bei der Berechnung der Verfügbarkeit darauf, dass Sie 10 bis 20% nicht festgelegte Zeiten berücksichtigen, um ungeplante Besprechungen, Toilettenpausen, Ablenkungen usw. Zu berücksichtigen Dann planen Sie alles während der Zeremonien. Am Ende gleicht sich alles aus.
Sinaesthetic

12
Wenn dies nicht konstruktiv ist, wo im Stackexchange-Ökosystem würde es sich am besten befinden?
Ryan Schultz

2
Vielleicht programmers.stackexchange.com ... nicht sicher.
Kevin Krumwiede

21
Frage mit 53 positiven Stimmen. Akzeptierte Antwort mit 49. Geschlossen als nicht konstruktiv. Offensichtlich haben einige selbstgerechte "Moderatoren" die Einnahme ihrer Medikamente eingestellt. Nochmal.
SzG

Stimmen Sie zu, die Frage
betrifft die

Antworten:


68

Dies ist relativ normal und kann manchmal eine Beschwerde unserer Teammitglieder sein, wenn Projekte über einen längeren Zeitraum fortgesetzt werden.

Der Schlüssel zu dem, worüber wir hier sprechen, ist nachhaltiges Tempo . Wenn Sie und Ihr Team in der Lage sind, Ihr Tempo langfristig aufrechtzuerhalten, ist das hervorragend - Sie erreichen die Hyperproduktivität, die alle Scrum-Teams anstreben.

Wenn Sie feststellen, dass Sie überschätzen, wie viel Arbeit Sie tatsächlich an einem Tag erledigen können, müssen Sie dies möglicherweise während Ihrer Retrospektive neu bewerten. Die Menge der produktiven Zeit an einem Tag , dass ein Team wählt zu erkennen , wenn ihre Kapazitätsplanung zu tun für einen Sprint als bezeichneten Fokus Faktor .

Henrik Kniberg hat folgendes zu sagen:

Der „Standard“ -Fokusfaktor, den ich für neue Teams verwende, beträgt normalerweise 70%, da dort die meisten unserer anderen Teams im Laufe der Zeit gelandet sind.

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

Es hört sich jedoch so an, als würden Sie über die ununterbrochene Dynamik von Sprint nach Sprint sprechen, nicht unbedingt über Ihre Produktivität an einem Tag. Hier sind einige Vorschläge von Dingen, mit denen wir versucht haben, umzugehen:

  • Beende den Sprint an einem Freitagmorgen. Lassen Sie Ihren Sprint am Morgen überprüfen und einen Rückblick geben und lassen Sie das Team den Rest des Tages an etwas anderem arbeiten, um den Kopf frei zu bekommen. Abholung mit der Sprint-Planung am Montag.
  • Wir haben den Begriff "Labortage" eingeführt. Dies sind ganze Tage, an denen das Team aus dem Projekt herausgenommen wird, und sie verbringen den Tag damit, ihre eigenen technischen Fähigkeiten durch gegenseitige Forschung und Zusammenarbeit bei bestimmten technischen Themen zu verbessern. Meistens haben sie absolut nichts mit dem spezifischen Projekt zu tun und ermöglichen es den Teammitgliedern, über leichtere Themen nachzudenken.

3
Kniberg sagte sich: "Fokusfaktor ist eines der Dinge, die ich aus dem Buch herausreißen möchte. Ich habe es direkt nach dem Schreiben des Buches nicht mehr verwendet ..." - twitter.com/henrikkniberg/status/207853426967715841
MPV

24

Aus Wikipedia zum Thema Burnout: "Burnout ist größtenteils ein organisatorisches Problem, das durch lange Arbeitszeiten, geringe Ausfallzeiten und kontinuierliche Überwachung durch Kollegen, Kunden und überlegene Mitarbeiter verursacht wird."

Sie könnten genauso gut ein Symbolbild von Scrum neben der Definition von Burnout haben.

Wenn Sie glauben, Sie könnten jemanden für eine kurze Ablenkung auf etwas anderes schicken, um Burnout zu beheben, haben Sie es offensichtlich nicht durchdacht. Machen Sie jemals Urlaub, nachdem Sie ausgebrannt sind, und machen Sie sich wieder an die Arbeit und denken Sie: Wow! Jetzt bin ich erfrischt und bereit für weitere 6 Monate dieser Folter, bis ich endlich wieder eine Pause bekomme. Nein, was passiert ist, dass du realisierst, Wow! Mein Job ist scheiße. Jetzt kann ich wirklich sehen, wie der Mikromanagement- und Entwicklungsprozess meines dummen Managers nur ein weiterer Weg ist, um mehr für weniger aus mir herauszuholen, und das Leben ist zu kurz dafür ... Ich sollte etwas anderes finden, um etwas zu tun oder Jobs in etwas weniger Stressiges umzuwandeln .

IMHO, kurze 2 Wochen Scrum sollte verboten werden, außer in kleinen Dosen, nicht mehr als 4-8 hintereinander. Verwenden Sie es als Werkzeug für außergewöhnliche oder kritische Dinge, nicht ständig. Verwenden Sie gesunden Menschenverstand.


3
Das ist lächerlich FUD, bei Scrum geht es sicherlich nicht darum, dass Leute ausgebrannt werden, bei kurzen Sprints geht es nicht darum, 80 pro Woche zu arbeiten.
Pascal Thivent

7
Das ist genau richtig. Es ist lustig, wie die Scrum-Liebhaber es mit dem Märchen verteidigen, wie es "gemacht" werden soll, aber die meisten Entwickler erfahren genau, worüber das OP spricht.
Kirk.burleson

2
Ich habe dies in den letzten Jahren erkannt und stimme voll und ganz dem zu, was hier gesagt wurde. Ich bin verzweifelt daran, so nicht mehr zu arbeiten, auch wenn es bedeuten könnte, für eine Weile ein Penner zu sein und Einsparungen zu erzielen. Ganz zu schweigen von dem gefürchteten "Aufstehen" jeden Morgen. Ich wache auf und wünschte, ich wäre irgendwo anders und ich arbeite daran, dies Wirklichkeit werden zu lassen.
Fähigkeit M2

5
Scrum verursacht für mich Burnout. Die Anzahl der Stunden, die ich arbeite, und die Produktivität, die ich habe, ändern sich nicht, aber meine Stimmung. Ohne Scrum habe ich meine Arbeit erledigt und fühlte mich gut dabei. Als wir den Scrum-Prozess hinzufügten, erledigte ich die gleiche Arbeit im gleichen Tempo, machte mir aber ständig Sorgen über die Fristen und Besprechungen, sodass ich sie nicht mehr genoss. Wenn Sie Ihre Arbeit nicht genießen, können Sie aufhören. Das Burn-Down-Diagramm kann auch ein erstaunlicher Demotivator sein, wenn ein Sprint schlecht läuft.
Orfdorf

3
Ich möchte sagen, dass es einen großen Unterschied zwischen den Unternehmen gibt, die den Begriff Scrum verwendet haben. Für die reinsten Organisationen bedeutet Scrum, dass sie ihre Ergebnisse korrigieren, pünktlich liefern und viel planen, um dies sicherzustellen Das funktioniert so. Für die am wenigsten reinen Organisationen bedeutet Scrum, dass Sie voraussichtlich alle zwei Wochen liefern, die Anforderungen ständig im Fluss sind und Sie jeden Morgen ein Mikromanagement-Meeting erhalten. Ich würde sagen, dass die letztere Version von Scrum stattfindet häufiger als die erstere und verursacht den oben beschriebenen Burnout viel schneller.
Edwin Buck

14

Sie werden nach 36 Wochen harter Arbeit müde; das ist nicht Scrum, das ist die menschliche Natur! Scrum ist nicht dazu da, Sie härter arbeiten zu lassen, sondern Ihnen dabei zu helfen, konsistenter und vorhersehbarer zu arbeiten. Ich sehe oft Leute, die die Symptome des normalen Projektmanagements mit den Symptomen agiler Methoden verwechseln (dh „der Kunde ändert ständig die Anforderungen - es muss Scrums Schuld sein!“). Dies ist jedoch eine wichtige Unterscheidung, da Sie die Symptome nicht behandeln können, ohne die Ursache zu identifizieren. Persönlich würde ich nach Möglichkeiten suchen, Burnout zu reduzieren, wie z. B. Techniken zur Stressbewältigung. Es gibt jede Menge Informationen darüber, wie man in einem stressigen Umfeld erfolgreich sein kann.


11

Das Team, an dem ich gerade arbeite, löst dieses Problem sehr gut. Nach drei Sprints haben wir eine Woche, in der jeder Entwickler an dem arbeiten kann, was er will. Diese Nebenprojekte sollten mit dem Geschäftswert verknüpft sein, aber es besteht kein Druck, dies zu erreichen. Es ist eine Maßnahme, die es uns Entwicklern ermöglicht, neue Technologien zu erforschen, aber es bietet uns auch eine Woche entspannter und unterhaltsamer Arbeit.

Dies hilft mir sicher, nicht ausgebrannt zu werden.


11

Ein Sprint ist kein 100-Yard-Strich. Es ist eine (zufällige) Meile in einem Marathon, dh ein Tempo, das Sie auf unbestimmte Zeit durchhalten können.

Führt Ihr Team am Ende jedes Sprints Retrospektiven durch? Dies ist die Gelegenheit des Teams, seinen Prozess zu "inspizieren und anzupassen"? Als ScrumMaster bitte ich das Team regelmäßig, zu bewerten, wie sich das Team als Einheit "fühlt" und ob es Spaß hat. Wir untersuchen, warum oder warum nicht, und experimentieren mit Anpassungen und Alternativen.

Nach meiner Erfahrung genießen Teammitglieder (bis zu einem gewissen Grad) den „Druck“, den die Sprint-Zeitbox einschränkt. Der Schlüssel besteht darin, sich dieser Zone zu nähern, sie jedoch nicht zu überschreiten. Bei Bedarf ist die Kalibrierung dieser Zone in einer Retrospektive ein Hauptkontrollpunkt.

Was "... Zeit in einer Scrum-Umgebung betrifft, die nicht zugewiesen / nicht verfolgt ist, um einige kleinere Dinge zu erledigen und den Kopf frei zu bekommen", wobei das Team-Engagement bei x% der verfügbaren Kapazität bleibt (Punkte, vorzugsweise, aber Stunden können verwendet werden falls erforderlich (in beiden Fällen habe ich festgestellt, dass etwas im Bereich von 60-70% die Norm zu sein scheint), ist der Schlüssel zur Nachhaltigkeit innerhalb eines Sprints, und ein gelegentlicher "freier Codetag" funktioniert gut für Sprints außerhalb.


20
Vielleicht sollten sie es dann nicht Sprint nennen, oder? Sie sollten es eine Runde nennen.
Alex Baranosky

4
Ich bin überzeugt, dass sie es einen Sprint nennen, um Leute außerhalb des Teams davon abzuhalten, sich einzumischen. Ein Sprint klingt nach etwas, das Sie nicht unterbrechen sollten.
Paul Tevis

Eine Runde impliziert kein Ziel, es ist nur eines von vielen mehr. Ein Sprint definiert einen "Lauf zu einem Ziel", der sprintletztendlich ein Ziel ist. Die Terminologie ist Sound IMHO
Jakub

2
Verwenden Sie einfach "Iteration". Für die meisten von uns sind die Begriffe bereits synonym, aber "Iteration" fehlt die gesamte Konnotation "Laufen, bis Sie vor Erschöpfung tot umfallen".
Gedankenverbrechen

10

Egal welchen Entwicklungsprozess Sie verwenden, wenn das Team ausgebrannt ist, stimmt etwas nicht. Es kann so einfach sein, dass sich die Leute nicht die Urlaubszeit nehmen, die sie brauchen, oder es kann in den Details liegen, wie Sie mit Ihren Scrums umgehen. Teams sind langfristig effektiv, da jeder auf dem Weg den Rest bekommt, den er braucht.


8

Eine Lösung besteht darin, die Anzahl der Stunden am Sprinttag zu reduzieren.

Ich kenne einige Leute, deren Arbeitstage aus nur zweieinhalb Stunden Sprint bestanden, wobei sich der Rest des Tages auf eine Vielzahl anderer Aktivitäten konzentrierte: Unterstützung, Abbau technischer Schulden, Forschung usw. Ihre Entwicklungsgeschwindigkeit wurde entsprechend festgelegt.

Das mag ein bisschen extrem erscheinen, aber wenn ich mich nicht irre, war es ein profitables Unternehmen, bis der jüngste weit verbreitete wirtschaftliche Schock eintraf.


1
Ich denke, im Moment sind wir auf 6 Stunden Sprint pro Tag eingestellt. Vielleicht ist das einfach etwas zu viel.
mmcdole

Es klingt vielleicht nicht nach viel, aber ich finde, dass es ein ziemlich enges Seil zum Laufen ist. Wenn während des Tages keine wirklichen Probleme auftauchen, können Sie es gut halten, aber wenn Sie einen Haken treffen, zerstört es Ihre Geschwindigkeit für diesen Tag.
mmcdole

Mein Team plant auf der Grundlage von 5 produktiven Stunden pro Tag. Und TBH Ich denke, dass 4,5 Stunden wahrscheinlich besser zu uns passen würden. Deshalb denke ich , dass 6 produktive Stunden pro Tag ist eine ganze Menge.
John Rayner

6

Du bist in deinem 18. Sprint!?

Bei 2 Wochen pro Sprint bedeutet dies, dass 36 Wochen ohne Unterbrechung am selben Projekt gearbeitet wird. Sie kommentieren auch, dass die Arbeit ungefähr 6 Stunden pro Tag. Das klingt nach viel!

Ich weiß nicht so viel über agile Methoden (obwohl wir Scrum in unserem aktuellen Projekt tatsächlich verwenden), aber es gibt ein Prinzip für Ihre Arbeitszeit (ich meine, die Zeit, die Sie für eine Aufgabe aufwenden) sollte 60% betragen. ~ 70%. Wenn Sie jetzt wieder Zahlen machen, wenn Ihr Arbeitstag 8 Stunden lang ist und Sie 6 Stunden arbeiten, verbringen Sie wirklich ungefähr 75% Ihrer Arbeitszeit. Dies könnte eine kleine Abweichung sein, die Sie endlich zu diesem Gefühl gebracht hat.

OTOH, ich glaube, wenn Ihr Projekt lange dauern wird, sollten die Sprints größer sein, nicht 2 Wochen, sondern keinen Monat. Betrachten Sie eine Abwärtskurve in Ihrem Burnout-Diagramm: Beginnen Sie Ihren Sprint mit einem regulären Aufgabenbrand und reduzieren Sie Ihre Aktivität in den letzten 2 oder 3 Tagen vor dem Ende des Sprints.

Agile ist kein Stein mit der Gravur: "Arbeite schneller / stärker / besser / härter", es ist eher wie ein blauer Himmel mit weißen Wolken, der lautet: "Arbeite schön, schön, produktiver". (ein wenig lol am Ende mit freundlicher Genehmigung von Daft Punk + Radiohead).


6

Ich verstehe voll und ganz, was du sagst. Für diejenigen unter Ihnen, die sagen "Ihr Tempo ist zu schnell", bin ich mir nicht sicher, ob das Tempo immer das Problem ist, wenn Menschen durch diesen Prozess ausgebrannt werden. Auch wenn es eine gute Sache ist, all Ihre Fortschritte im Auge zu behalten, kann dies auch ein Stressfaktor sein (und es kann auch sein, dass Sie nicht den Überblick behalten), nicht nur, weil Ihr Chef / PM bei Ihnen ist, wenn er sieht, dass etwas nicht läuft nach Plan, aber für sich. Nur diese protokollierten Informationen zu haben, wird die meisten Leute dazu bringen, ein bisschen härter zu arbeiten, als Sie es normalerweise die ganze Zeit tun würden, und ich bin nicht sicher, ob mehr Zeit für Ihre Zeitschätzungen erforderlich ist, um dies für alle zu beheben. Ich denke nicht, dass ein Motivator (wie Ihr Burn-Down-Diagramm) immer positiv ist.

Manche Menschen fühlen sich nicht so, andere nicht. Es gibt keine Arbeitsweise, die allen passt. Das wird meiner Meinung nach niemals sein.

Wenn Sie sagen, dass diese agilen Methoden und Sprints nicht effektiver / produktiver werden, warum verwenden Sie sie überhaupt? Warum wollen Unternehmen diese Methoden Ihrer Meinung nach überhaupt anwenden? Es ist nicht, weil sie Spaß machen ...

Effektivität / Produktivität hat meiner Meinung nach immer einen Preis. Es taucht nicht aus dem Nichts auf, nur mit den magischen Methoden (wenn Sie meinen Standpunkt verstehen).

Der einzige Weg für Sie, effektiver zu werden (Arbeit und Druck) und weniger Arbeit zu erledigen, besteht darin, jemanden die Arbeit erledigen zu lassen oder sie zu automatisieren.

Meiner Meinung nach sollte man immer die eigenen Prozesse überprüfen und herausfinden, was automatisiert werden kann, und stattdessen Zeit für die Automatisierung Ihrer Prozesse aufwenden. Automatisierung kostet zusätzliche Arbeit, anstatt "die eigentliche Arbeit" zu erledigen, aber egal wie klein die automatisierte Aufgabe ist, von der Sie auf lange Sicht immer profitieren werden. IMMER! Wenn nicht eines Tages, in zwei. Nicht einen Monat, zwei. Nicht ein Jahr, in zwei Jahren. Du hast die Idee.

Ich mag jedoch die Idee, frei zu haben, um an persönlichen Projekten zu arbeiten. Die meisten Unternehmen werden dies jedoch niemals zulassen. Aber vielleicht können Sie Ihren Arbeitgeber davon überzeugen, diese Zeit für die Automatisierung Ihrer Prozesse zu nutzen, und diese Arbeit könnte "außerhalb der Sprintkontrolle" liegen, damit sich die Zeit, über die Sie sprechen, "ausruhen" und Energie für einen neuen Sprint zurückerhalten kann.

Das waren nur meine 2 Cent. Ich habe ein bisschen Angst, wenn Leute sagen, dass diese Methoden nicht dazu da sind, uns effektiver zu machen und härter zu arbeiten. Natürlich sind sie! Wenn Sie keine Spur von dem haben, was Sie tun, werden Sie sich ausruhen, wenn Ihr Körper es Ihnen sagt. Wenn "alles", was Sie tun, verfolgt wird, werden Sie sich selbst schieben. Oder ich korrigiere mich, die meisten Leute arbeiten so, manche ruhen sich trotzdem aus.


2

Nachhaltiges Tempo ist ein zentraler Grundsatz für Agilität. Wenn ein Team die SCRUM-Praktiken zusammen mit den XP-Praktiken ausführt, kann ein Team Sprint für Sprint auf unbestimmte Zeit liefern. Aber weil man kann, heißt das nicht, dass man sollte.

Es hört sich so an, als müssten Sie sich gegen die endlosen Sprints ändern, die Sie vor sich sehen. Eine Reihe von Optionen kann angeboten werden. Bei jeder X-Anzahl von Sprints kann sich ein Teammitglied (oder Paar) aus einem Team herausdrehen. Während Ihrer Rotation können Sie das Laufteam unterstützen, eine Klasse besuchen, sich auf eine Reihe von Spikes konzentrieren, Urlaub machen usw.

Wenn das Team 5 Paare hat und Sie eine Person von der Linie drehen, kann eine Person jeden 10. Sprint (wenn eine einzelne Person) oder jede 5. Iteration (wenn ein Paar) eine Off-Rotation durchführen. Fragen des Budgets und des Return on Investment für Ihre Aktivitäten müssen von Ihrer Führung und / oder Ihrem Geschäftspartner behandelt werden. Aber klar, etwas Zeit zum "Schärfen der Säge" zu haben, würde dem Team und damit dem Projekt Vorteile bringen. Das Team frisch und konzentriert zu halten, ist eine sehr gute Sache. Aber wir müssen uns daran erinnern, dass wir bezahlt werden und Wert für die Dollars bringen müssen, die wir verdienen.


3
Vielleicht sollten sie es dann nicht Sprint nennen, oder? Sie sollten es eine Runde nennen.
Alex Baranosky

2

Ich denke, Sie vermissen etwas, aber Sie sind nicht der einzige. Wie Jim Highsmith sagt: "Geschwindigkeit wird zunehmend als Produktivitätsmaß verwendet (nicht als beabsichtigtes Kapazitätskalibrierungsmaß), das zu viel Aufmerksamkeit auf das Volumen der gelieferten Story Points richtet."

Ich denke, genau das passiert mit Ihrem Team. Ich empfehle, diesen wegweisenden IMHO-Beitrag dieses Highsmith zu lesen: Geschwindigkeit tötet Beweglichkeit!

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.