Burnout im Softwaretesten: 6 Ursachen & wie man es behebt

Markus Flueckiger

on Feb 3, 2026

QUICK SUMMARY

Gehen wir das weitverbreitete Problem des Burnouts unter Fachkräften im Bereich Softwaretesten an. Wie tragen zentrale Methoden wie Agile und DevOps zusammen mit unrealistischen Erwartungen und Arbeitsumgebungen mit hohem Druck zu diesem Problem bei? Notwendig sind systemische Veränderungen in der Teamdynamik und Arbeitskultur sowie individuelle Strategien zum Stressmanagement, um Burnout in der IT-Branche vorzubeugen und abzumildern.

Ist es möglich, eine Situation in einem Softwareentwicklungsteam zu konstruieren, in der ein Tester mit sehr großer Wahrscheinlichkeit ausbrennt?

Wenn ja, was können Tester aus diesem Gedankenexperiment lernen?

Es zeigt sich, dass Burnout unter Software-Testfachleuten nicht nur ein theoretisches Gedankenexperiment in der Softwaretestbranche ist – es ist ein reales und weitverbreitetes Problem, das viele Entwickler, Ingenieure und Tester betrifft.

Ich habe mich mit dem Thema Burnout im Softwaretesten beschäftigt und gefragt:

Wie sieht Burnout in dieser Branche aus?
Wie groß ist das Problem?
Was schafft Systeme, in denen Softwaretester ausbrennen?
Wie können wir das Thema Burnout aufschlüsseln – und lösen?

Die Antworten – oder zumindest der Anfang davon – sind in diesem Artikel zu finden.

Burnout unter Softwaretest-Fachleuten in der IT

Arbeitsplatzbezogener Stress ist etwas, das viele von uns in der IT-Branche erleben. Ich bin sicher, auch Sie kennen Ihren Anteil an Stress. In meinem Umfeld ist das Thema Burnout leider in den letzten Jahren deutlicher geworden.

Ist Burnout ein Problem?

Als ich Jonathon Wright fragte: „Wie groß ist Ihrer Meinung nach das Burnout-Problem unter QA-Fachleuten?“, antwortete er:

„Es ist ein riesiges Problem. Berühmte Worte: Man kann nicht ständig sprinten.“
Jonathon Wright, Gastgeber des QA Lead Podcasts

Er führte weiter aus,

„Methoden wie Agile und DevOps fördern die Idee, alles noch ‚schneller‘ zu erledigen. Wie kann ein QA-Fachmann in einer Fail-Fast-Learn-Rapidly-Landschaft messbaren Mehrwert bieten?

In einem aktuellen Podcast auf QALead kam der Begriff ‚erst verlangsamen, um zu beschleunigen‘ auf. Solange Unternehmen Misserfolge nicht feiern (was nur sehr wenige tun), wird jedes Scheitern die Teamgeschwindigkeit nicht fördern.

Die Antwort steckt schon im Titel des überstrapazierten Burndown-Charts. Die Gamifizierung, sich auf eine Anzahl von Story Points zu committen, führt zu einem ungesunden Wettbewerb.

"Man ist gezwungen, mit weniger mehr zu leisten, arbeitet nach der unrealistischen Erwartung, dass Arbeit innerhalb von zweiwöchigen Sprints erledigt sein muss."
Jonathon Wright, Gastgeber des QA Lead Podcasts

Wie sieht Burnout im QA aus?

Burnout ist kein Einzelfall in der Softwarebranche – aber wie sieht es konkret aus?

Hier sind Rückmeldungen von Softwaretest-Fachleuten, die zeigen, wie Burnout im QA-Alltag entsteht.

„Wir müssen unseren Wert beweisen. Teams sagen mir, sie seien agil, sie brauchen keine Tester.“

„Angst. Es ist schwer für QA-Fachleute, sich vor einem größeren Release keine Sorgen zu machen oder sich nicht für das Ergebnis verantwortlich zu fühlen.“

„Zeitdruck. Tester sind immer die Letzten. Und ich bekomme nie die Zeit, die ich brauche. Und dann wird sie halbiert, weil Entwickler überziehen.“

„Unrealistische Erwartungen. Ich könnte ewig testen und würde trotzdem nicht alles testen können. Sagen Sie das mal einem Projektleiter. Was bringt ein Tester, der die Fehler nicht findet?!“

„Herauszufinden, was aus den Backlog-Items zu testen ist, ist fast unmöglich. Und niemand erwähnt Edge Cases.“

„Die Verschwendung ist frustrierend. Entwickler können einen Bug nicht reproduzieren, das Backlog-Item ist veraltet oder schon behoben.“

„Viele wollen keinen ehrlichen Bericht und schon gar keine schlechten Nachrichten. Wenn man darauf besteht, kann es persönlich werden.“

Warum kommt es zu Burnout?

In der Literatur werden viele Faktoren genannt, die Stress auslösen und die Wahrscheinlichkeit von Burnout erhöhen. Es gibt individuelle Faktoren, zum Beispiel persönliche Antreiber wie: Sei perfekt, beeil dich, streng dich an, sei stark oder mach es allen recht. Mehr dazu findet man bei der Transaktionsanalyse.

Und es gibt Belastungen aus dem Arbeitsumfeld: hohe Arbeitslast, Zeitdruck, unerreichbare Ziele und Erwartungen, Kontrollverlust, verschärfte Konflikte, Angst vor Arbeitsplatzverlust, Unzufriedenheit im Job, Mobbing, Ausgrenzung und mehr. Sie sind uns bekannt.

Vor einiger Zeit begann ich, Burnout aus einer systemischen Perspektive zu betrachten, und entwickelte ein Simulationsspiel, in dem die Spieler das Schicksal eines Software-Entwicklungsteams beeinflussen können. Sie können die Teammitglieder ausbrennen lassen oder das erfüllendste Projekt aller Zeiten schaffen.

Das Herzstück der Simulation ist ein Burnout-System, also ein System, das so aufgebaut ist, dass einige Mitglieder eines Teams früher oder später ausbrennen werden. Einen ersten Eindruck vom Spiel können Sie auf meinem Blog gewinnen.

Dieser systemische Ansatz funktioniert auch für verschiedene Rollen in einem Team. Ich habe das für User-Experience-Profis umgesetzt und war überrascht, wie leicht es ist, diese Leute ins Zentrum eines Burnout-Systems zu treiben. Besonders beim Einsatz für die Nutzer sind sie bereit, sich zusätzlich zu engagieren und dabei selbst unterzugehen.

Im Folgenden gehe ich auf eine Geschichte von Alan ein, einem QA-Profi, um das Problem des Burnouts in der Softwarebranche besser zu verstehen und zu veranschaulichen.

Anschließend spreche ich darüber, wie Burnout-Systeme entstehen und was wir tun können, um diese Systeme zu verbessern.

Eine persönliche Geschichte über Burnout

Jetzt, da ich mir sicher bin, dass ich ein Burnout-System für QA-Profis konstruieren kann, möchte ich Ihnen Alan und seine Geschichte vorstellen.

Alan hat fast ein Jahrzehnt Erfahrung im Software-Testing, insbesondere im Performance-Testing. Er steht kurz davor, einem Entwicklungsteam beizutreten. Das Team arbeitet bereits seit zehn Sprints an dem Projekt, mit weiteren vier Sprints bis zum ersten Release.

Wie war Alans erster Tag im Projekt?

Alan: Es gibt viel für mich zu tun. Die Software hat eine geringe Qualität. Ich rechne mit vielen unentdeckten Fehlern und befürchte Probleme, falls ich sie bis zum Release nicht finde.

Markus: Also ist das Finden der Fehler für dich oberste Priorität, um die Qualität zu verbessern?

Alan: Das ist ein Teil davon. Wir erwarten auch viele Anwender. Die Performance der Software ist extrem wichtig, sobald wir an die breite Öffentlichkeit gehen. Das Team freut sich darauf, von meiner Expertise zu profitieren.

Bisher ist Alan recht optimistisch, dass die mit dem Team vereinbarten Maßnahmen die Softwarequalität verbessern werden. Doch schon einen Sprint später, mit noch drei Sprints bis zum Ziel, wirkt Alan nicht mehr so zuversichtlich.

Was ist los?

Alan: Die zwei Wochen waren intensiv. Ich bin mit meinem Fortschritt unzufrieden. Ich wollte einen ersten, einfachen Performance-Test haben, aber davon bin ich weit entfernt.

Markus: Was hindert dich?

Alan: Ich brauche Unterstützung von den Entwicklern, aber sie sind völlig ausgelastet. Außerdem habe ich viel mehr Zeit gebraucht als erwartet, um die Software kennenzulernen und gefundene Fehler zu melden.

Markus: Konnte du die neuen Stories testen, die das Team geliefert hat?

Alan: Nicht wirklich, das Team war damit beschäftigt, sie zu verfeinern. Von den zwei am Ende des Sprints fürs Testen reservierten Tagen blieb nur ein halber Tag übrig. Ich bin länger geblieben und habe am Samstag gearbeitet, aber ich bin weit davon entfernt, fertig zu sein.

In der Retrospektive des zwölften Sprints, nur noch zwei Sprints vor dem Release, ist das Testen das wichtigste Thema: Der Product Owner beschwert sich über die Anzahl der von Alan gefundenen Fehler.

Entwickler: Die meisten Fehler, die Alan gefunden hat, sind entweder unwichtig oder gar keine echten Fehler. Lass uns erst mal durchgehen, bevor wir irgendwelche Schlüsse ziehen.

Alan: Nun, für mich war es schwierig zu verstehen, was die Software aus den Backlog-Einträgen tun soll. Eine Spezifikation würde wirklich helfen.

Entwickler: Niemals! Wir wollen kein Wasserfall-Modell. Meistens ist es gesunder Menschenverstand. Komm einfach zu uns und frag. Wie läuft es mit den Performance-Tests?

Alan: Ich komme nicht weiter. Ich bekomme das Tool nicht dazu, gegen die Service-Schicht mit all der Sicherheit zu laufen. Ich brauche Hilfe.

Entwickler: Wir haben im letzten Projekt ein anderes Tool verwendet. Hat wunderbar funktioniert. Ich schick dir den Link.

Daraufhin organisiert der PO im nächsten Sprint ein schnelles Zweistunden-Meeting. Ziel ist, die Fehler zu prüfen und zu besprechen, was in die Backlog-Einträge geschrieben wird, um es dem Neuling Alan leichter zu machen. Spüren Sie, wie Alans Frust steigt?

Alans fatale Position als Sündenbock wird nach Sprint dreizehn, mit nur noch einem Sprint vor dem Release, noch deutlicher. Hier die Beschlüsse aus dieser Retrospektive:

Viele Fehler wurden in Stories gefunden, die Alan schon im vorherigen Sprint hätte testen sollen. Keine Story darf ohne Alans Test abgeschlossen werden.
Es gibt immer noch keinen Performance-Test. Wir holen einen Experten dazu. Alan soll ihn einweisen.
Zwei Stories konnten nicht abgeschlossen werden. Wir haben zwei Tage verloren, weil wir unnütze Fehlermeldungen aussortiert haben. Alan kennzeichnet jeden Fehler mit Relevanz. Im Zweifel das Gespräch mit dem Product Owner suchen.

Haben Sie es bemerkt? Das Team hat zwei Stories nicht fertiggestellt und es geschafft, Alan die Schuld zuzuschieben!

Stellen Sie sich den nächsten Sprint vor, in dem Stories nicht abgeschlossen werden, weil Alan keine Zeit hatte, sie zu testen! Kein Wunder, dass Alan erschöpft aussieht.

Alan: Nur noch zwei Wochen bis zum Release und die Qualität ist ein Albtraum. Sag das mal dem Product Owner! Und der Performance-Test wurde mir auch noch entzogen. Das war überhaupt der Grund, warum ich dem Projekt beigetreten bin. Mein Chef ist unzufrieden. Er wollte, dass ich ein Vorbild dafür bin, wie man Tester in agile Teams integriert. Ich werde wohl kämpfen müssen, mein Ruf im Unternehmen steht auf dem Spiel.

Vier Wochen später, zwei Wochen nach dem ersten Release für eine ausgewählte Zielgruppe, ist das Burnout-System voll funktionsfähig.

Alans Zusammenfassung seiner bisherigen "Erfolge":

Performance-Testing: gescheitert
Als Experte für Performance-Testing anerkannt werden: gescheitert
Die neu entwickelten Dinge gründlich testen können: gescheitert
Das bereits Entwickelte gründlich nachtesten können: gescheitert
Tester in agile Teams integrieren: gescheitert
Keine kritischen Bugs im Release: gescheitert
Empfohlen werden: gescheitert
Hart arbeiten und dafür die Schuld bekommen: erreicht
Angst, den Job zu verlieren: erreicht
Burnout: mit Volldampf unterwegs

Dies ist ein klassischer Fall eines Burnout-Systems. Was erzeugt dieses System – und wie können wir ihm entgegenwirken?

Was verursacht ein Burnout-System?

Für Alan ist es von Anfang an wie verhext, könnte man sagen. Und man hätte recht. Alan befindet sich in einem Burnout-System, das im Team schon länger wirkt. Das Burnout-System fixiert Alan wie ein Raubtier sein Opfer. Aber was ist dieses Burnout-System, und wie funktioniert es?

Ein Burnout-System ist ein Zusammenspiel aus Menschen, antreibenden Faktoren und Konflikten. In einem sich selbst verstärkenden Kreislauf entsteht eine Situation, die so voller Stressoren ist, dass einige Menschen zwangsläufig ausbrennen werden. Besonders mächtig wird es, wenn es den Überlebensmechanismus der Menschen anspricht.

1. Energie folgt den Treibern

In Alans Geschichte können wir einige Antreiber erkennen:

Ambitionen und die Faszination für das Lieblingsthema Performance-Testing motivieren Alan, sich dieser Aufgabe zu widmen.
Die Angst, für einen misslungenen Release verantwortlich gemacht zu werden, lässt Alan nach Bugs jagen.
Etwas treibt die Teammitglieder dazu, alle Features zu bauen, bevor an anderes gedacht wird.

Treiber beeinflussen das Handeln maßgeblich. Es fällt den Menschen schwer, klar darüber nachzudenken, was erreicht werden soll und wie sie es am besten tun. Die investierte Energie folgt dem Treiber und nicht dem, was am nötigsten wäre. Alans Team hinterfragt nie, ob es wirklich sinnvoll ist, alle Features umzusetzen. Genauso wenig fragt Alan sich, ob das zuverlässige Finden aller Bugs passend ist.

Das Schwierigste für uns alle ist, zu erkennen, wann ein Treiber die Kontrolle übernommen hat. Zum Glück haben Psychologen dies erforscht. Wer an persönlichen Antreibern ansetzen möchte, findet in der Transaktionsanalyse einen guten Einstieg. Für Teams bietet der Begriff Gruppendenken eine passende Ausgangsbasis. Zu beiden Themen gibt es viele hilfreiche Ratschläge.

Im Zusammenhang mit der Nervosität vor einem Release riet ein erfahrener QA-Profi: „Man muss auch einfach mal loslassen und cool bleiben.“ Hätte Alan von Beginn an diese Einstellung, würde er vielleicht ein anderes Ziel verfolgen, als sämtliche Bugs zu jagen und Performance-Tests einzurichten. Die Top-Prioritäten könnten dann sein, dass das Team die kritischen Fehler entfernt und insgesamt eine bessere Qualität liefert. Ein Weg, den mit repetitiven Aufgaben verbundenen Stress zu reduzieren, ist der Einsatz von erstklassigen Tools für das Software-Testen.

2. Konflikte heizen das System an und werden persönlich

Neben den Treibern brechen im Team Konflikte aus. Zum Beispiel: Alan braucht mehr Zeit von den Entwicklern, als sie bereit sind zu geben. Das Ergebnis: Alan macht viel Lärm und die Entwickler versuchen, ihn sich vom Hals zu halten. Mit wenig Unterstützung kann Alan die Erwartungen nicht erfüllen. Aus Angst um seinen Ruf verdoppelt er seine Anstrengungen – und erzeugt noch mehr Lärm.

Das wirklich Schlimme ist, dass Konflikte persönlich werden. Nach zehn Jahren als Tester ist Alan wahrscheinlich ein ziemlicher Profi. Trotzdem sieht das Team in ihm nur eine lahme Ente – und handelt entsprechend. Je länger dies andauert, desto tiefer gräbt sich die Perspektive ein. Schließlich betrifft es sogar Alan selbst: Er beginnt, an seiner Kompetenz zu zweifeln.

Wie oft haben Sie jemanden beschuldigt? Wie viele Menschen um Sie herum leisten keine gute Arbeit? Jeder solche Gedanke deutet auf einen Konflikt hin, der persönlich geworden ist.

Die meisten Teams sind kaum in der Lage, Konflikte zu lösen. Das fällt nicht leicht. Konfliktmanagement ist dabei das Schlüsselwort, unter dem Sie viele Ratschläge finden. Die Grundbotschaft: Teams benötigen eine Kultur, in der Ideen offen ausgetauscht werden können, abweichende Meinungen als Chance für Neues begrüßt und unterstützendes Verhalten geschätzt wird. Das ist schwer zu erreichen, gerade im Vergleich zur verbreiteten Hochgeschwindigkeitskultur, die eine interviewte Person beschreibt: „Solange Unternehmen Scheitern nicht feiern, trägt jedes Scheitern nicht zur Teamgeschwindigkeit bei.“

3. Teamstruktur beeinflusst Teamdynamik

Alans Team reservierte die letzten beiden Tage des Sprints für das Testen, den Abschluss des Sprints und die Vorbereitung auf den nächsten Sprint. Das Team nahm einfach an, dass Alan dieser Struktur folgt. Er würde die neu implementierten Funktionen am Ende des Sprints testen und im nächsten Sprint einige Nachtests sowie generelle Verbesserungen beim Testen durchführen. Klingt gar nicht schlecht, oder?

Die Realität sieht jedoch ganz anders aus. Die Software ist erst am letzten Tag des Sprints verfügbar. Die Backlog-Einträge bieten wenig Hilfe, wie sie genau funktionieren soll. Während das Team die Details für den nächsten Sprint bespricht, versucht Alan herauszufinden, was er aus diesem Sprint testen muss. Dann stellt er kurz vor Feierabend Fragen an die Entwickler und testet am Wochenende. Gut, dass das Team bespricht, was dokumentiert werden muss. Alan kann dann testen, ohne die Entwickler zu stören. Bingo.

Die Teamstruktur isoliert Alan zunehmend. Das Team bemerkt seine Schwierigkeiten nicht. Sie registrieren nur vermeintlich dumme Fragen und verspätete Ergebnisse mit geringem Wert. Was für ein lahmer Vogel.

Specification by example zeigt sehr anschaulich, wie das Testen und die Tester ein integraler Bestandteil eines agilen Teams sein können. Tester nehmen an Refinements teil, helfen beim Erstellen einer testbaren Spezifikation, richten den Fokus der Testaktivitäten auf das Wesentliche, verbessern Teamprozesse, individuelle Fähigkeiten und Werkzeuge – und sie führen auch manche Tests selbst durch. Testen geschieht kontinuierlich, nicht nur am Ende des Sprints.

4. Grundlegende Regeln ignorieren und ins Verderben rennen

Alans Team ignoriert grundlegende Regeln der Softwaretechnik.

Hier sind fünf davon:

Unerwartetes geschieht. Wenn man dafür keinen Spielraum lässt, führt das zu Hektik, Abkürzungen, dummen Fehlern, erhitzten Konflikten und auf lange Sicht zu langsameren Fortschritten.
Druck verzögert. Druck reduziert den Spielraum für Unerwartetes.
Qualität ist emergent. Das Team muss eine Qualitätskultur entwickeln. Testen ist nur ein Teil des Puzzles. Und ein einzelnes Teammitglied gegen alle anderen scheitert meist.
Teamwechsel bringen Verlangsamung. Vertrauen aufbauen, Prozesse anpassen, mehr Konflikte lösen: Das Team braucht Zeit und Energie, um neue Teammitglieder zu integrieren. Zusätzliche Leute in ein verspätetes Projekt zu stecken, macht es noch später.
Fehler sind zum Lernen da. Wenn ein Prozess zu viele Fehler produziert, sollte man ihn anhalten, beheben und daraus lernen. Keine Schuldzuweisungen – und vor allem das Tempo nicht erhöhen.

Es gibt noch mehr solcher Regeln, und wann immer Leute sie ignorieren, wird alles nur schlimmer. So war es auch bei Alan.

5. Wahrgenommene Enge löst es aus

Warum ignoriert das Team solch fundamentale Dinge? Ganz einfach. Typisch für eine angespannten Situation, in der Vorgaben (Liefergegenstände, verfügbare Zeit und Team) kaum Flexibilität für Unerwartetes lassen. Das kennen viele: man versucht trotzdem alles zu liefern. Ausgebrannte Systeme nutzen die einzig verbleibende Variable in einer so fixen Konstellation aus: wie hart das Team arbeitet, also wie viel Energie die Mitglieder aus ihren Batterien verbrauchen.

Die Preisfrage: Ist Alans Team wirklich in einer derart engen Lage, und ist es wirklich das Beste, alle Features zu liefern? Man kann es nur vermuten. Das Team tat es ebenso und stürzte sich eilig auf die Umsetzung aller Features.

Es ist die Wahrnehmung der Situation, die zählt. Der Auslöser dafür kann eine Vertragsklausel, ein Anreiz, eine große Marktchance, starker Druck vom Chef, ein gemachtes Versprechen, ein Kundenwunsch oder eine behördliche Vorgabe sein.

Alan erwartet Mengen von Bugs und Jagdfieber ergreift ihn. Die Preisfrage für ihn: Ist das Finden der Fehler in diesem Fall wirklich so ein wichtiger Schritt? Man kann nur mutmaßen – und genau das tat Alan. Er nahm an: ja.

Die Wahrnehmung einer engen Situation ist ein wichtiger Hebel, um ein Ausbrennersystem zu durchbrechen. Dahinter verbirgt sich eine weitere grundlegende Regel der Softwaretechnik:

Zu hohe Erwartungen. Stakeholder – einschließlich der Entwickler selbst – hoffen, erwarten oder verlangen mehr, als ein Softwareteam realistisch leisten kann.

Wenn ich auf die letzten 25 Jahre meiner Projekterfahrung zurückblicke, fällt mir kein einziges ein, in dem das nicht zutraf. Der Konflikt zwischen Erwartungen und Machbarkeit ist der Knackpunkt. Der Projekterfolg hängt davon ab, wie gut die Beteiligten diesen Konflikt auflösen können. Ich empfehle daher, gute Praktiken zu den Themen Stakeholder- und Erwartungsmanagement, Konfliktmanagement, Requirements Engineering, Agilität und ähnliches zu prüfen.

Jedenfalls sollte man das Wesen des Konflikts genau verstehen: Wie stark ist er? Was treibt ihn an? Mit wem muss man zusammenarbeiten? Oder wie es einer der interviewten QA-Profis ausdrückte: „Ich glaube, jedes Unternehmen muss eine bewusste Entscheidung zwischen Qualität, Kosten und Geschwindigkeit treffen.“ Jedes Unternehmen muss an seinen Erwartungen arbeiten.

QA-Profis stehen meist nicht in der Position, diese Diskussion zu führen. Sie können versuchen, beizutragen. Wahrscheinlicher ist es, die Erwartungen zu steuern, mit denen sie selbst konfrontiert sind. Ein Interviewpartner verriet mir ihr Rezept: „Es ist unmöglich, alles zu testen. Am besten einen Zeitrahmen und die Prioritäten zusammen mit dem Product Owner abstimmen. Die Prioritäten spiegeln das Risiko des Nich-Testens wider. Wenn man unzufrieden ist, muss man Zeitrahmen und Prioritäten nachverhandeln.“

6. Agile-Falle

Ein starkes Team, das sich kontinuierlich an die sich ändernden Bedürfnisse anpasst, ein unbürokratischer Umgang mit Veränderungen, einfache Mittel zur Planung und Fortschrittskontrolle: Die agile Bewegung hat eine Fülle an Innovationen hervorgebracht, von denen Entwicklungsteams dringend profitieren sollten. Dennoch scheint Agilität die Sache zu verschärfen.

Es beginnt schon bei den Bezeichnungen: Sprint bedeutet schnell, Velocity bedeutet schnell, man scheitert schnell. Agile Prinzipien stellen den Code in den Vordergrund, vorausschauendes Denken wird leicht als Verschwendung abgetan. Sogar der Begriff Scrum stammt aus dem Rugby, einer Sportart, in der sich die Spieler mit voller Geschwindigkeit gegenseitig tackeln. So fördert Agilität – selbst gegen die eigene Überzeugung – Geschwindigkeit vor Qualität. „Methodologien wie Agile und DevOps fördern die Idee, alles noch schneller zu machen“, beklagte sich ein QA-Profi.

Die Mechanik von zum Beispiel Scrum ist sogar noch schlimmer als die Benennung. Es ist nicht so, dass diejenigen, die Scrum entwickelt haben, Burnout fördern wollten. Aber Scrum führt die Teams auf eine gefährliche Fährte.

Zum einen richtet sich die Aufmerksamkeit des Teams auf das Backlog. Die Aufgabe des Product Owners ist es, Dinge ins Backlog zu legen. Die Aufgabe der Teammitglieder ist es, diese zu nehmen und nacheinander abzuarbeiten. Die Aufgabe des Scrum Masters ist es, sicherzustellen, dass dies schneller geht. Dazu braucht agile Fortschrittskontrolle kleine, in wenigen Tagen umsetzbare Backlog-Einträge. Gurus empfehlen zudem exakt ausgearbeitete Akzeptanzkriterien vor dem Sprint. Teammitglieder bekommen klar definierte, kleine Aufgabenpakete. Sie berichten täglich, wie viel Zeit sie noch für den Abschluss benötigen. Die Velocity zeigt allen, wie gut sie performen. Mikromanager jubilieren und kontrollieren jede Minute: fehlende Kontrolle, kein kreativer Raum, Druck, schneller zu werden – ein Hamsterrad.

Angesichts dessen: Zählt es in einer scheinbar engen Situation, ob das Produkt großartig für Nutzer ist? Nein, das ist Aufgabe des UX-Teams. Zählt es, ob es sinnvoll ist? Aufgabe des Product Owners. Zählt es, ob die Akzeptanzkriterien vollständig sind? Ebenfalls Sache des Product Owners. Ist Fehlerfreiheit wichtig? Aufgabe der Tester, sobald die Akzeptanzkriterien erfüllt sind. Was zählt wirklich? Dass ich meinen Backlog-Eintrag rechtzeitig abschließe. Verstehst du Alans Standpunkt? Scrum führt Teams dazu, alle Features umzusetzen. Qualität ist Alans Job. Das Grundprinzip wird verletzt, die Situation verschlechtert sich.

Alans Team hält sich auch an das Commitment. Sie füllen den Sprint mit so vielen Backlog-Einträgen, wie die Velocity angibt. Dann schwören sie, das abzuliefern. Das nächste Grundgesetz schlägt zu: Unvorhergesehene Dinge passieren. Anstatt den Schwur zu brechen, werden Abkürzungen genommen – beim Testen wird spart. Rechtzeitig fertig, gut gemacht! Einer der Interviewten sagte es ganz offen: „Die Gamifizierung des Commitments zu einer Anzahl von Story Points erzeugt ungesunden Wettbewerb.“

Alans Team ist in die agile Falle getappt. Sie wenden Scrum an, ohne wirklich agil zu sein. Vergleiche die folgenden zwei Bilder: Das erste zeigt, worum es bei Scrum geht, das zweite, worum es bei Agilität geht.

Scrum dreht sich darum, Backlog-Einträge in ein Produkt umzuwandeln.

Agilität dreht sich darum, mit einem Produkt Wirkung zu erzielen und um die Interaktion der beteiligten Personen: Diejenigen, die ein Produkt bestellen, diejenigen, die es nutzen, und diejenigen, die es erschaffen.

Scrum ist zwar ein großartiges Hilfsmittel für intrinsisch motivierte agile Teams, doch es ist fatal in einer top-down geführten Befehlshierarchie!

Fazit

In der Softwarebranche ist es wichtig, Schutzmechanismen gegen Stress und Burnout unter Softwaretester:innen zu entwickeln. In manchen Firmen mehr als in anderen. Manche Situationen sind wirklich eng, andere werden absichtlich eng gemacht. Doch die meisten Situationen erscheinen viel enger als sie tatsächlich sind. Das führt dazu, dass wir unseren inneren Antreibern folgen, die Konflikte ignorieren und fundamentale Regeln ausblenden.

Die folgende Tabelle fasst die Zahnräder eines Burnout-Systems zusammen.

Schlüsselelemente eines Burnout-Systems

Wahrgenommene Enge ist die Lücke zwischen dem, was wir als unsere Aufgabe sehen, und dem, was wir liefern können. Herauszufinden, was wirklich das Beste ist, kann das Burnout-System auflösen.
Antreiber bestimmen, wohin die Energie fließt und hindern uns daran, in einer engen Situation klug zu handeln. Unsere Antreiber zu erkennen, kann helfen, weniger Energie zu verbrauchen und sie gezielter einzusetzen.
Konflikte heizen die Situation an, machen ein Team weniger effektiv und zehren an den Kräften. Schaffen wir eine Teamkultur, in der wir Konflikte willkommen heißen und uns gegenseitig unterstützen.
Grundregeln werden leicht ignoriert. Zu sehen, dass sie ignoriert werden, ist ein deutliches Warnsignal. Wir müssen handeln!
Teamstruktur friert gute und schlechte Praktiken gleichermaßen fest. Eine Veränderung der Teamstruktur kann grundlegend verändern, wer was macht und wie Menschen interagieren. Sie kann die Spielregeln völlig neu gestalten.
Teufelskreise entstehen aus dem Zusammenspiel der Akteure im und um das Team und verschärfen die Lage immer weiter. Können wir die Teufelskreise erkennen, die uns gefangen halten? Wir müssen sie anhalten und beheben!
Agile Falle bedeutet, agile Frameworks einzuführen, ohne wirklich agil zu sein. Das Ergebnis ist ein Hamsterrad. Lasst uns auf die Nutzer:innen, auf ein großartiges Produkt und auf die Zusammenarbeit achten, statt nur Backlog-Einträge abzuhaken.

Als QA-Profi bist du vielleicht nicht in der Position, die Gesamtsituation zum Besseren zu wenden. Aber du kannst vermutlich etwas Stress abbauen.

Ich habe Jonathon Wright gefragt: „Wo hast du gesehen, dass Unternehmen oder Teams Maßnahmen ergreifen, um die mentale Gesundheit von QA-Profis zu fördern? Was funktioniert?“

Er antwortete,

„Nachdem ich das letzte Jahr damit verbracht habe, der britischen Regierung bei den Brexit-Vorbereitungen zu helfen, war ich von der Arbeitsmoral dort äußerst beeindruckt. Ich habe meinen ersten verpflichtenden Achtsamkeitskurs besucht, der äußerst hilfreich war, es gab vor Ort Spezialisten für psychische Gesundheit und sogar Selbsthilfegruppen, die sich wöchentlich trafen.“

Er wies außerdem darauf hin, dass QAs viel tun können, um Stress und Ängste auf persönlicher Ebene zu bewältigen:

„Das Leben ist zu kurz, um sich über Kleinigkeiten Sorgen zu machen. Für QA-Fachkräfte ist es schwierig, sich vor einer großen Produkteinführung keine Sorgen zu machen oder sich für die Ergebnisse verantwortlich zu fühlen. Aber wie in Episode II mit Parveen muss man manchmal einfach ‚loslassen, loslassen‘ und nicht versuchen, ‚cool zu bleiben‘.“
Jonathon Wright, Moderator des Podcasts The QA Lead

„Als jemand, der seine gesamte berufliche Laufbahn mit Angstzuständen zu kämpfen hatte, gab es dabei Rückschläge und Herausforderungen, aber ich bin immer gestärkt daraus hervorgegangen und konnte meine Angst besser bewältigen – ich habe jedes Mal mehr über mich selbst gelernt. Die Branche zieht Menschen an, die sich in unterschiedlichem Maße auf dem Spektrum befinden (wozu ich mich selbst zähle). Allerdings haben die talentiertesten Menschen, mit denen ich arbeiten durfte, unter psychischen Erkrankungen gelitten, weshalb ich meine eigene psychische Erkrankung als Superkraft betrachte!“

Wie Jonathon hervorhebt, kann man mit etwas Glück und der richtigen Einstellung einen stressigen Job in einen erfüllenden verwandeln. Ich ermutige Sie, die Sichtweise eines Burn-out-Systems zu übernehmen. Lassen Sie Ihre Ängste los, bleiben Sie ruhig. Schauen Sie dann über Gebote, Prozesse und Tools hinaus. Konzentrieren Sie sich auf das, was wirklich zählt: darauf, wie Sie und Ihre Teamkollegen sich gegenseitig unterstützen, um großartige Produkte zu schaffen.

Want more from The CTO Club?