Stress wie auch Burn-out, als persönliche Krise hervorgerufen durch andauernden Stress, sind in den letzten Jahrzehnten gut dokumentiert worden. Wikipedia gibt einen Einstieg in dieses Themenfeld [Wiki]. Die Literatur nennt viele Faktoren, sogenannte Stressoren, die zu einer Belastung führen. Im Arbeitsumfeld gehören dazu insbesondere hohe Arbeitslast, Zeitdruck, nicht erreichbare Erwartungen und Ziele, fehlende Kontrolle, aufgeheizte Konflikte, Angst vor Jobverlust und Unzufriedenheit im Job. Natürlich reagiert nicht jede Person in jeder Situation gleich. Wo einige aufblühen, gehen andere zugrunde.
Interessant ist in diesem Zusammenhang das Modell der inneren Antreiber aus der Transaktionsanalyse: Sei perfekt, sei stark, beeile dich, streng dich an und sei gefällig. Das sind fünf wertvolle Werte, um im Leben zu bestehen. Jedoch können dieselben Antreiber eine Person stark belasten, gerade wenn die daraus abgeleiteten Handlungen eine Situation verschärfen anstatt entschärfen.
Das hier vorgestellte Konzept eines Burnout-Systems ist nun ein System aus Personen, welches derart gestaltet ist, dass einige der Personen immer mehr Energie investieren und unweigerlich ausbrennen. Besonders auffallend ist, dass gerade auch diese Personen im System selbst die Stressoren hervorrufen und verstärken.
Die Wirkung eines Burn-out-Systems am Beispiel
Es ist oft leichter, abstrakte Zusammenhänge an einem konkreten Beispiel zu diskutieren. Deshalb möchte ich Sie mit Philipp bekannt machen. Philipp ist ein Fachspezialist im Bereich User Experience (UX), und er zaubert harmonische und perfekt auf Nutzer zugeschnittene Softwareprodukte hervor. In der folgenden Geschichte, in ganzer Länge können Sie diese hier [Flü19] nachlesen, landet Philipp in einer bedrohlichen Situation. Philipp und die Geschichte sind fiktiv, oder vielmehr pointiert: Die Geschichte basiert leider nur auf zu realen Ereignissen.
Ein wichtiger Kunde möchte ein neues Produkt und mit diesem einen großen Fortschritt bei der UX erreichen. Voller Tatendrang macht sich das Team ans Werk. Philipp, der UX-Fachmann, ist mit dabei. Nach vier Wochen die Anfrage des Kunden: Eine weitere Funktion wäre wirklich wichtig. Das Team sagt zu und erweitert den Umfang. Die Entwickler müssen sich nun auf die Umsetzung konzentrieren und Philipp kann die anderen im Team nur noch wenig für UX-Arbeiten beiziehen. Zudem muss er seine Ergebnisse früher fertigstellen. Trotz Mehrarbeit an den freien Abenden muss Philipp bei Problemanalyse und Konzeption kürzen.
Der Bumerang kommt zurück: Unausgereifte Designs sind nachzubessern. Als das Team feststellt, dass das bereits Umgesetzte ebenfalls nicht genügend durchdacht ist, ungeplante Änderungen notwendig werden und damit der Termin kaum mehr haltbar ist, entsteht noch mehr Druck auf Philipp. Seine fehlerhaften Vorgaben seien schuld. So kämpft Philipp alsbald alleine für eine gute UX, arbeitet an Abenden und Wochenenden, erntet von allen Seiten nur Kritik, sein Ruf ist infrage gestellt und somit sein Job bedroht, und er selbst zweifelt an seinen Fähigkeiten. Wie lange hält er diese toxische Situation durch?
Nun, vielleicht haben Sie sich beim Lesen der Geschichte am einen oder anderen Punkt über das Verhalten der Personen im Team gewundert? Beispielsweise hat das Team den Umfang erweitert, ohne Termin oder Ressourcen anzupassen. Generell stellt man fest, dass Softwareteams immer wieder grundlegende Gesetzmäßigkeiten des Software-Engineering missachten. In Philipps Team sind dies unter anderem die folgenden drei:
- Die Menge an Aufgaben, die in einer bestimmten Zeit erledigt werden können, ist begrenzt.
- Die beteiligten Personen erhoffen sich immer mehr, als machbar ist.
- Unvorhergesehenes wird eintreffen und zusätzlichen Aufwand erzeugen.
Abb. 1: Vorhandene Zeit passt selten zu den Erwartungen, selbst ohne Unvorhergesehenes
Wahrgenommener Spielraum und Unvorhergesehenes
Drei Parameter spannen das Bermudadreieck der Softwareentwicklung auf (siehe Abbildung 2), in welchem sich das Team bewegen kann: das zu erzielende Ergebnis, die verfügbare Zeit und das Team selbst.
Abb. 2: Sind Ergebnis und Zeit für das Team zu knapp bemessen, muss mehr persönliche Energie mobilisiert werden
Nun schafft sich jedes Softwareteam Spielraum für Unvorhergesehenes und überzogene Erwartungen: Dies sind Reserven im Budget und der Zeit wie auch Anpassungsmöglichkeiten am Ergebnis. Philips Team hat das Ergebnis erweitert, ohne Team und Zeit anzupassen. Es verkleinert den Spielraum. Wird dieser zu klein, muss also mehr erledigt werden, als in der verfügbaren Zeit eigentlich machbar wäre, entsteht Druck auf das Team. In der Regel geschehen nun zwei Dinge:
- Die Beteiligten investieren mehr Zeit und Energie, leeren also die Batterien. Sie werden müder und begehen mehr Fehler, die nachgebessert werden müssen.
- Die Beteiligten nehmen Abkürzungen: technische Schulden anhäufen, Teambildung und kontinuierliche Verbesserung zurückstellen oder individuelle Förderung reduzieren. Das Team wird schwächer und schafft weniger.
Beides führt in eine Abwärtsspirale: Der Druck steigt, die Konflikte nehmen an Hitze zu. Das Team muss mehr Abkürzungen nehmen und mehr Energie investieren (siehe Abbildung 3).
Nicht der tatsächliche Spielraum ist dazu maßgebend, sondern die Wahrnehmung. Diese entsteht nicht von ungefähr. Ein Vertrag könnte eine Firma verpflichten, gewisse Features zu liefern. Auch könnte sich ein Sponsor mit vollmundigen Versprechen in die Nesseln gesetzt haben und Druck ausüben. Oder eine Opportunität auf dem Markt verlangt gewisse Features zu einem bestimmten Zeitpunkt. In Philipps Team will man den Kunden beeindrucken und hat viel versprochen, noch bevor die Entwicklung überhaupt gestartet hat. Man spricht von einem sportlichen Plan. Generell gilt: Die beteiligten Personen schätzen den vorhandenen Spielraum falsch und zu eng ein.
Abb. 3: In einem Burn-out-System wirkt eine Abwärtsspirale
Unerkannte Antreiber
Der Kunde in Philipps Geschichte strebt ein besonders gutes Nutzererlebnis an. Was trägt beispielsweise die zusätzliche Funktion dazu bei? Philipps Team kann diese Frage nicht beantworten. Man ärgert sich über ungenügende Qualität des Codes und den Testaufwand. Auch nörgelt der Kunde über viele unstimmige Details. Doch bewirkt dies nur, dass man sich über den unfähigen Philipp ärgert und den Kunden als schwierig empfindet. Doch damit müsse man leben. Der Kundenwunsch, die zusätzliche Funktion, habe Vorrang.
Der durch den zu eng wahrgenommenen Spielraum gefühlte Druck aktiviert in Philipps Team einen typischen Antreiber: Wir haben Erfolg, weil wir alle gewünschten Funktionen liefern. Dadurch verändert sich so einiges. Das Nutzungserlebnis wird zweitrangig, das Augenmerk richtet sich auf die Umsetzung von Funktionen, auch neue. Generell gilt, dass Personen in engen Situationen eher gut eintrainierte Verhaltensweisen zeigen und Neues vermeiden. Zu Ersterem gehört in Philipps Team, Funktionen zu entwickeln, zu Letzterem ein gutes Nutzererlebnis zu gestalten.
Konflikte, Bewertung, Bedrohung
Während das Team also vom Ziel großartiges Nutzererlebnis abkommt und auf Funktionen umschwenkt, bleibt Philipps Anspruch bestehen. Ein Zielkonflikt entsteht und dieser trennt Philipp vom Team. Philipp verstärkt diese Abspaltung. Er zeichnet nur in erster Linie pixelgenaue Vorgaben der Nutzerschnittstelle mit einem nur ihm geläufigen und zugänglichen Werkzeug. Der Aufwand dafür ist groß und keiner im Team kann helfen. Auch sieht das Team nur das Ergebnis und nicht den Weg. So entsteht die Annahme, ein gutes Nutzererlebnis entstünde durch kreatives Werkeln im passenden Werkzeug. Philipp hingegen weiß, er müsste sich intensiv mit Nutzern austauschen und testen. Dafür reicht die Zeit nicht und es ergeben sich Fehler und Unzulänglichkeiten. Das Tragische: Das Team lastet die Defekte nicht den schlechten Strukturen und den ungelösten Konflikten an, sondern Philipp. Philipp wird vom Team abgewertet, als unfähig wahrgenommen.
Das Team zerbricht
Bei so viel Druck stellt sich sehr rasch eine existenzielle Frage: Wir oder ich? Die Beteiligten können sich verschwören und gemeinsam die Situation meistern oder sie geben das Team auf, retten sich selbst und opfern jemanden. Philipp bietet sich als Opfer an, er bremst das Team scheinbar aus.
So ist ein Fehler in Philipps Arbeit schuld daran, dass eine Funktion nicht fertig implementiert wird. Auch kann man etwas nicht einplanen, solange Philipps Arbeit nicht getan ist. Man implementiert zudem, was gut und einfach geht, schließlich hat die Vorgabe sowieso nicht alles berücksichtigt.
Die Stressoren
Damit hat das Team nun Konflikte und Strukturen, welche viele der typischen Stressoren auf Philipp konzentrieren: hohe Arbeitslast, nicht erfüllbare Erwartung, gut aussehende und durchdachte Vorgaben zu erstellen, Diskrepanz zwischen der eigenen Aspiration (gute UX) und der Aufgabe (pixelgenaue Designs), mangelnde Einflussmöglichkeiten (der Backlog treibt unbarmherzig vorwärts), Kritik an der Arbeit und Abwertung. Philipps Ruf leidet und damit entwickeln sich Jobängste.
Je länger diese Situation anhält, desto wahrscheinlicher wird auch, dass Philipp so starke Symptome einer persönlichen Krise zeigt, dass man von Burn-out sprechen kann. Ob und wie schnell dies tatsächlich geschieht, hängt nun von Philipps Möglichkeiten ab, diese Situation zu bewältigen, und natürlich auch, ob man diese toxische Situation anerkennt und entsprechend handelt.
Weitreichende Folgen
Ist die Situation an sich schon bedenklich, so ist die Ausstrahlung auf andere noch kritischer. Die geschilderte Situation wird schon bald überstanden sein. Es ist auch möglich, dass der Kunde mit dem Ergebnis doch zufrieden ist. Die Beteiligten – und damit die Organisation – könnten einiges gelernt haben:
- Wer dem Kunden viel verspricht, gewinnt den Auftrag.
- Kommt es hart auf hart, konzentriert man sich voll auf die Umsetzung der Funktionen.
- Logisch, dass man auch mal abends und samstags arbeitet.
- UX-Fachpersonen werkeln kreativ im Zeichnungstool.
- UX-Fachpersonen wollen mit Nutzern sprechen. Es geht problemlos ohne.
- Andere beschuldigen, ist absolut ok.
Die Liste ließe sich noch um viele schöne Erkenntnisse erweitern. Die grausame Systematik ist doch gerade, dass die Verhaltensweisen, die das Burn-out-System anheizen, weiter eintrainiert werden und sich über die informellen Kanäle in der Organisation verbreiten, gerade wenn die Vorhaben im Großen und Ganzen erfolgreich sind. Die Kultur der Firma entwickelt sich.
Die agile Falle
Und wie ginge es besser?
Sie können davon ausgehen, dass die Beteiligten zu hohe Erwartungen haben und den Spielraum im Bermudadreieck der Softwareentwicklung falsch und zu eng einschätzen. Es ist notwendig, die Beweggründe der Beteiligten zu verstehen und realistische Erwartungen zu formen.
Hilfreich ist beispielsweise eine Produktvision, die Geschäftsziele, Nutzerbedürfnisse und Aufwand der Lösung berücksichtig. Ist diese Produktvision bei den Beteiligten verankert, lässt sie sich beispielsweise mit dem Hilfsmittel von User Story Mapping gezielt anstreben.
Es fällt gelegentlich schwer, Einigkeit über das Wesentliche zu erzielen. Was dies wäre, entscheidet sich, sobald Leute ein Produkt kaufen, nutzen und weiterempfehlen. Wer also genau und nur das Wesentliche entwickeln will: Der enge Kontakt mit Kunden, um Ideen und den aktuellen Entwicklungsstand zu testen, scheint der beste Weg zu sein. Übrigens täte Philipp genau dies, verbrächte er die Zeit nicht mit dem Bemalen von Pixeln. Philipp hat sich sein persönliches Gärtchen UX geschaffen. Mit Folgen: Philipp wird vom Team isoliert und die Konflikte konzentrieren sich auf ihn. So wie die guten Praktiken Pair Programming und Collective Code Ownership solche Gärtchen unter Entwickler verhindern, ließe sich dies mit Collective UX Ownership, Pair Interviews und Mob UX Design auch für UX erreichen. Philipp soll seine Expertise ins Team bringen, nicht die ganze Arbeit machen. Die anderen machen mit und lernen von ihm. Philipp kann mit seinem gestalterischen Können und seinen Techniken, wie man effektiv Nutzer einbindet, punkten. Ähnliches gälte für andere Spezialisten wie Tester und Businessanalysten.
Unter hohem Druck erhalten persönliche Ziele eher Vorrang vor der gemeinsamen Aufgabe. Aus gemeinsam wird nebeneinander und gegeneinander. Diesem Effekt lässt sich entgegenwirken. Beispielsweise verhandelt das Team regelmäßig, was mittelfristig erreicht werden soll, wie die Schritte dazu sind, wer was dazu beitragen wird und wie man die Zusammenarbeit konkret gestaltet. Die in Scrum vorgesehenen Retrospektiven eignen sich dazu. Bei größeren Änderungen am Team oder bei Erreichen von Meilensteinen lohnt es sich zudem, bewusst ins Team zu investieren und funktionierende Teamstrukturen neu zu definieren, schließlich wollen Teammitglieder sich verändern und weiterentwickeln können. Ein gemeinsam verbrachter Tag mit Rahmenprogramm ist hier Gold wert.
Mitarbeiterführung kann Werte etablieren und Verhalten fördern: Zusammenarbeit und gegenseitiges Helfen anstelle Gärtchendenken, Auseinandersetzung mit Kundennutzen und Zielen anstelle Arbeit nach Vorgabe, Fördern der Kollegen anstatt Absicherung der eigenen Position, Konflikte bearbeiten anstatt andere aburteilen. Ungeschickte Mitarbeiterführung hingegen erzeugt zusätzliche Konflikte. So verstärken individuelle Zielvorgaben und Aufträge beispielsweise persönliche Ziele. Wer auf gute Teamarbeit wert legt, der sollte eher passende Werte und Verhalten fördern, als individuelle Zielerreichung fordern.
Tabelle 1: So wirkt ein Burn-out-System
Fazit
Die Praxis zeigt, man kann getrost davon ausgehen, dass die Beteiligten an einer Softwareentwicklung mehr erwarten, als realisierbar ist, und dass sie den vorhandenen Spielraum im Bermudadreieck der Softwareentwicklung verkennen und zu eng setzen. Somit ist ganz einfach eine gefährliche Situation vorhanden. Softwareteams verhaspeln sich im agilen Hamsterrad, bauen teure Software und verheizen Mitarbeiter.
Firmen, die es besser haben wollen, legen Wert auf effektives Software-Engineering, fördern Teamarbeit, ganzheitliches Denken und Handeln und sind jederzeit bereit, den Dialog zu führen, wie die Firma mit dem voraussichtlich lieferbaren Kundennutzen erfolgreich wirtschaften kann. Das reduziert nicht nur Stress und damit die Gefahr von Burn-outs, das Unternehmen wird auch besser wirtschaften.
Literatur & Links
[Flü19] M. Flückiger, UX in a burn-out system, 17.12.2019, siehe: https://starstoroad.com/blog/?p=1642
[Jef16] R. Jeffries, Dark Scrum, 8.9.2016, siehe: https://ronjeffries.com/articles/016-09ff/defense/
