Warum Requirements-Engineering-Techniken auch im agilen Umfeld notwendig sind

Mike Cottmeyer von LeadingAgile schrieb einmal: «Just becuase we do lightweight documentation doesn’t mean lightweight thinking.» Er spricht damit den Punkt «working software over comprehensive documentation» aus dem agilen Manifest an und die oftmals falsche Schlussfolgerung, dass Dokumentation unnötig sei. Er deutet an, dass durch die weggelassene Dokumentation auch das strukturierte und analytische Denken verloren gehen kann.

Auch in der agilen Welt ist es von entscheidender Bedeutung, die Stakeholder-Bedürfnisse und das Umfeld bzw. deren Zusammenhänge und Abhängigkeiten – kurz: das grosse Ganze – zu verstehen. Für solche strukturierten und analytischen Betrachtungen eignen sich die Techniken aus der Requirements-Engineering-Disziplin hervorragend.

Keine RE-Rolle, also kein analytisches Vorgehen?

In vielen agilen Vorhaben sind diese Techniken jedoch nicht mehr vorhanden, da explizit keine RE-Rolle mehr vorgesehen ist. Es ist gar noch schlimmer: Requirements sind bei den Entwicklern verpönt, da einschränkend und fordernd, und wurden, wo immer möglich, eliminiert. Dabei wird jedoch oft übersehen, dass die Requirements-Spezifikation nur ein einzelnes Artefakt aus einem grösseren, nutzbringenden Prozess ist.

Der eigentliche Mehrwert der Requirements-Engineering-Disziplin entsteht in der Erhebungs- und Konsolidierungsphase, wo die analytische Betrachtung der Vorhabenziele erfolgt – schliesslich adressiert die erste Version eines Auftrags selten die eigentlichen Probleme. Erst das strukturierte Erarbeiten der Problemstellung bringt die in Wahrheit zu lösende Herausforderung ans Tageslicht.

Ja zu RE-Techniken, aber wie viel?

Requirements-Engineering-Techniken unterstützen ein strukturiertes Vorgehen. Die Schwierigkeit ist dabei herauszufinden, wie weit diese analytische Betrachtung im gegenwärtigen Vorhaben gehen muss. Gemäss Agile soll es insgesamt leichtgewichtig sein. Geht man zu weit, endet man möglicherweise in der klassischen Upfront-Spezifikation, bleibt man zu oberflächlich, besteht die Gefahr, ein irreführendes Backlog zu erstellen und am Ziel vorbeizuschiessen.

Das wird besonders dadurch begünstigt, dass User Stories immer nur einen kleinen Teil der Herausforderung betrachten. Fehlt die analytische Gesamtsicht, können die Mikroschritte unbemerkt in eine falsche Richtung führen und die Vorhabensziele gefährden.

Der Product Owner ist der neue RE

Das alles ist kein Geheimnis. Warum fehlt es dann trotzdem in vielen Vorhaben am übergeordneten, strukturierten und analytischen Denken? Ein möglicher Grund ist das Fehlen eines dedizierten Requirements Engineers.

Gemäss der Rollenbeschreibung des agilen Product Owners (PO) muss er das Product Backlog mit sinnvollem Inhalt füllen. Dabei muss er sämtliche Bedürfnisse der Stakeholder, deren Prioritäten und die Wertsteigerung des Produkts berücksichtigen. Und all dies soll der PO dann noch mit dem Team besprechen, sodass am Ende einer Iteration etwas Nutzbringendes entsteht. Das ist eine immense Aufgabe und umfasst nicht nur Techniken aus dem Requirements Engineering, sondern auch aus den Disziplinen Projekt-Management, Finance und Testing.

Die kognitive Last, die mit der Erfüllung dieser vielfältigen Aufgabenstellung verbunden ist, kann überwältigend sein. Manche Menschen bevorzugen ein weit gefächertes, aber eher oberflächliches Arbeiten, andere haben tiefgreifende Fähigkeiten in wenigen, ausgewählten Gebieten. Selten kann eine Person sämtliche Rollenanforderungen in der vollen Breite und Tiefe vollständig abdecken.

Besser wäre ein Expertisen-gerechtes Delegieren

Ist man sich dieser Tatsache bewusst, kann der PO durch eine Verteilung der nicht optimal abgedeckten Aufgaben entlastet und massgeblich in seiner Gesamtverantwortung unterstützt werden. Aus diesem Grund spricht Mike Cottmeyer von einem Value Team, andere haben ein PO-Team gegründet, Technical/Story Writers ernannt und so weiter.

Egal wie diese Teams nun aufgebaut sind, geht es stets darum, die PO-Aufgaben aufgrund der Anforderungen an Personen mit den geforderten Fähigkeiten zu delegieren, ohne dass der PO dabei auf sein Stimm- und Entscheidungsrecht verzichtet

Es gibt jedoch auch noch einen anderen Grund, warum man Aufgaben delegieren möchte: Der Feature- bzw. User des POs ist nicht hoch genug, um mit dem Vorhaben mitzuhalten. Das kann daran liegen, dass der Vorhabensumfang schlichtweg zu gross für eine einzelne Person ist, die fachlichen Abklärungen überdurchschnittlich komplex oder zeitaufwändig sind oder dass der PO für mehrere Teams gleichzeitig zuständig ist und dementsprechend viele Features und/oder User Stories vorbereiten muss.

Und was sind denn jetzt die notwendigen RE-Techniken?

Ob nun der Grund für nicht angewandte Requirements-Engineering-Techniken die Überlast, fachliche Defizite oder der Fokus auf anderen Bereichen ist, ist es für ein Vorhaben unabdingbar, den Grund für deren Absenz zu erkennen und darauf zu reagieren.

Welches die zielführenden Techniken sind, hängt vom Vorhaben ab. Allgemein sind dies aber:

• eine generell strukturierte Denkweise,
• das systematische Analysieren, Zerlegen, Abstimmen und Priorisieren von Stakeholder-Bedürfnissen,
• das Erkennen und Definieren des Umfelds, der Systemgrenzen und dem Vorhaben-Umfang,
• das Hinterfragen von angeblichen Tatsachen zum Erkennen der eigentlichen Beweggründe,
• die Anwendung von erprobten Erhebungs-, Kreativitäts- und Workshop-Techniken,
• das Definieren und Sicherstellen angemessener Vorhaben-Artefakte wie Epics/Features/User Stories und/oder ausgewählter Dokumentation,
• das Erkennen und Einhalten von Rahmenbedingungen,
• die Definition und konsistenten Einhaltung von Konzepten und Begriffen,
• die analytische Priorisierung von Features und User Stories,
• die systematische Dokumentation von Vorhaben-relevanten Entscheidungen.

Und wer kann das nun?

Das Spektrum der RE-Tätigkeiten und damit verbundenen Techniken ist sehr vielfältig. Entscheidend ist, dass diese von einem Teammitglied mit den entsprechend trainierten Fähigkeiten ausgeführt werden.

Stellen Sie in Ihrem Vorhaben sicher, dass Ihr Team nicht in «lightweight thinking» endet. Requirements Engineers unterstützen Sie dabei mit ihrem fundierten Wissen und langjähriger Expertise, RE-Kurse können interessierte Teammitglieder auf den richtigen Weg bringen und Assessments durch externe Experten können Lücken im aktuellen Vorhaben aufdecken.

Wie Sie zu diesem Wissen gelangen, erfahren Sie in unserem Grundkurs oder in der Erweiterung, um auch im agilen Umfeld zu brillieren.