Agile Projekte sind nicht schneller – und genau deshalb braucht Agilität besseres Requirements Engineering
Viele Unternehmen arbeiten heute nach Scrum. Trotzdem sind ihre Product Backlogs überfüllt, User Stories werden im Sprint nicht fertig und wandern regelmäßig in den nächsten Sprint. Das Team arbeitet von Sprint zu Sprint – doch der Berg offener Anforderungen wird kaum kleiner.
Die Einführung von Scrum wurde dabei häufig mit einem klaren Ziel begründet: Wir wollen schneller werden.
Genau diesen Satz höre ich seit vielen Jahren in nahezu jedem Unternehmen. Agile Methoden gelten als Synonym für Geschwindigkeit, Flexibilität und schnelle Ergebnisse.
Doch genau hier beginnt das Missverständnis.
Geschwindigkeit war nie das eigentliche Ziel
Die ursprüngliche Idee des Agilen Manifests war nicht, Projekte möglichst schnell abzuschließen.
Vielmehr sollte vermieden werden, dass Teams über Monate oder Jahre an Lösungen arbeiten, die am Ende am Bedarf des Kunden vorbeigehen.
Anstatt sämtliche Anforderungen zu Beginn vollständig festzulegen, wird schrittweise entwickelt:
- Anforderungen werden verfeinert
- Software wird umgesetzt
- Nutzer geben Feedback
- Erkenntnisse fließen in die nächste Iteration ein
Dieser Lernprozess erhöht die Wahrscheinlichkeit, das richtige Produkt zu entwickeln. Er führt jedoch zwangsläufig zu zusätzlichen Abstimmungen und Änderungen.
Agilität ersetzt also lange Planungsphasen durch kontinuierliches Lernen.
Was Studien tatsächlich zeigen
Wissenschaftliche Untersuchungen bestätigen dieses Bild.
Eine häufig zitierte Studie von Serrador und Pinto mit über 1.000 Projekten zeigt, dass agile Projekte insbesondere bei der Kundenzufriedenheit und der Fähigkeit, auf Veränderungen zu reagieren, besser abschneiden. Ein eindeutiger Nachweis, dass agile Projekte generell schneller abgeschlossen werden, konnte hingegen nicht erbracht werden.
Auch Untersuchungen großer agiler Organisationen zeigen ein ähnliches Bild. Je größer Projekte werden, desto mehr Abstimmung, Architekturarbeit und Anforderungsmanagement werden notwendig. Mit zunehmender Projektgröße verschwinden strukturierte Prozesse also keineswegs – sie gewinnen vielmehr wieder an Bedeutung.
Der größte Irrtum: Agilität ersetzt Requirements Engineering
In vielen Unternehmen entstand in den vergangenen Jahren ein gefährlicher Denkfehler:
“Wir arbeiten agil. Deshalb brauchen wir kein klassisches Requirements Engineering mehr.”
Tatsächlich findet Requirements Engineering auch in Scrum-Projekten täglich statt.
Jede User Story muss
- verstanden,
- abgestimmt,
- priorisiert,
- beschrieben,
- überprüft und
- akzeptiert
werden.
Genau das ist Requirements Engineering.
Lediglich die Artefakte und der Zeitpunkt unterscheiden sich.
Statt eines großen Lasten- oder Pflichtenhefts entstehen Anforderungen kontinuierlich während des Projekts.
Der Product Owner trägt heute eine enorme Verantwortung
Mit Scrum wurde ein großer Teil der Verantwortung für Anforderungen auf den Product Owner übertragen. Doch genau hier zeigt sich häufig eine Schwäche.
Viele Product Owner verfügen über ausgezeichnetes Produktwissen und kennen ihre Stakeholder sehr gut. Die Rolle verlangt heute jedoch deutlich mehr als Priorisierung und Backlog-Pflege.
Professionelles Requirements Engineering gehört mittlerweile zu den wichtigsten Kompetenzen eines erfolgreichen Product Owners.
Was ihnen jedoch oftmals fehlt, sind Methoden des professionellen Requirements Engineering:
- Stakeholderanalyse
- Konfliktmanagement
- Geschäftsprozessanalyse
- Modellierung komplexer Abläufe
- Definition messbarer Akzeptanzkriterien
- Qualitätsprüfung von Anforderungen
- Nachverfolgbarkeit (Traceability)
- Umgang mit nicht-funktionalen Anforderungen
Diese Kompetenzen werden in Scrum häufig vorausgesetzt, aber selten systematisch aufgebaut.
Gute User Stories entstehen nicht zufällig
Ein häufiger Irrtum lautet: “Wir schreiben einfach User Stories.”
Doch gute User Stories sind das Ergebnis einer sorgfältigen Analyse.
Wer die eigentlichen Bedürfnisse der Anwender nicht versteht, formuliert lediglich kleinere Pakete unklarer Anforderungen.
Die Folgen sind:
- Rückfragen während der Entwicklung
- unterschiedliche Interpretationen
- häufige Nacharbeiten
- technische Schulden
- unnötige Diskussionen in jedem Sprint
Viele Teams erleben genau das und führen die Probleme anschließend auf Scrum zurück.
In Wahrheit fehlen häufig grundlegende Kompetenzen im Requirements Engineering.
Ein Product Backlog ersetzt keine Anforderungsanalyse. Er dokumentiert lediglich deren Ergebnis.
Agile Projekte investieren anders – nicht weniger
Klassische Projekte investieren einen größeren Teil des Aufwands zu Beginn. Agile Projekte verteilen diesen Aufwand über die gesamte Laufzeit.
Deshalb entsteht häufig der Eindruck, dass agile Projekte schneller starten. Tatsächlich wird jedoch kontinuierlich analysiert, abgestimmt und priorisiert.
Der Analyseaufwand verschwindet also nicht. In vielen Scrum-Projekten wird dieser Aufwand lediglich verschoben.
Anstatt Anforderungen vor der Entwicklung ausreichend zu analysieren, entstehen Diskussionen während des Sprints. Entwickler stellen Rückfragen, Product Owner müssen Entscheidungen kurzfristig treffen und User Stories werden erneut angepasst. Dadurch entstehen genau die Verzögerungen, die Scrum eigentlich vermeiden wollte.
Agilität braucht besseres Requirements Engineering
Gerade weil agile Projekte von kurzen Entscheidungszyklen leben, wird professionelles Requirements Engineering wichtiger denn je.
Ein Product Owner sollte deshalb nicht nur das Produkt verstehen. Er sollte auch die Methoden beherrschen, mit denen gute Anforderungen entstehen.
Dazu gehören unter anderem:
- systematische Stakeholderanalyse
- Moderation unterschiedlicher Interessen
- Prozessanalyse
- verständliche Modellierung (eventuell mit UML)
- Formulierung überprüfbarer Anforderungen
- Definition klarer Akzeptanzkriterien
- Priorisierung nach Geschäftswert
- kontinuierliche Validierung mit den Anwendern
Diese Fähigkeiten entscheiden oft darüber, ob ein agiles Team effizient arbeitet oder sich Sprint für Sprint mit Missverständnissen beschäftigt.
Fazit
Agilität macht Projekte nicht automatisch schneller. Sie macht Veränderungen einfacher. Das ist ein entscheidender Unterschied.
Wer Agilität ausschließlich mit Geschwindigkeit verbindet, wird zwangsläufig enttäuscht werden. Wer sie hingegen als Werkzeug versteht, um Risiken zu reduzieren und schneller zu lernen, wird ihren eigentlichen Nutzen erkennen.
Professionelles Requirements Engineering hat deshalb auch in agilen Projekten keineswegs ausgedient.
Im Gegenteil:
Je agiler ein Projekt arbeitet, desto wichtiger wird die Fähigkeit, die richtigen Anforderungen zur richtigen Zeit in der richtigen Qualität bereitzustellen.
Vielleicht ist genau das die wichtigste Erkenntnis der letzten zwanzig Jahre Agilität:
Die erfolgreichsten Scrum-Teams, die ich kenne, investieren nicht weniger Zeit in Anforderungen – sondern mehr. Der Unterschied ist lediglich, dass sie diese Requirments Engineering Aufgaben kontinuierlich und systematisch vor jedem Sprint leisten. Genau deshalb bleiben ihre Backlogs überschaubar und ihre User Stories werden innerhalb eines Sprints abgeschlossen.