This entry is part 1 of 2 in the series Agile Produktplanung

Mit der Agilen Produktplanung (APP) stelle ich Ihnen heute und in den nächsten 3 Teilen dieser Blogreihe, das Framework vor, das Ihnen hilft, Requirements Engineering in Ihr agiles Vorgehen zu integrieren.
Möchten Sie mehr zur Agilen Produktplanung erfahren und sind daran interessiert es umzusetzen, dann empfehle ich das mehrtägige Curriculum zu APP für Sie, oder auch zusammen im Team. Nun aber zu dem ersten Missverständnis im RE.

Plan- und dokumentenbasiertes Requirements Engineering oder agiles RE?

Haben Sie sich bereits mit dieser Frage beschäftigt? Mit ihr beschäftigen sich sehr viele Requirements Engineers. Sie ist aber meiner Meinung nach falsch gestellt. Denn, wenn agiles Vorgehen die Lösung in einem bestimmten Kontext ist, muss Requirements Engineering dieses Vorgehen bestmöglich unterstützen. Aber es ist immer noch Requirements Engineering.

Ich lade Sie dazu ein, mit dieser Blog-Serie häufige Missverständnisse beim Umgang mit Anforderungen im agilen Umfeld aufzudecken. Lassen Sie uns gemeinsam schauen, wie wir einen Weg finden, Requirements Engineering in agile Vorgehensweisen zu integrieren.

Die beschreibende Unterscheidung von traditionellem und agilem Requirements Engineering finde ich per se nützlich. Sie kann beispielsweise helfen, Unterschiede beim Umgang mit Anforderungen in verschiedenen Kontexten besser zu verstehen.

Sie ist aber keine Abgrenzung zwischen verschiedenen Disziplinen. Requirements Engineering ist Requirements Engineering. Es verfolgt von jeher das Ziel, ein gemeinsames Verständnis und eine gemeinsame Sicht der Anforderungen an ein zu entwickelndes System unter allen an dem Entwicklungsvorhaben Beteiligten zu schaffen. Um dieses Ziel zu erreichen, muss Requirements Engineering zum Kontext des Vorhabens und zum gewählten Vorgehen passen.

Warum wählen wir in den letzten Jahren immer häufiger ein agiles Vorgehen? Oder anders formuliert:

Wenn agil die Lösung ist, was ist dann das Problem?

Wir leben heute in einer VUCA-Welt:

Das Ausmaß und die Geschwindigkeit von Veränderungen nehmen im Vergleich zu vorangegangenen Jahrzehnten zu (Volatility).  Nutzer sind durch das Internet umfassender, besser und schneller informiert als je zuvor und verlangen auch schnellere Reaktionen der Produzenten.

Vorhersagen und Planungen werden bei zunehmender Unsicherheit schwieriger. Daher wird schnelles Reagieren auf Veränderungen wichtiger (Uncertainty).

Warum nimmt die Unsicherheit beispielsweise in der Systementwicklung zu? Das liegt daran, dass die Systeme, die wir bauen, um die Ansprüche des Marktes zu befriedigen, immer komplexer werden. Die Beziehung zwischen Ursache und Wirkung, zwischen Problem und Lösung ist nicht mehr linear und damit ist die Lösung nicht mehr eindeutig vorhersagbar und planbar. Wir werden während des gesamten Entwicklungsprozesses immer häufiger mit unbekannten Unbekannten konfrontiert. Die Unsicherheit steigt.
Daneben kommt noch ein weiterer Aspekt hinzu: Wir, die diese Systeme bauen, sind als Organisationen ebenfalls komplexe Systeme. Wir befinden uns also vermehrt in einem Kontext, in dem komplexe Systeme von komplexen Systemen gebaut werden (Complexity).

Auch die Mehrdeutigkeit in den Begriffen von Dingen, mit denen wir umgehen, nimmt zu (Ambiguity).

Um in solchen Umgebungen Produkte entwickeln zu können, reichen traditionelle Planungs- und Steuerungsinstrumente nicht mehr aus. Die Vorgehensweise in der Entwicklung muss sich zwangsläufig ändern, denn wir kennen in einer Welt der unbekannten Unbekannten nicht schon am Anfang alle Fragen, die wir stellen sollten. Und damit können wir auch nicht am Anfang alle Antworten, und damit alle Anforderungen, kennen. Wir wissen aber, dass es sinnvoll ist, so schnell wie möglich auf die Fragen zu stoßen, von denen wir am Anfang nicht wussten, dass wir sie hätten stellen sollen. Klingt komplex? Ist es auch.
Wir brauchen also ein Vorgehen, das es uns ermöglicht, schnell zu lernen und uns anzupassen. Hier hat sich das agile Vorgehen bewährt.

SCRUM als verbreitetes agiles Vorgehensmodell

SCRUM basiert auf der Theorie empirischer Prozesssteuerung, die von drei Säulen getragen wird: Transparenz, Überprüfung und Anpassung:

Aus dem Scrum Guide 2017:

Scrum macht die relative Wirksamkeit Ihres Produktmanagements und Ihrer Arbeitstechniken sichtbar, damit Sie fortlaufend das Produkt, das Team und die Arbeitsumgebung verbessern können.

Was bedeutet das?

Mit empirischer Prozesskontrolle legen wir weder den genauen Umfang des herzustellenden Systems fest, noch definieren wir genau den Prozess, wie dieses System herzustellen ist.
Stattdessen bauen wir in kurzen Zyklen kleine, auslieferbare Teile des Systems.              
Dann überprüfen wir, was wir gebaut haben, und wie wir es gebaut haben.
Danach überarbeiten wir sowohl das System, als auch die Art und Weise, wie wir es erstellt haben. Anschließend passen wir beides, basierend auf dem, was wir bei der Überprüfung gelernt haben, an.

Dieses feedback-orientierte Vorgehen ermöglicht es uns also, schnell auf die Fragen zu stoßen, von denen wir am Anfang gar nicht gewusst haben, dass wir sie hätten stellen sollen.
Wie kann nun ein Requirements Engineering aussehen, das solche agilen Vorgehensweisen unterstützt?

Der Scrum Guide sagt dazu nicht viel aus. Dies führt in der Praxis leider zu vielen Missverständnissen und Fehlinterpretationen.

Lesen Sie im 2. Teil der Blogreihe, um welche Missverständnisse es geht.

Series NavigationAgile Produktplanung (APP) – Missverständnisse >>