© saicle/Shutterstock.com
PHP Magazin
Teil 2: Tabuthema Burn-out: Wie Arbeitsmethoden und -bedingungen in das Burn-out führen

Agiles Burn-out

Ab in das Burn-out, 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 Burn-out-Risiko der beteiligten Mitarbeiter.

Ann-Cathrin Klose


ArtikelserieTeil 1: Tabuthema Burn-out: Daten, Zahlen, FaktenTeil 2: Tabuthema Burn-out: Wie Arbeitsmethoden und -bedingungen in das Burn-out führenTeil 3: Tabuthema Burn-out: Strategien und Tipps gegen die Erschöpfung

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 das Burn-out zu schicken. Dennoch hat auch die agile Arbeitsweise bestimmte Merkmale, die zum Risiko für das Burn-out 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 [1] Jahr für Jahr. In der gegenwärtig zehnten Auflage der großen Anwenderbefragung 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, Burn-out in der IT [2], wider: Etwa ein Viertel der für den Index „Gute Arbeit“ des DGB [3] 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 das Burn-out

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 Burn-out-Quoten. Niemand ist nämlich an jedem Arbeitstag gleich schnell. Und keine Aufgabe gleicht der anderen, sodass die Vergleichbarkeit leidet – zumal Feature Points ei...

PHP Magazin
Teil 2: Tabuthema Burn-out: Wie Arbeitsmethoden und -bedingungen in das Burn-out führen

Agiles Burn-out

Ab in das Burn-out, 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 Burn-out-Risiko der beteiligten Mitarbeiter.

Ann-Cathrin Klose


ArtikelserieTeil 1: Tabuthema Burn-out: Daten, Zahlen, FaktenTeil 2: Tabuthema Burn-out: Wie Arbeitsmethoden und -bedingungen in das Burn-out führenTeil 3: Tabuthema Burn-out: Strategien und Tipps gegen die Erschöpfung

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 das Burn-out zu schicken. Dennoch hat auch die agile Arbeitsweise bestimmte Merkmale, die zum Risiko für das Burn-out 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 [1] Jahr für Jahr. In der gegenwärtig zehnten Auflage der großen Anwenderbefragung 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, Burn-out in der IT [2], wider: Etwa ein Viertel der für den Index „Gute Arbeit“ des DGB [3] 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 das Burn-out

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 Burn-out-Quoten. Niemand ist nämlich an jedem Arbeitstag gleich schnell. Und keine Aufgabe gleicht der anderen, sodass die Vergleichbarkeit leidet – zumal Feature Points ei...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang