Ab in den Burnout, aber mit Methode! Was nach dem besten Ansatz aller Zeit in der Softwareentwicklung klingt, kann zu ganz schön vielen Problemen führen. Agile ist nämlich nicht nur gut für Projekte, sondern erhöht unter Umständen auch das Burnout-Risiko der beteiligten Mitarbeiter.

Man kann also agil ausbrennen? Wer das nicht glaubt, möge einen Moment innehalten. Natürlich ist nicht jede Implementierung agiler Methoden dafür prädestiniert, die damit arbeitenden Projektteams in den Burnout zu schicken. Dennoch hat auch die agile Arbeitsweise bestimmte Merkmale, die zum Risiko für den Burnout werden können.

Agile als eierlegende Wollmilchsau

Das hat  verschiedene Gründe. Fangen wir einmal mit dem Erfolg agiler Projekte an: Woran wird dieser Erfolg gemessen? Ganz einfach: Schnell fertig muss das Projekt sein und dabei gleich noch ohne Bugs ausgeliefert werden! Das zeigt der State of Agile Report Jahr für Jahr. In der gegenwärtig zehnten Auflage der großen Anwender-Befragung von VersionOne liegt die pünktliche Auslieferung des Produkts in der Liste der beliebtesten Erfolgsmetriken vor der hohen Produktqualität in Führung. Und danach kommt gleich noch die Zufriedenheit des Kunden. Wie soll man das bloß unter einen Hut bekommen?

Die Wahrheit ist: Das geht nicht. Auch Agile kann entweder zu schnelleren Ergebnissen führen oder dazu, dass die Produktqualität steigt. Wer beides will, muss der Realität ins Auge blicken – oder lässt seine Entwickler ausbrennen. Diese Erkenntnis spiegelte sich ja auch schon im ersten Teil dieser Artikelserie, Burnout in der IT, wieder: Etwa ein Viertel der für den Index „Gute Arbeit“ des DGB befragten IT-Fachkräfte gab an, häufig aufgrund von Zeitmangel Abstriche bei der Qualität ihrer Arbeit machen zu müssen.

Tägliche Bewertungsmöglichkeiten: Velocity für den Burnout

Wer nun glaubt, dass das alles gar nicht so schlimm ist, weil kein Team jemals die Ansprüche seines Managers erfüllen kann, sollte im 10th State of Agile Survey jedoch weiterlesen: Auf Ebene der täglichen Bewertung des Projekterfolgs steht die Velocity im Zentrum der Aufmerksamkeit: Ist das Team schnell genug? Arbeitet es das Product-Backlog mit einer gleichbleibend hohen Geschwindigkeit ab? Das ist offenbar der wichtigste Maßstab dafür, wie gut agil arbeitende Teams sind.

Addieren wir nun noch einen Mikromanager hinzu, haben wir beste Bedingungen für hohe Burnout-Quoten. Niemand ist nämlich an jedem Arbeitstag gleich schnell. Und keine Aufgabe gleicht der Anderen, sodass die Vergleichbarkeit leidet – zumal Feature Points ein relatives Maß darstellen. Sie richten sich nach der Komplexität der Aufgabe, die nicht immer im Vorfeld einschätzbar ist.

Die Velocity sollte also lieber nur zur langfristigen Beurteilung der Entwicklung der Teamleistung verwendet werden, nicht, um die Leistung des einzelnen Entwicklers täglich zu bewerten. Sonst droht ungesunder Stress; Angst vor negativen Konsequenzen nach schlechten Tagen tut niemandem gut. Wer dauerhaft in der Sorge arbeitet, dass er für einen Tag abgestraft werden könnte, an dem es ihm einfach nicht so gut ging, gerät schnell in den Burnout-Teufelskreis. Das könnte allerdings häufiger vorkommen als man annehmen würde, wenn Velocity doch der wichtigste Maßstab für die Bewertung agil umgesetzter Projekte ist.

Agile gone wrong?

Natürlich lässt sich nun einwenden, dass das alles ja dafür spricht, dass Agile in solchen Fällen einfach falsch verstanden wird und die Probleme nichts mit Agile an sich zu tun haben. Tatsächlich ist das häufig der Fall: Wenn der Manager erwartet, dass Agile ins gelobte Land der Softwareentwicklung führt, ist die Implementierung agiler Methoden von Anfang an zum Scheitern verurteilt. Und auch Mikromanager können agile Projekte bekanntlich im Alleingang gegen die Wand fahren. Ist es also wirklich die agile Arbeitsweise, die zum Burnout ihrer Mitarbeiter beiträgt?

Auch jenseits aller anti-agilen Polemik lassen sich einige Faktoren identifizieren, die fest zur agilen Arbeitsweise gehören und doch die Entstehung von Burnouts begünstigen. Lange To-Do-Listen und das Gefühl, nie alle anstehenden Aufgaben bewältigen zu können, gehören dazu. Außerdem kann die ewige iterative Arbeit zur sogenannten „Scrum Fatigue“ führen.

Backlogs für den Burnout

Realistische To-Do-Listen sind durchaus hilfreich gegen Prokrastination und andere Hürden im Arbeitsalltag. Das Problem ist aber, dass To-Do-Listen häufig falsch verwendet werden. Werden Aufgaben nur grob beschrieben, verunsichern sie viele Menschen und werden nach hinten geschoben; wächst die Liste parallel immer weiter an, droht der Frust. Hier entsteht psychologisch gesehen ein Schuldgefühl, das in vielen Fällen unberechtigt ist: Man sieht den Berg unerledigter Aufgaben; aber nicht, was bereits geschafft ist. Agile mit seinem ewigen Entwicklungskreislauf ist dazu prädestiniert, solche Probleme auszulösen.

Besonders problematisch ist das, wenn Entwickler zu wenig Einfluss darauf haben, was auf ihrer To-Do-Liste landet. Das gilt sowohl für den stetigen Nachschub, gegen den sie sich oft nicht wehren können, als auch für die Art der Aufgaben. Jeder Entwickler macht bestimmte Dinge lieber und auch, wenn wohl niemand im Berufsalltag nur seiner bevorzugten Tätigkeit nachgehen kann, muss auch das in kreativen Jobs wie dem des Entwicklers von Zeit zu Zeit möglich sein. Sonst sinkt die Motivation.

Die Prioritäten in der agilen Softwareentwicklung werden jedoch vom Product Owner festgelegt – und was der Kunde sich gerade wünscht, muss erledigt werden, egal ob es Spaß macht. Wird hier nicht darauf geachtet, Entwicklern trotzdem auch spannende Herausforderungen und gelegentlich mal ein paar Lieblingsaufgaben ohne Zeitdruck zu überlassen, droht die Erschöpfung.

Scrum Fatigue

Auf Teamebene existiert außerdem der sogenannte Scrum Fatigue. Der Begriff wird von Gavin Coughlan benutzt, um zu beschreiben, was passiert, wenn Scrum-Teams ihren Antrieb verlieren. Werden die Meetings immer unproduktiver, ist das Backlog unklar definiert, fehlte es an Erfolgserlebnissen, befindet sich das Scrum-Team auf dem Weg in die Krise und nimmt das Produkt gleich mit. Dann kann die agile Arbeitsweise auf Teamebene zu einer Art Mini-Wasserfall verkommen: Man befolgt alle agilen Regeln, arbeitet aber eigentlich einen lange im Voraus feststehenden Plan ab. Das nimmt dem gesamten Team die Motivation.

Wenn sich dann Teammitglieder an unklaren Anforderungen abarbeiten, während Sprint-Ziele regelmäßig verfehlt werden, wirkt sich das natürlich auch auf die einzelnen Teammitglieder aus. Sie verlassen das Team, wie Coughlan beschreibt – oder brennen aus. Hier gilt wieder der Grundsatz, dass diejenigen besonders gefährdet sind, die für das Projekt brennen.

Wer nämlich bereit ist, 110 Prozent zu leisten, während das Projekt auf dem absteigenden Ast ist, verausgabt sich schnell. Immerhin ist hier die Einschätzung, einfach nichts produktives mehr zu leisten, in der Regel sogar korrekt – leidet das Team unter Scrum Fatigue, ist das Projekt zum Scheitern verurteilt.

ScrumBut

Auch unter dem Begriff ScrumBut findet sich darüber hinaus so mancher Ansatz, der typischerweise dazu beiträgt, Mitarbeiter agil in den Burnout zu schicken. ScrumBut steht für „We use Scrum, but…“ – also die Einschränkung dessen, welche Teile des Frameworks adaptiert werden. Fehlt es beispielsweise am positiven Feedback in der Retrospektive oder an der Fehlertoleranz, entsteht daraus Stress für die Mitarbeiter, weil sie agil arbeiten sollen, ohne sich auf wichtige Elemente der Methodik stützen zu können. Gute Leistungen dürfen beispielsweise nicht für selbstverständlich gehalten werden, sondern müssen erwähnt werden. Nur das hält die Motivation hoch und hilft Mitarbeitern dabei, ihre Erfolge wahrzunehmen.

Auch dabei handelt es sich aber natürlich wieder um eine fehlerhafte Implementierung der agilen Methodik. Die agile Fatigue kann hingegen grundsätzlich jedes Team befallen, das nicht auf die Anzeichen achtet; auch der Wegfall positiven Feedbacks passiert im Arbeitsalltag ganz schnell, wenn das Backlog endlos anwächst. Und ständig wechselnde Anforderungen, beispielsweise bei der Arbeit mit unentschlossenen Kunden, gehören ebenfalls zu den Faktoren, die das Ausbrennen von Mitarbeitern begünstigen.

Agil in den Burnout?

Wer Agile richtig macht, kann also viele Fehler vermeiden, die zum Burnout agiler Teams führen können, allerdings nicht alle vorgenannten Probleme vollständig ausmerzen. So gehören Last-Minute-Änderungen an die Anforderungen häufig zum Arbeitsalltag agiler Teams und lassen sich nicht vermeiden – in dieser Hinsicht ist Agile dann einfach stärker auf das Produkt als auf die Menschen dahinter ausgelegt. Auch das Abarbeiten von Backlog-Items in der „richtigen“ Reihenfolge muss sein. Andere Aspekte lassen sich mit genug Aufmerksamkeit vermeiden.

So oder so kann ein Job in der IT-Branche aber stressig werden – um bei Dauerstress den Burnout zu vermeiden, können allerdings persönliche Strategien heranzogen werden, die wir im dritten Teil dieser Artikelserie verraten.