Dass es auch in agilen Vorhaben immer noch Anforderungen braucht ist klar und wohl unbestritten. Doch ist das Verteilen der Business Analyse und des Requirements Engineering auf die anderen Rollen effektiv? Oder sind dafür dedizierte Rollen doch die bessere Alternative? Ist das Erheben, Spezifizieren, Prüfen und Managen von Anforderungen also eher ein Skillset oder eine Disziplin?
In sehr vielen IT-Vorhaben, egal ob nach klassischen oder agilen Methoden, wurden letztes Jahr die Erwartungen nur bei jedem dritten Projekt erfüllt. Dabei werden den Anforderungen nur ein Zehntel des Gesamtaufwandes gewidmet, obwohl deren Wichtigkeit unbestritten ist.
Gemäss einer Marktumfrage im Frühjahr 2018 mit mehr als 400 Teilnehmenden wurden 2 von 3 IT-Initiativen nach agilen Vorgehensweisen umgesetzt. Die überwiegende Mehrheit davon verwendete dabei das Scrum-Framework als Grundlage. Die übrigen Projekte wurden im klassischen Stil umgesetzt. Entsprechend werden die Anforderungen immer weniger in dedizierten Projektphasen nach «alter Schule» erhoben, sondern iterativ und kontinuierlich. Trotzdem ist es beängstigend festzustellen, dass über alles betrachtet bei nur jedem dritten Vorhaben die Anforderungen zufriedenstellend erfüllt wurden.
Der neuen «Trends & Benchmarkstudie 2019» zufolge werden rund 12% der gesamten Projektkosten und ca. 16% im Verhältnis zur Entwicklung für die Bedürfnis- und Problemerfassung aufgewendet. Dies ist viel zu wenig, wenn man sich vor Augen hält, dass Anforderungen zentrale Artefakte sind, die die Problemstellungen und Bedürfnisse der End-User darstellen – speziell im Hinblick auf «Customer Centric Design» oder «Design Thinking.
Auch wenn in agilen Frameworks die Halbwertszeit von Anforderungen kürzer ist, ist es nicht gewinnbringend hier zu sparen.
Tipps für die Praxis
- Es sollte Verständnis und Akzeptanz geschaffen werden, dass Anforderungen in der heutigen Zeit sich ändernde Artefakte sind und nie als fertig oder endgültig zu erachten sind.
- Schlechte Anforderungen müssen aktiv thematisiert und durch regelmässige Refinement Sessions geklärt werden. Die dazu notwendige Zeit muss explizit eingefordert werden, um den Nutzern des Produkts auch das zu liefern, was sie wirklich wollen.
- Fehlende Anforderungen müssen proaktiv angegangen werden. Dazu müssen die betroffenen Stakeholder angemessen involviert und in die Verantwortung genommen werden. Dabei hilft es wenn man sich die Frage stellt: «Was für einen Wert hat das Produkt für den User, WENN dieses Feature/Anforderung fehlt oder weggelassen wird?»
- Ein effizientes und effektives Mittel ist es, mittels eines simplen Prototypen die Anforderungen zu visualisieren. So können die Anforderungen validiert, angepasst und ein gemeinsames Verständnis geschaffen werden.
Abbildung 1: Zufriedenheit mit den Anforderungsmanagement in Projekten (Quelle: Trends & Benchmarkstudie 2019)
Ein Problem liegt darin, dass in den agilen Frameworks weder eine BA/RE-Rolle existiert, noch genügen darauf eingegangen wird, wie und welche «Items» in den «Backlog» gelangen. Es wird davon ausgegangen, dass die lösungsneutrale Formulierung von Problemen einfach, schnell und nebensächlich ist. Diesbezüglich sind die meisten agilen Frameworks zu eng abgegrenzt und werden der heutigen Komplexität nicht gerecht.
Ein weiteres Problem ist, dass der «Product Owner» das Requirements Engineering häufig nebenbei bewältigen muss. Dieser verfügt aber selten über die notwendige Zeit, sich ausreichen mit den Bedürfnissen der Nutzer auseinanderzusetzen und diese in umsetzbare Anforderungen zu überführen. Hinzu kommt, dass dieser nicht selten aus dem Projektmanagement kommt und dadurch nicht über das notwendigen Skillset verfügt um der Rolle des PO’s vollumfänglich gerecht zu werden.
Als logische Konsequenz, fehlen dann neben der Zeit auch die Skills auch Erfahrungen für das Requirements Engineering was wiederum zu schlechten Anforderungen und unzufriedenen End-Usern führt.
Tipps für die Praxis
- Der Disziplin Requirements Engineering sollte mindestens die gleiche Priorität eingeräumt werden wie der Entwicklung selbst (Ressourcen und Zeit).
- Probleme oder Bedürfnisse sind auf Business-Ebene zu formulieren und müssen die Ziele und den angestrebten Mehrwert (Added-Value) aufzeigen.
- Anforderungen müssen einfach und verständliche formuliert sein. Implizites Wissen muss explizit formuliert werden, um getroffene Annahmen zu validieren.
- Egal wie einfach oder eindeutig die Anforderungen zu sein scheinen, ist es unablässig, Anforderungen schon in einem frühen Stadium zu diskutieren und zu prüfen. Nutzer, Sponsoren, Analysten, Entwickler und Tester haben bereichernde Perspektiven, die es zu berücksichtigen gilt.
- «Definition of Ready» (DoR) ist ein effektives und effizientes Quality-Gate für die Spezifikation von Anforderungen und daher unbedingt zu definieren sowie kontinuierlich zu befolgen.
Für gutes und kontinuierliches Spezifizieren und Managen von Anforderungen braucht es keine dedizierte Rolle. Allerdings erfordert es gut und spezifisch ausgebildete Mitarbeitende. Es sind erfolgskritische Aufgaben und sollten hochgradig professionalisiert sein. Das Skillset der Mitarbeitenden ist erfolgsentscheidend.
Für das Erheben und umsetzungsgerechte Spezifizieren von Anforderungen werden Personen eingesetzt, welche einerseits Business-, andererseits Methodenkompetenzen verfügen. Gleichzeitig steigen die notwendigen Sozial- und Kommunikationskompetenzen wegen der stärkeren und kontinuierlichen Einbindung der Stakeholder. Es ist also ein sehr vielseitiges und breites Anforderungsprofil, welches nur schwierig und kostspielig von einer einzelnen Person im Sinne einer Rolle erfüllt werden kann.
Aus unternehmerischer Sicht ist es also naheliegend, dass die Aufgaben der Business Analyse und des Requirements Engineerings anstelle von konzentriert in einer Rolle, auf mehrere Schultern verteilt werden – ein Wandel von «Rollen» zu «Disziplinen». Dies setzt aber voraus, dass die eingesetzten Mitarbeitenden über die notwendigen Skills verfügen, um die ihnen zugeteilten Aufgaben in genügender Qualität erfüllen zu können. Fehlen diese, so resultiert dies häufig in Unzufriedenheit mit den Anforderungen und dem Produkt.
Tipps für die Praxis
- Ein mögliches Hilfsmittel ist die Erstellung einer Skill-Matrix des Teams, die die Fähigkeiten und spezifischen Stärken der Personen bei der Aufgabenverteilung berücksichtigt.
- Ist spezifisches Knowhow nicht vorhanden, sind gezielte Ausbildungen und Schulungen der Mitarbeitenden ein sich allemal auszahlendes Investment – hier Geld zu sparen ist kurzsichtig. Es gibt eine Vielzahl von praxisorientierten Kursen mit erfahrenen Fach- und Methodenexperten.
- Bedürfnisse und Probleme zu erkennen und abzuholen ist zentral, aber nicht trivial. Die Sozial- und Kommunikationskompetenzen («Softskills») der dafür eingesetzten Mitarbeitenden sollten explizit und umfangreich geschult sein.
- Es gibt unzählige Erhebungsmethoden für Anforderungen. Diese sollten nicht nur an der Verfügbarkeit der Stakeholder oder dem benötigten Zeitaufwand gewählt werden, sondern auch anhand der Fähigkeiten und Erfahrungen der Mitarbeitenden.
Zusammenfassend kann festgehalten werden, dass die Rollen des Requirements Engineers und des Business Analysten auch im agilen Kontext nicht tot sind. Es ist weder richtig noch falsch, für das Erheben und Spezifizieren von Anforderungen eine dedizierte Rolle einzusetzen oder es in Disziplinen (aufgabenbasiert) zu organisieren – vielmehr ist es den situativen Gegebenheiten anzupassen. Für welche Variante man sich auch entscheidet, am Ende ist das Skillset der dafür eingesetzten Mitarbeitenden entscheidend. Im agilen Kontext ersetzt der Product Owner den Business Analysten und den Requirements Engineer nicht. Dazu sind die meisten Projekte und Produkte zu gross und komplex. Es ist daher wichtig, dass die Business Analyse und das Requirements Engineering durch Mitarbeitende GEMACHT werden, die über das richtige Skillset verfügen. Bei agilen Projekten ist es sinnvoller, die Aufgaben zielorientiert zu verteilen und als Disziplinen zu organisieren – gemäss dem Motto: «Follow the goal rather than the role».