Mit Scrum in den Burnout?

Campfire on shi shi beach in Olympic national park

Wenn moderne Ideen, Frameworks oder auch Produkte an Popularität gewinnen, dann weichen im Laufe der Zeit einige Interpretationen sehr schnell vom Ursprung ab. Leider. Dann kommt es zu kausalen Verbindungen und Irrtümern die nicht der Grundidee entsprechen.

Was schade ist, denn es wird dem Werkzeug an sich nicht gerecht. Gleichzeitig sind Missverständnisse oder Vorbehalte vorprogrammiert. Denken Sie an ein Hilfsmittel, an ein Werkzeug. Vielleicht an Ihr Auto oder ein Messer in der Küche.

Sie können mit dem Messer schneiden oder mit dem Auto von A nach B fahren. Viele Menschen tun das, gewinnen an Mobilität, können somit komfortabel an die Arbeit fahren, Freunde besuchen oder ein leckeres Essen zubereiten. Daneben kann man mit einem Messer auch andere verletzen oder sich in den Finger schneiden oder mit dem Auto in die Fußgängerzone fahren und Menschen verletzen. Das geht beides. Jetzt ist die Frage ob diese Werkzeuge per se schlecht sind oder Opfer destruktiver Anwendung werden?

Wieso das Ganze? Ich möchte mich mit diesem Beitrag auf einen recht schroffen Artikel beziehen der Scrum und agile Methoden für ein erhöhtes Burnout-Risiko verantwortlich macht. Nicht nur weil ich glaube, das es den Methoden nicht gerecht wird, sondern auch weil einige Irrtümer enthalten sind. Es geht um folgenden Artikel:

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.

Agil ausgebrannt – Wie Arbeitsmethoden & -bedingungen in den Burnout führen

Ich werde dazu einzelne Passagen des Artikels herausziehen und kommentieren. Sie können daraus ein tieferes Verständnis zur Scrum-Methode entwickeln. Let´s go.

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.

Irrtum #1: Agile führt nicht zu schnellerem Ergebnis, sondern es liefert frühere Teilinkremente die potentiell ausgeliefert und vom Kunden beurteilt werden können. Es gibt zusätzliche Feedbackschleifen die vermeiden sollen, das lange Zeit etwas falsches entwickelt wird – was demotiviert. Schneller wird man nicht. Das Burnout-Risiko steigt damit nicht, im Gegenteil, es wird eher gesenkt, weil: frühe Wertschätzung gegenüber dem was ist, schnelle Anpassung und Korrektur von Fehlern.

Irrtum #2: „Ein Spagat aus Qualität, pünktliche Auslieferung und Kundenzufriedenheit geht nicht.“ Doch geht, nur im Scrum-Ansatz wird weder an Qualität, zeitlichen Terminen und Kundenzufriedenheit gespart, sondern am Inhalt. Der Spagat gelingt durch Maximierung des Geschäftswertes und Weglassen von unwichtigem.

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.

Irrtum #3: Die Velocity und das Burndown-Chart sind Indikatoren dafür ob das was sich das Team am Beginn des Sprintes vorgenommen hat bis zum Ende des Sprintes wirklich fertig wird. Es geht um eine Selbstüberprüfung der Realisierbarkeit und ob „Störungen“ vorliegen die daran hindern.

Abweichungen dafür sind Grund für Analysen in der Retrospektive. Es geht also nicht um Aspekte wie „schnell“ oder „gut“ ein Team ist, sondern darum ob der Prozess, den das Team nutzt, passt.

Addieren wir nun noch einen Mikromanager hinzu, haben wir beste Bedingungen für hohe Burnout-Quoten.

Irrtum #4: There is no Micromanager, because agile. :) Ein Scrum-Team arbeitet vollständig ohne Management. Es gibt die Rollen Scrum Master, Product Owner und Entwickler. Natürlich kann es innerhalb der Stakeholder die Situation des Micromanagements geben – dann ist es jedoch Aufgabe des Scrum-Masters/des Teams darüber zu sprechen, falls das in irgendeiner Weise zum Problem wird.

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.

Irrtum #5: Eine Vermischung zwischen persönlicher Velocity und Team-Velocity die es im Scrum-Framework in der Form nicht gibt. Eine Velocity bezieht sich immer auf das Team – nie auf einzelne Mitarbeiter.

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.

Irrtum #6: Dem Gefühl, anstehende Aufgaben nicht bewältigen zu können wird doch mit konkreten User Stories die schriftlich formuliert werden, einem festen Ansprechpartner (dem Product Owner), Akzeptanzkriterien, gemeinsamen Schätzung im Team und einer Zusammarbeit als Team sehr stark entgegen gewirkt. Darüber hinaus hilft die Velocity des Teams dabei eine klare Aussage über die Realisierbarkeit und den zeitlichen Horizont abzuschätzen. Was vorher nur vage formuliert war, wird nun sichtbar und in Fakten betrachtbar.

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.

Irrtum #7: In Scrum werden keine Aufgaben zugewiesen (Push), sondern jeder nimmt sich per Pull-System ein der nächsten Aufgaben mit hoher Priorität. Daher gibt ein implementiertes Scrum-Backlog den Entwicklern wesentlich mehr Freiheitsgrad als zum Beispiel die Aufgabenverteilung via Chef-Position.

Gegen stetigen Aufgaben-Nachschub habe ich aber kein wirkliches Argument und kenne auch nicht wie das Scrum-Framework darauf reagiert. Rein persönlich finde ich ja nachwachsende Aufgaben ein sicheres Zeichen dafür, auch noch in ein paar Monaten gebraucht zu werden :)

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.

Irrtum #8: Damit genau das nicht passiert, gibt es doch die Retrospektiven – nach jedem Sprint.

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.

Irrtum #9: Die Wissenschaft streitet darüber und keiner weiß, was wirklich motiviert (siehe Reinhard K. Sprenger). Was wir aber Wissen: was uns demotiviert und das kann in einem Framework in denen die Werte Mut und Offenheit eine große Rolle spielen, natürlich eingebracht werden.

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.

Irrtum #10: Da stimme ich zu. Doch ist der kausale Zusammenhang an der Stelle verkehrt. Das liegt nicht am Scrum-Framework – im Gegenteil, das Framework gibt die Chance mit unentschlossenen Kunden und hohen Unsicherheiten konstruktiv umzugehen. Zugleich ist die kundennahe Entwicklung nicht in Scrum begründet, sondern daran das sich unsere Märkte heute stark verändert haben und besonders in der Software-Entwicklung häufig individuelle Kundenaufträge umgesetzt werden.

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.

Richtig und wertvoll! Burnout ist nämlich ein persönliches Thema und das ist Irrtum #11: Die Vermischung zwischen persönlicher und organisatorischer Ebene die sich vollständig durch diesen Artikel zieht.

Burnout entsteht beim Menschen und ist sozusagen „hausgemacht“ – das ist quasi ein persönliches „Problem“. Natürlich wirkt der Kontext und die Umwelt darauf ein, aber eben nur bedingt und daher ist es egal ob mit Scrum oder ohne Scrum gearbeitet wird. Das Risiko dafür gibt es in beiden Fälle, aber die Ursache ist oftmals eine ganz andere. Sie sind komplex.

Das ist auch der Grund weshalb es in jedem Beruf und jeder Branche eine fast gleich verteilte Prozentzahl an sogenannten „Burnout“-Betroffenen gibt.

Scrum an sich besitzt jedoch viele Artefakte damit sich eine hohe Mitarbeiterzufriedenheit einstellen kann und unsichtbares sichtbar wird. Doch ist es wie bei einem Messer… Sie können sich damit in den Finger schneiden oder Ihr Mittagessen zubereiten.

Mit Scrum in den Burnout? Ich weiß nicht.

Ein Kommentar

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht.

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>