Es gibt in der Scrum- sowie in der SAFe-Methodologie einige Unklarheiten darüber, was Requirements Engineering angeht und wer dafür zuständig sein soll. Aber die Anforderungen sind auch in Agile essentiell, um Effizienz in den Iterationen zu gewinnen. Hier ein paar Tipps, was agile Unternehmen beachten sollten, um bei der Erhebung der Requirements besser zu werden.
In den meisten verwendeten Agile Frameworks ist die Rolle des Requirements Engineers nicht klar genug definiert. Viele haben bereits über dieses Problem geschrieben. Unter anderen meine Kollegen Stephanie Berger (“Product Owner = Requirements Engineer – alles klar oder nicht?)” und Tamer Kuyucu (“Wo um Scrums Willen ist der Requirements Engineer?”), die ich beruflich kenne und schätze.
Es scheitert oft am Zeitmangel
Viele Interpretationen der Agile Frameworks sehen die Verantwortung beim Product Owner oder kurz gesagt, dem PO: Nach der SAFe-Vorgehensweise übernimmt der Product Owner die Verantwortung des Team-Backlog, und ist dann für die User Stories und das Refinement der Requirements zuständig. Aber die Anforderungen wirklich zu verantworten, bedeutet viel mehr. Wenn ich mir alle anderen Aufgaben der Product Owner vor Augen führe, sieht dies nach einer grossen zeitlichen Herausforderung.
Der Artikel von Zühlke “Ein klaffendes Loch im agilen Requirements Engineering” hat mich beruhigt, ich bin nicht die einzige, die es als unrealistisch sieht, diese zusätzlichen Aufgaben in ein «menschliches Arbeitspensum zu packen»: «Product Owners haben oft nur ca. 10% ihrer Zeit für die Rolle als Requirements Engineer zur Verfügung». Und laut dem Autor des Artikels wird mindestens eine 30-Prozent-Stelle benötigt. Ja, der Product Owner ist verantwortlich, dass das Requirements Engineering gemacht wird, und auch für die Definition of Ready (obwohl sie nicht mehr existiert laut SAFe 5.1). Aber der PO hat in der realen Welt nicht die Kapazität, alle Anforderungen zu erfüllen.
Die Rollen/Aufgabenverteilung ist wichtig, das Know-how auch
Es gibt in den Agile Communities unterschiedliche Empfehlungen, wie man den PO bei den Requirements unterstützen kann. Dedizierte Requirements Engineers sind dabei erwiesen die sinnvollste Investition für eine Firma. Eine interne Rollenverteilung ist bestimmt auch eine gute Lösung, aber falls sich ein agiles Team für diese Richtung entscheidet, dann müsste sichergestellt werden, dass die Teammitglieder sich den RE-Methoden und -Techniken öffnen. Es reicht nicht, sich die Zeit für die Ermittlung, Abnahme und Validierung der Requirements zu nehmen, man muss auch ein Minimum an Know-how haben, um gewisse Techniken je nach Situation anzuwenden.
User Stories sind meistens nicht genug als Requirements
Ja, das Vorgehen im agilen Kontext mit dem User-Centered-Design und mit der Erstellung der User Stories sowie mit dem Backlog Refinement hat nachweislich viele tolle Vorteile gebracht, endlich die Sicht des Kunden näher zum Business zu bringen.
Scrum und SAFe machen wenig Vorgaben zur Beschreibungsform der Requirements. Viele POs gehen davon aus, dass alle Anforderungen durch die User Stories und ihre Akzeptanz Kriterien abgedeckt sind. Dies mag ab und zu der Fall sein, aber oft benötigen die Entwickler mehr Informationen und vertiefte Details zum System und Business-Kontext, zum Prozess, oder auch Prototypen. Und dies zeigt, dass Requirements eben nicht nur aus den User Stories bestehen.
Anerkennung und Einsicht der Requirements Engineers nötig
Zuletzt als Reflexion: Es ist eine Tatsache, dass Requirements Engineers heutzutage wenig anerkannt sind in den Agile Frameworks. Doch die Verantwortung eine gute Lösung zu finden, liegt nicht nur bei den Firmen, die agil arbeiten. Die Definition dieser Rolle oder mindestens die Verteilung der Aufgaben sollte deutlicher definiert sein in den Agile Communities. Sieht ihr das auch so?
Weiterführende Links zum Thema
Scaled Agile: https://www.scaledagileframework.com/product-owner/
Scrum: https://www.scrum.org/resources/what-is-a-product-owner
