- Programmierung ist heute deutlich stressiger als in den 90ern und den frühen 2000er-Jahren
- Damals wurde es nur in der Nähe von Deadlines wirklich chaotisch, während es sonst vergleichsweise ruhig war
- Es wurde darüber nachgedacht, warum der Stress in den letzten Jahrzehnten zugenommen hat
- Nicht wegen Wettbewerb, Marktveränderungen oder strikten Deadlines, sondern wegen sprintbasierter Arbeit
1. Sprints hören nicht auf
- Sprints sind endlose, aufeinanderfolgende Deadlines
- Das Wasserfallmodell war an echte Deadlines und Ereignisse gekoppelt
- Sprints sind künstliche Deadlines, ohne natürliche Erholungsphasen
- Kurzfristiger Stress kann gesund sein, langfristiger Stress schadet dem Körper
2. Sprints sind nicht freiwillig
- Es ist etwas anderes, ob ein Team freiwillig alle zwei Wochen Code ausliefert
- Jeder Aspekt von Sprints ist vorgegeben
- Autonomie spielt eine wichtige Rolle für das Arbeitserleben
- Erzwungene Arbeit verursacht Stress und Unbehagen
3. Sprints ignorieren wichtige unterstützende Aktivitäten
- Sprints geben keine Zeit, um die nächste Arbeit vorzubereiten
- Um Arbeit auszuführen, braucht es Vorbereitungszeit
- Sprints versuchen, Vorbereitung und Ausführung zu trennen, aber das erzeugt Stress
Scrumpol: das tatsächliche (und noch schlechtere) Bild
- Die meisten Scrum-Implementierungen sind eine Mischung aus Wasserfall und Scrum
- Große Deadlines sind im Hintergrund immer präsent
- Wenn große Deadlines näher rücken, wird Scrum unterbrochen und der Stress nimmt zu
Fazit
- In Sprints gibt es keine Erholung, wenig Autonomie und zu wenig Vorbereitungszeit
- Entwickler sollten ihre Arbeit und ihre Prozesse kontrollieren können
- Dafür braucht es Anstrengungen wie den Aufbau ethischer Organisationen oder den Wechsel in die Freiberuflichkeit
Zusammenfassung von GN⁺
- Dieser Artikel erklärt, warum Scrum bei Entwicklern dauerhaften Stress verursacht
- Die Hauptgründe sind fortlaufende Deadlines, fehlende Autonomie und mangelnde Vorbereitungszeit
- Entwickler sollten ihre Arbeitsweise selbst kontrollieren können
- Ein anderes Projektmodell mit ähnlicher Funktionalität ist Kanban
8 Kommentare
Selbst bei Projekten wie öffentlichen SI-Vorhaben wird man pausenlos mit Phase 1, 2, 3 ... und so weiter durchgepeitscht. Und in jeder einzelnen Phase ändert sich dann wieder unglaublich viel. So lässt sich das eigentliche Ziel von Scrum, erfolgreich zu entwickeln, niemals erreichen. In diesem chaotischen, unübersichtlichen Durcheinander gehen am Ende einfach nur die Entwickler kaputt.
Ich bin derzeit PM.
In Agile-/Scrum-Setups, die sich für mich gut funktioniert anfühlten, gab es nach dem Ende wichtiger Sprints eine Retrospektive und Zeit zur Erholung. Sowohl das Entwicklungsteam als auch das Planungsteam hatten einen Moment zum Durchatmen, bevor sie das Nächste vorbereiteten.
In Arbeitsweisen, die sich für mich – wie im Haupttext beschrieben – nicht funktionierend anfühlten, lief unter den von oben im Waterfall-Stil vorgegebenen Deadlines innerhalb des Produktteams parallel auch noch Scrum, wodurch sich der Stress weiter erhöhte. Da die Deadlines selbst nicht veränderbar waren, sind wir jede Woche ohne Zeit für Erholung oder Retrospektiven weitergerannt, und es fühlte sich an wie ein nie endender Lauf.
Meinem Verständnis nach besteht die Absicht von Waterfall darin, Anforderungen möglichst früh zu identifizieren und die Arbeit der Reihe nach zu erledigen, weil zwischen Design-, Implementierungs- und Testarbeiten Abhängigkeiten bestehen. Und die Absicht von Agile und Sprints ist es, Arbeit, die im Waterfall im Voraus zu umfangreich wäre, um sie zu entwerfen oder zu implementieren, in kleinere Teile zu zerlegen und sie so anzugehen. Beide haben Vor- und Nachteile, und statt einer Methodik dogmatisch zu folgen, könnte man je nach Situation vielleicht einfach nur das auswählen, was man wirklich braucht. Wie im Artikel behauptet, sollte es auch Pausen geben, ebenso wie Vorbereitungszeit für technische Reviews oder den Bau von Prototypen. Unabhängig davon, wer die Reihenfolge der Aufgaben festlegt, denke ich, dass die Frage, ob Entwickler Autonomie haben oder nicht, keine große Rolle spielt, solange man Störfaktoren versteht und die Prioritäten entsprechend dem tatsächlichen Arbeitsfluss festlegt.
Liegt es daran, dass es im Ausland viele Manager gibt, die keinerlei Entwicklungserfahrung haben und die Abläufe von Entwicklungsmethodiken blind anwenden wollen, sodass solche Beiträge in ausländischen Blogs auftauchen? Es wirkt fast so, als würde man den Konflikt zwischen Planern und Entwicklern sehen, wie wir ihn hierzulande kennen, wenn Planer die praktische Arbeit überhaupt nicht verstehen.
Entlang des tatsächlichen Arbeitsablaufs dürfte doch der Entwickler selbst am besten in der Lage sein, Prioritäten zu setzen. Ich denke, schon der Ansatz, ihm die Autonomie zu nehmen und das von jemand anderem stellvertretend erledigen zu lassen, ist vielmehr eine Ursache dafür, dass die praktische Arbeit und die Teamplanung voneinander getrennt werden.
Wenn Management selbst ein eigenes Fachgebiet ist, dann denke ich, dass selbst ein Manager ohne Entwicklungserfahrung, wenn er an den Punkt kommt, an dem das Management von Entwicklungsressourcen nicht gut funktioniert, sich an die Situation anpassen oder entsprechend darauf reagieren sollte. Trotzdem habe ich viel zu oft gesehen, dass diese Verantwortung auf einzelne Mitarbeitende abgewälzt wird...
Die endgültige Verantwortung sollte dein Manager tragen. Aber in der Realität scheint das wohl nicht so zu sein. So wie ein CEO, der nur managen kann, das eigentliche Geschäft des Unternehmens überhaupt nicht versteht und die Firma manchmal gegen die Wand fährt.
Es gibt zu viele PMs, die nur Pingpong spielen T_T
Hacker-News-Kommentare
Unter Verweis auf Rich Hickey wird gesagt, dass Programmierer Probleme nicht wie Kurzstreckenläufer lösen, sondern indem alle 100 Yards der Startschuss für einen neuen Sprint abgefeuert wird
Ich habe angefangen, Softwareprozesse zu hassen. Wenn man die Teamgröße angemessen festlegt und Entwicklern die Befugnis gibt, Ziele zu erreichen, können sie auch ohne den Produktivitätsfluss des Managements gute Arbeit leisten. Agile und Ähnliches existieren, damit Manager ihr Gehalt rechtfertigen können
Ich frage mich, was damit gemeint ist, dass „Sprints nicht freiwillig sind“. Das Team wählt die Eigenschaften des Sprints, sie werden nicht zufällig zugewiesen. Es ist eine Zusammenarbeit zwischen Führung, Teammitgliedern und nicht zum Team gehörenden Stakeholdern. Bitte erklärt, warum Scrum so starr ist
Ich fand schon seit dem ersten Auftauchen von Scrum, dass es keinen Sinn ergibt, Entwickler ständig sprinten zu lassen. Ein Sprint ist kurz und schnell, und danach braucht man Ruhe. Alle Arbeit zu Sprints zu machen, ist verrückt
Scrum wird in der Praxis oft zum noch schlimmeren „Scrumfall“. Anfangs wurde Scrum für die Kommunikation in Remote-Teams genutzt, verwandelte sich aber nach und nach in marketinggetriebene Ziele und stressige Sprints. Das Ausbrennen von Entwicklern ist klar erkennbar
Anfang der 2000er arbeiteten Engineering-Teams eigenständig ohne Projektmanager. Software war nicht so stark miteinander vernetzt wie heute, und die Release-Zyklen waren länger. Heute läuft durch CI/CD und Continuous Deployment alles schnell. SCRUM verursacht Stress
Die meisten Gespräche lassen sich so zusammenfassen: „Scrum ist an meinem Arbeitsplatz wegen X, Y, Z nicht gut“ und „Das ist nicht ideales Scrum“
Ich entwickle seit 40 Jahren Software, und egal welche Methode man nutzt, man muss die Arbeit aufteilen und zeigen, dass Ziele erreicht werden. In kleinen Teams kann Kanban mit einer einfachen Codebasis ausreichen, aber bei großen Teams oder komplexen Lösungen braucht es Reporting
Wir nutzen weder Agile noch Scrum noch Standups. Wir setzen einmal pro Woche in einem Meeting die Prioritäten neu und verfolgen den Fortschritt über ein Ticketsystem. So können Entwickler autonom arbeiten. Es sollte mehr Zeit fürs Coden als für Meetings oder TPS-Reports geben
Nachdem ich in acht Unternehmen gearbeitet habe, war der Shape-Up-Ansatz von Basecamp am erfolgreichsten. Wichtig ist die Frage, „wie viel Zeit wir investieren wollen“, nicht „wie viele Tage“. Shape Up bietet zwischen den 6‑Wochen-Zyklen Cooldown-Zeiten und liefert konsistent erfolgreiche Produkte