Auf entwickler.de wird Scrum mit Burnout in Verbindung gebracht. Im ersten Moment würde ich meinen, dass das nicht sein kann. So hat auch Patrick Koglin gleich den entsprechenden Konter parat. Patrick scheint wohl durch meinen Tweet auf dieses Thema aufmerksam geworden zu sein:
Agiler Burnout: Schöne neue Arbeitswelt https://t.co/cV6hFri48G
— Norbert Eder (@norberteder) September 27, 2016
Damit wollte ich nicht meine Meinung kundtun, sondern vielmehr eine weitere Meinung in das Thema der agilen Methoden mit einbeziehen. Patrick hat hierbei versucht, die Irrtümer aus dem ursprünglichen Artikel zu korrigieren. Aber der Reihe nach.
Ein Blick auf die genannten Irrtümer
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.
Damit hat Patrick recht, es entsprich der Grundidee. Durch kurze Iterationen frühzeitig die Möglichkeit zu erhalten, das Ergebnis zu begutachten und eventuell die Richtung ändern zu können. Das klingt in der Theorie super gut. In der Praxis KANN es passieren, dass gerade das Management dies zum Anlass nimmt, eben das schnelle Ergebnis in den Vordergrund zu stellen. Das entspricht dann zwar nicht mehr der Grundidee von Scrum, aber das macht an dieser Stelle ja nichts – kann man also schon mal machen (bitte mit entsprechendem Sarkasmus lesen).
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.
Ja, auch hier hat Patrick recht. In der Realität wird an der Qualität gespart. Nicht weil es der Entwickler möchte, sondern weil der Druck entsprechend hoch ist, dass der Entwickler (wenn er die notwendige Unterstützung durch die Entwicklungsleitung nicht hat), da gar nicht auskommt. Auf der Strecke bleibt also Qualität, Testing und Dokumentation. Das kennen wir doch alle. Niemand findet es gut, aber es ist so.
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.
Ja. Nochmals ja und wieder ja. Wer will, kann das Commitment des Teams auch als Versprechen nehmen und dann zusätzlich (nennen wir das die Emergency Lane) zusätzliche Features “einkippen”. Das geht sich doch locker neben dem eigentlichen Versprechen aus. Das Team weiß natürlich, dass das nicht korrekt ist, kommt aber eventuell nicht aus, da “der Befehl” von hoch oben kommt und somit dringlicher ist, als den Prozess einzuhalten.
Irrtum #4: There is no Micromanager, because agile.
Theoretischer kann diese Aussage nicht sein. Natürlich gibt es in der Scrum-Welt keine Rolle ‘Micromanager’. Leider gibt es sie in der Realität und leider hängt man sich gerne das Schild “Wir leben Scrum” um, man will ja cool sein und dazu gehören. Gelebt wird es aber oft anders. Manchmal will man es auch gar nicht verstehen, schließlich wird man in seinem Micromanagement durch Scrum doch deutlich beschnitten. Ergo, eine wahre Aussage und es sollte auch so sein, solange sich aber nicht alle an den Scrum-Prozess halten, wird das auch nichts.
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 Zusammenarbeit als Team sehr stark entgegengewirkt.
Wenn jemand an seinem Job hängt, dann wird er lange Todo-Listen, die vom Chief Executive Officer kommen, abarbeiten. Egal, ob das nun Teil der Iteration ist, perfekt ausgearbeitet ist, oder nicht. Natürlich kann man sich als Team stark machen, im Einzelgespräch ändert sich das Verhalten aber sehr schnell.
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.
Natürlich. In der Praxis kennen sich bestimmte Entwickler in einem bestimmten Bereich aus und andere nicht. Wer macht es? Natürlich der, der sich auskennt. Warum nicht ein anderer, um Wissen zu verteilen? Ganz klar: die Emergency Lane führt schon wieder einige Sonderpunkte und das Committment gerät ins Wanken.
Irrtum #11: Die Vermischung zwischen persönlicher und organisatorischer Ebene die sich vollständig durch diesen Artikel zieht.
Natürlich kann man diese Grenzen ziehen. Ich bin natürlich für meine Gefühle verantwortlich. Kein anderer. Aber seien wir einmal ehrlich. Wenn man tagein-tagaus immer dasselbe predigt, und dennoch wird es ignoriert, irgendwann kann man bei diesem Thema nicht mehr “cool” bleiben. Das Ergebnis ist, dass wir emotional in eine Diskussion gehen. Zieht sich das über Monate oder gar Jahre, dann kann man sich dieser Sache emotional einfach nicht mehr entziehen. Das Ergebnis kann sein, dass sich der Puls massiv erhöht, wenn eine bestimmte Person den Raum betritt (da muss noch nicht mal etwas passiert sein). Sowas fließt in die Beurteilung mit ein und das kann auch niemand unterbinden. Wird nun auf Management-Ebene der Prozess Scrum torpediert und kämpfen Entwickler jedoch für diesen Prozess, dann haben wir ein organisatorisches Problem, das sich über kurz oder lang zu einem persönlichen Problem der Entwickler entwickeln wird. Eine Trennung der Ebenen erscheint mir daher nicht als möglich.
Scrum als Druckmittel
In keinster Weise möchte ich hier Patrick Koglin zu nahe treten, ich denke er weiß schon was er sagt und tut. Ebensowenig möchte ich den ursprünglichen Artikel in Abrede stellen. Der Punkt ist, dass es sehr viele Manager gibt, die Scrum einsetzen möchten, weil man damit Entwickler anlocken kann. Ebenso viele möchten es jedoch nicht leben. Deshalb nicht, weil sie dadurch “Macht” abgeben müssen. Entscheidungen werden anders getroffen, liegen nicht mehr bei einer einzelnen Person. Vielmehr ist es durch die neue Transparenz ein Leichtes, das Entwicklungsteam zu überwachen. Mit Hilfe der erhaltenen Kennzahlen kann man das Team super steuern. Und genau dieses fehlende Verständnis dafür, wie Scrum funktioniert, kann zu erheblichen Druck und in weiterer Folge zu Burnout führen.
Der Kampf gegen Windmühlen
Das Problem ist also nicht Scrum, sondern das Management, das sich etwas auf die Fahnen heftet, was es nicht bereit ist zu leben, Scrum macht es dem Management aber einfach, Druck auszuüben. Nehmen wir als Beispiel die Velocity:
Ein Scrum-Team hat sich gegen das Management durchgesetzt und schätzt die Aufgaben nun in Story Points (Schätzung nach Komplexität) und nicht mehr nach zeitlichem Aufwand. Die Velocity beschreibt nun, wie viele Story Points ein Team im Schnitt pro Iteration erledigen kann. Diese Kennzahl ist transparent und jedem zugänglich. Der Micromanager hat nun einige Möglichkeiten, den Hebel anzusetzen:
- Er involviert sich in die Schätzung und will für höherere Komplexität geringere Story Points
- Es muss “einfach” die Velocity erhöht werden
Natürlich, das DARF ER NICHT. Schon klar. Manche machen es trotzdem. Wir wissen, dass man dazu Scrum sagen kann (man kann auch zu einer Birne Apfel sagen), es aber kein Scrum ist. Und genau darin liegt die Gefahr, dass Scrum in ein Burnout ausartet. Warum? Weil sich durch diesen falschen Einsatz eine ständige Reibung zwischen Management und Scrum-Team gibt. Das Scrum-Team muss ständig dagegen halten und auf einer Front “arbeiten”, die nicht notwendig wäre. Don Quijote kommt mir spontan hier in den Sinn. Das zermürbt, da eine Änderung nicht möglich ist (außer den Job zu quittieren).
Fazit
Wird Scrum von allen getragen und richtig eingesetzt, halte ich eine Förderung von Burnouts für unwahrscheinlich (ohne mir Statistiken dazu angesehen zu habe – sofern verfügbar). Bei falschem Einsatz bin ich mir sicher, dass entweder die Burnout-Rate nach oben geht, oder die Fluktuation im Scrum-Team steigt.
Du gehörst auch zu diesen Blinden. Burnout ist ein Tabuthema und oft wissen die betroffenen selbst nicht unter was sie leiden. Die gepriesene Hyperproduktivität 200%-800% schneller und mit top Qualität (mach es zu 100% richtig beim ersten Versuch, wie es Scrum-Bücher lehren), ist moderne Sklaverei und den Naturgesetzen entgegengesetzt. Aber unsere ausländischen Softwareentwickler sind sich das ja gewöhnt sich wie Slaven behandeln zu lassen. Jeder weiss, dass R&D nicht der Management Theorie X entspricht und das Scrum rein nur für Ausnahmesituationen entwickelt wurde (Code Red). Unser Scrum Trainer hat zugegeben, dass es bei Scrum in erste Linie um Kontrolle geht und um Misstrauen (https://de.wikipedia.org/wiki/X-Y-Theorie). Scrum wurde verkauft, aufgrund wirtschaftlicker Probleme der Erfinder. Sie brauchten Geld und wussten, dass es gut in die Manager-Prozess-Landschaft passt. Homo oeconomicus wird es sicherlich gut finden! Leide mal unter diesem Control-Freak und JIRA scheiss. Ich stecke Dich in ein Hamsterad und es wird behauptet, dass die Autonomie beim Team ist – doch das Team bist niemals du. Im Gegenteil! Du bist ein unselbständiger Keyboard-Affe, für welchen andere schätzen wie lange zu für etwas brauchst. Alle drücken sich vor denen Tasks, wo man nicht schnell erledigen kann und nicht als Looser dahsteht in der JIRA Statistik. Die Leute können sich in diesem komplizierten Umfeld längst nicht mehr so entwickeln wie das früher das Fall war. Durch Angst arbeitet niemand besser – wie Dave Thomas bereits sagte. Macht die Industrie weiterhin kapputt mit solchen Prozessen, die guten Leute machen da eh nicht mit mit dem ganzen Agile/Scrum Betrug. Es gibt nur zwei Möglickeiten Scrum auszuhalten. Entweder man nimmt das ganze nicht so ernst – auch die heiligen Firmenprozesse nicht, oder man sucht sich einen Job ohne Agile. Die Entwickler im zweiten Beispiel gefallen mir besser!
Servus,
vielen Dank für dein Feedback. Genau dieser “Hyperproduktivität”, dem Performance-Trieb der agilen Welt, wollte ich entgegensprechen. Schade, es scheint mir nicht gelungen zu sein, dies wirklich eindeutig darzulegen.
Vielmehr wollte ich die Möglichkeit, frühzeitig und schnell auf Änderungen reagieren zu können, in den Vordergrund rücken. Darauf ist die Konzentration zu legen, nicht auf reine Kennzahlen zur Steuerung und “Performanceoptimierung” der Entwickler.
Scrum, oder reden wir doch lieber generell von der agilen Softwareentwicklung, wurde nicht für Ausnahmesituationen entwickelt, sondern um Unzulänglichkeiten in der Softwareentwicklung (überzogene Budgets, falsches Featureset, etc.) in den Griff zu bekommen. Ebenso dient es als Gegenstück zu schwergewichtigeren Prozessen wie z.B. das V-Modell.
Offensichtlich hast du aber sehr schlechte Erfahrungen gemacht und daher lade ich dich gerne zu einem Erfahrungsaustausch via E-Mail (norbert (at) norberteder (dot) com) ein.
Viele Grüße,
Norbert
Wenn das Committment ständig ins Wanken gerät, dann ist vllt. einfach das Committment falsch?! bei Scrum committet man sich auf ein künstliches Ziel (den Sprintinhalt), der durch nichts reales erzwungen ist. Es ist ein “Fake”-Ziel, was man sich setzt.
Natürlich erhalten dann reale Belange wie z.B. dringende Aufgaben Priorität. Das ist auch gut so.
Das Scrum-Ziel nicht zu erreichen führt erstmal zu keinerlei Schaden, und zwar, weil es ein künstliches Ziel war.
Ich haben meinen Gedanken eventuell nicht vollständig ausgeführt. Natürlich ist das Committment ein künstliches Ziel, das aber schon realistisch sein sollte und auch einem Versprechen des Teams zu verstehen ist, dass sie das definierte umsetzen, dafür jedoch in Ruhe arbeiten können.
Führungskräfte, misbrauchen dies, da sie das Committment als “das schaffen wir locker” ansehen und zusätzlich Dinge umgesetzt haben möchten, die nicht dringlich sind, aber alles was über die “Emergency Lane” kommt wird ja extra umgesetzt. Nennen wir sie die “Überstunden-Linie”.
Das kommt mir alles nach hausgemachten Problemen vor. Vllt. sagt man einfach “Wir machen alle N Wochen ein Deployment und eine Ergebnispräsentation. Der Kunde gibt Feedback, ob die Richtung stimmt. Ins Release kommt, was auch immer wir in der Zeit schaffen. Repriorisieren, Pausieren, Absagen ist jederzeit möglich und wird als eine wertvolle Kurskorrektur wahrgenommen.”
Das wäre Scrum ohne die künstlichen Beschränkungen der Arbeit.
Natürlich. Deswegen schreibe ich ja darüber, dass Scrum zu Burnout führen kann, wenn es vom Management missbraucht wird ;-)