Keine agile Methode kennt die Funktion des Requirements Engineers. Der Schluss liegt also nahe, dass es Requirements Engineering in agilen Projekten überhaupt nicht braucht!
Kürzlich war ich in einem Projekt, wo es darum ging, ein in die Jahre gekommenes Altsystem durch eine Neuentwicklung abzulösen. Das Entwicklungsteam arbeitete nach Scrum. Alle Scrumzeremonien wurden durchgeführt. Dem Product Owner stand ein Businessanalystenteam zur Seite, welches die User Stories im Backlog kontinuierlich verfeinerte. Mit Continuous Deployment stand jederzeit eine lauffähige Software zur Verfügung. Die nachhaltige Dokumentation wurde in Enterprise Architect geführt. Ein Vorzeigeprojekt, alles paletti! Oder?
Embrace the Change – zu jedem Preis
Nachdem die Architekturfragen geklärt waren und ein Prototyp für gut befunden wurde, startete die Entwicklung. Die Anforderungen wurden „just in time“ erhoben und spezifiziert und in den User Stories dokumentiert. Die Quelle der Anforderungen war im Wesentlichen das Altsystem. In Laufe der Entwicklung stellten sich aber immer wieder neue fachliche Fragen zur Sinnhaftigkeit der Implementation im Altsystem und zur Datenmigration. Aus einer 1:1 Ablösung des Altsystems wurde eine Neuentwicklung, mit vielen Verbesserungen und Anpassungen, was zu vielen Änderungen im Projekt führte. Die Änderungen wurden im Backlog erfasst, priorisiert und abgearbeitet, ganz nach dem agilen Motto: „Embrace the Change!“.
Durch die vielen Änderungen wurde die Applikation gefühlt drei Mal entwickelt. Die Kosten vervielfachten sich und das Ende war plötzlich nicht mehr in Sicht. Der Auftraggeber wurde langsam ungehalten. Der Druck auf das Projekt stieg. Der Ton wurde gehässig und das Finger Pointing begann. Die Entwickler waren frustriert, weil sie zum x-ten Mal den Code für die gleiche Sache ändern mussten. Die „Technical Debt“ stieg ständig und plötzlich kamen Zweifel auf, ob das Projekt überhaupt erfolgreich abgeschlossen werden könne. Kurz gesagt: Es war nicht lustig.
Agile Requirements Engineering - Wer ist der Reiseleiter?
Ich bin der Meinung, dass die wichtigste Aufgabe der Business Analysis / Requirements Engineerings darin besteht, stabile Geschäftsanforderungen zu liefern. Stabile Anforderungen kann man formulieren, wenn alle Stakeholder eine Vision teilen, sich auf gemeinsame Ziele verständigen und die Geschäftsanforderungen abgestimmt sind. Diesen Zustand herbeizuführen, ist Kunst und Leistung des Requirements Engineers – der Rest ist Fleissarbeit.
Im beschriebenen – durchaus typischen Projekt – fehlten die stabilen Geschäftsanforderungen. Auch fehlte eine Vision. Das Ziel, das Altsystem abzulösen, taugt dazu nicht. Die Auswirkungen waren für alle Beteiligten unangenehm und belastend. Am Ende spielt es keine Rolle, ob man agil oder nach Wasserfall entwickelt, bevor man mit der Implementierung beginnt, muss klar sein, wohin die Reise geht.
Auch agile Projekte können scheitern
Es ist die Stärke von agilen Methoden, schnell auf Änderungen im Umfeld zu reagieren und konstant mit den Stakeholdern zu überprüfen, ob der eingeschlagene Weg noch stimmt. Agile Projekte können also per se sehr gut mit Änderungen umgehen. Wenn aber die Anzahl der Änderungen überhandnimmt, gefährdet dies den Projekterfolg.
Der Trends & Benchmark Report Schweiz „Software Development 2017“ zeigt, dass agile Projekte mit einer Erfolgsquote von 64,2% leicht besser abschneiden gegenüber konventionellen Projekten mit 58,6%. Das bedeutet aber auch, dass immer noch eine Drittel aller agilen Projekte nicht erfolgreich (nicht in Zeit, nicht in Scope, nicht in Budget) abgeschlossen werden oder gar scheitern!
Requirements Engineering ist eine Aufgabe des Product Management
Die Wichtigkeit der Business Analyse ist also offensichtlich. Wieso kennen dann agile Vorgehensmodelle die Disziplin Requirements Engineering nicht? Agile Vorgehensmodelle haben den Ursprung und den Fokus auf der Softwareentwicklung. Es ist nicht Aufgabe der Softwareentwicklung Vision, Strategie und stabile Geschäftsanforderung zu erarbeiten. Dies wird von der Entwicklung als Input vom Auftraggeber erwartet. Dieser Input muss erstellt werden, bevor mit der Softwareentwicklung begonnen wird. Diese Abgrenzung zeigt, dass Requirements Engineering als Funktion des Auftraggebers zu verstehen ist. Bei Produktentwicklungen ist, in der Regel, das Product Management dafür verantwortlich, abgestimmte Geschäftsanforderungen zu liefern. Bei internen Vorhaben ist aber meist nicht so klar, wer dafür die Verantwortung trägt. Oft übernimmt eine Person die Aufgaben des Product Managers und Product Owners in Personalunion. Weder im Product Management, noch in den agilen Vorgehensmethoden ist Requirements Engineering als Aufgabe explizit beschrieben. Daher hängt viel davon ab, wie die Rollen in der Organisation interpretiert werden und ob diese überhaupt existieren.
Tipp: Requirements Engineering frühzeitig einsetzen!
Achten Sie darauf, dass gleich zu Beginn ihres nächsten Projektvorhabens geklärt wird, wer für die Business Analyse und das Requirements Engineering zuständig ist. An dieser Stelle geht es weniger darum, genau zu definieren, wer, was, wann, wie liefert. Es geht vielmehr darum, sicherzustellen, dass Requirements Engineering bewusst stattfindet, bevor die Entwickler mitten in der Umsetzung sind. Ansonsten verkommt Requirements Engineering zur reinen Symptombekämpfung.
Investieren Sie also vorab in das Agile Requirements Engineering für ihr Vorhaben, es lohnt sich!
