Agile Requirements Engineering / Agile Business Analyse – Fünf Prognosen


SwissQ

Agilität als Turnaround-Ansatz in grossen Corporate IT Organisationen etabliert sich immestärker. Dadurch werden die klassischen IT-Disziplinen wie z.B. Requirements Engineering respektive Business Analyse bedrängt. Davor warnt auch der diesjährige SwissQ Trends & Benchmarks Report 2015. In diesem Blog wage ich fünf Prognosen, welche Themen im Agilen RE/BA uns wirklich beschäftigen und beschäftigen müssen.

Der SwissQ Trends & Benchmarks Report 2015 hat’s belegt. Waren die Organisationen in den Jahren zuvor beschäftigt, RE/BA Methodik, RE/BA Werkzeug, RE/BA Rollen und RE/BA Organisationen auszurollen und zu konsolidieren und man schon debattieren durfte, ob RE/BA endlich “angekommen”, professionalisiert worden sei – so scheint jetzt alles wieder zerronnen und verloren.

Trends-2015-RE-Schluesselergebnis-WP-1024x479

Alle die Jahren des mühseligen, ja anstrengenden Aufbaus des RE/BA Berufs in klassischen Corporate IT Organisationen scheinen vergebens. Die Agilität attackiert alle klassischen Rollen und Disziplinen und vereinigt alles im omnipotenten Team. Wozu also benötigen wir noch eine dedizierte RE/BA Rolle und Disziplin in unseren Projektführungssystemen?

Trends-2015-RE-Erfolgsfaktoren-WP-1024x287

Die klassische RE/BA Methodik ist weiterhin erpicht, möglichst vollständige und korrekte Anforderungen produzieren zu können. Diese Erfolgsfaktoren bestätigt auch der SwissQ Trends & Benchmarks Report 2015. Agiles RE/BA widerspricht dem. Im Agilen RE/BA können Vollständigkeit und Korrektheit nicht angestrebt werden. Das Agile kennzeichnet sich dadurch, stets just in time zu liefern, was gerade erforderlich ist – und das gewiss mit dem Vorbehalt, dass man eine lernende Organisation sei und Anforderungen noch nachbessern könne.

In meinem letzten Blog-Beitrag habe ich von meinem Alltag als agiler RE berichtet. Die Erfolgsfaktoren “Vollständigkeit” und “Korrektheit” habe ich darin nie als solche betitelt – weil diese mich eben nicht wirklich herausfordern im agilen Umfeld. Nein, hier möchte ich nun prognostizieren, wie und was Agile RE/BA auf das klassische RE/BA-Tum wirklich wirkt, was uns beschäftigen muss und wird. Dass für das klassische RE/BA der grösste Erfolgsfaktor ist, wie man mit der Agilität zusammenkommt, schenken wir uns heute.

Also, was macht eigentlich:

  1. Agile RE/BA und Spezifizieren von Anforderungen?
  2. Agile RE/BA und Prüfen und Abstimmen von Anforderungen?
  3. Agile RE/BA und Verwalten von Anforderungen?
  4. Agile RE/BA und Organisation?
  5. Agile RE/BA und Ausbildung?

Agile RE/BA und Spezifizieren von Anforderungen?

Ich meine, dass die klassisch typisierte Anforderung als atomares Objekt in einem Word oder sonstigen RE/BA Werkzeug keine zwei Jahre mehr überleben wird. Alles – um einen im RE/BA verpönten Universalquantor zu bemühen – ist eine Anforderung. Eine Anforderung beginnt bei einem Post-It, verwirklicht sich in Screens oder Diagrammen und dokumentiert sich in User Stories.

Im Agilen RE/BA wird niemand eine klassische Requirements Specification gemäss IEEE 830-1998 formulieren wie uns das der durchaus geschätzte IREB CPRE FL Kurs lehrt. Im Agilen RE/BA ist die Spezifikationsform fluid, sehr beweglich, wechselhaft.

Stattdessen werden Diagramme, Visualisierungen, Modelle – ob kurzweilige, langlebige, mit oder ohne Tools – dominieren und die natürlichsprachliche Spezifikation wohl in wenigen Jahren verdrängen.

Agile RE/BA und Prüfen und Abstimmen von Anforderungen?

Alle RE/BA sind aufgewachsen damit, dass eine Anforderung geprüft und abgestimmt werden muss. Hierzu verweisen wir auf klassische Reviewtechniken. Im Agilen RE/BA, das von Prinzipien wie Mut zur Lücke, Geschwindigkeit und Unvollständigkeit-Unvollkommenheit begeistert ist, sind Inspektionen nicht mehr zweckdienlich, die eine lange, schlimmstenfalls sechsmonatige Spezifikationsphase beenden. Im Agilen RE/BA werden kurze und knappe Walkthroughs und schlanke Prototypen klassische Inspektionen ersetzen.

Wie schon das Spezifizieren ist auch das Prüfen und Abstimmen liquid, stets in iterativer Bewegung. Das klappt aber bloss, wenn sich die Projektbeteiligten einander vertrauen. Vertrauen ist für mich nämlich ein wesentlicher Erfolgsfaktor für die gelungene Projektdurchführung – so auch ein agiles Prinzip.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Agile RE/BA und Verwalten von Anforderungen?

Der klassische RE/BA fordert, dass alle Anforderungen in einem entsprechenden Werkzeug systematisch-ordentlich organisiert werden müssen. Eine Anforderung ist also mindestens kategorisiert, versioniert, priorisiert und ein statusbehaftetes Objekt. Mit diesen Werkzeugen können wir klassische Metriken auswerten – IREB differenziert hier z.B. zwischen Produkt- und Prozesskennzahlen.

Im agilen RE/BA ist alles anders. Einzelne Anforderungselemente schwirren auf Modellen, als Post-Its auf Boards oder konstituieren sich erst im persönlichen Gespräch. Sie werden nicht mehr zentral verwaltet, sondern verpuppen sich in Backlog Items und werden schlüpfen, wenn sie einem Sprint zugeordnet sind. Das Team wird bloss an der Velocity gemessen. Der wichtigste Status ist dabei done. Niemand wird einem sperrigen RE-Werkzeug nachtrauern.

Agile RE/BA und Organisation

Die agile Bewegung zerschlägt alle jene RE/BA Mono-Organisationen, die in den letzten Jahren teils viel investierten, eine mehr oder weniger ausgeprägte RE/BA Methodik zu grundieren. Agilität will aber alle Disziplinen vereinen und gemeinsam zum Ziel – endlich erfolgreichere Projekte – führen. Und eben das ist der grosse Widerspruch.

Gewisse RE/BA Organisationen werden zaudern, andere sich in übergreifende, aber machtlose Pools flüchten. Einige Nachzügler werden sogar in einem Agile RE/BA Framework letzte Hoffnung verspekulieren. Die schweizerische RE/BA Szene verliert jedoch allmählich den organisatorischen Heimathafen. Die RE/BA werden stattdessen den omnipotenten Teams zugeordnet. Wo sie in der Betriebsbuchhaltung zugerechnet werden, ist dann einerlei.

Agile RE/BA und Ausbildung

Die Lehrpläne der klassischen RE/BA Ausbildungen sind noch nicht für das agile Zeitalter aktualisiert. BABOK, der Standard des IIBA, siehe auch Chris’ Blog-Serie, hat die sogenannte Agile Extension publiziert, die das BABOK Framework auf die agile Welt transportiert. Der konkurrierende Standard IREB hat derzeit keinen vergleichbaren Agile-Aufsatz. Stattdessen hat IREB eine Abhandlung publiziert, dass der IREB nicht veraltet sei und auch fürs Agile RE/BA gelte.

iSQI hat den Markt für Agile RE/BA Ausbildungen momentan monopolisiert, der Certified Agile Business Analyst (CABA) ist die einzige mir bekannte – und natürlich von SwissQ angebotene – Ausbildung, die sich explizit an Agile RE richtet. Da aber die konkreten Tätigkeiten eines Agile RE/BA nicht standardisiert sind und je nach Ausprägung des Projekts, Teams und des Agile RE/BA selber variieren können – und sich somit die Rolle des Agile RE zunächst stabilisieren muss, warten wir kurzfristig vergebens auf ein international genormtes Agile RE/BA Vorgehen.

Und was empfiehlt SwissQ?

Agilität ist endlich angekommen. Erfolgreiche Projekte bedingen weiterhin RE/BA Fähigkeiten – daran wird sich vorläufig nichts ändern. Denn die Komplexität und Kompliziertheit der schweizerischen Projekte gebieten, eben RE/BA Fähigkeiten zu mobilisieren.

SwissQ sagt, dass die Agile RE/BA Tätigkeiten auf ihr Projekt abgestimmt werden müssen. Was benötigen und fordern PO und Team? Gehört der Agile RE/BA zum Entwicklungs- oder PO-Team? Ist der Agile RE/BA technisch oder fachlich versierter?

Wir unterstützen sie gerne, ihren Agile RE/BA Skills einen neuen Platz in ihrem Unternehmen zu finden. Beginnen sie mit fünf kleinen Schritten in ihrem Team, die wir hier empfehlen:

  1. Schaffen sie Agile RE/BA Aufwand transparent in ihrem Sprint, indem sie diese Tasks farblich hervorheben
  2. Verschieben sie ihre Agile RE/BA organisatorisch zu den Teams, lassen sie aber ihre Agile RE/BA in Pools gruppiert
  3. Definieren sie einen leichtgewichtigen Sprint-Vorbereitungsprozess (Grooming, Preperation, Sprint Planning, etc.) mit Kanban, welchen ihre Agile RE/BA zusammen mit ihrem PO ausführen
  4. Fördern sie das Verständnis, das Vertrauen der Just In Time Spezifikation ihrer Agile RE/BA mit einer kurzen Agile Einführung
  5. Nutzen sie Pair “Writing” für User Stories, PO und Agile RE/BA zusammen und etablieren sie “Muster”, wie sie User Stories schneiden

SwissQ kann auf Projekte referenzieren, wo wir den Agile RE/BA unterschiedlich einsetzen und damit Projekte zum Erfolg begleiten durften und weiterhin dürfen. Besuchen sie uns an unserem Stand am diesjährigen Swiss Requirements Day in Zürich. Unsere Agile RE/BA werden gerne von ihrem Agile Alltag erzählen.

Weitere Blog lesen

2 thoughts on “Agile Requirements Engineering / Agile Business Analyse – Fünf Prognosen”


  • Es ist gut möglich, dass Ihre Prognosen tatsächlich eintreten. Aus meiner Sicht allerdings nicht, weil BA/RE unnötig geworden wäre, sondern weil hier gemäss Trend einem Cargo-Kult nachgerannt wird. Man versteht zwar nicht, was man tun müsste, versucht aber die Post-IT-Arbeiten zu kopieren.

    Dabei heisst agile nichts anderes als „wendig“ und soll einem die Möglichkeit geben, laufend auf Veränderungen reagieren zu können. Dabei sollen nur die notwendigen Arbeiten erledigt werden; das Unnötige kann weggelassen werden. Bürokratie ist zu vermeiden, weswegen das Team einen hohen Freiheitsgrad braucht.

    Um nötig von unnötig zu unterscheiden, braucht es die besten Mitarbeiter mit der grössten Erfahrung. Das Team muss gesamte Prozesse inkl. Betrieb intus haben. Nur wer weiss, wofür ein Artefakt verwendet wird kann beurteilen, ob dessen Erstellung Sinn macht. Falls es Sinn macht, in welchen Detaillierungsgrad bzw. mit welcher Methode.

    Im agilen Umfeld muss für jede einzelne Anforderung dieser Entscheid getroffen werden. Ständig. Im Extremfall mehrfach am Tag.

    Ein BA/RE ist im agilen Umfeld aus meiner Sicht „Hüter des Teamwissens“. Das Team als Ganzes ist „Meister aller Klassen“.

  • beat.duenner@duenner-engineering.ch' Beat Dünner says:

    Es ist äusserst erfreulich zu sehen, dass agile Methoden je länger je mehr Akzeptanz gewinnen.

    Die Vergangenheit hat gezeigt, dass es enorm anspruchsvoll ist, zu Beginn eines (Entwicklungs-)Projektes alle Details so festzulegen, dass beide Vertragspartner diese exakt so verstehen, wie sie gedacht sind. Darüber hinaus verhindern auch die besten Abstimmungsprozesse nicht, dass sich das Umfeld verändert und es sinnvoller wäre, darauf Rücksicht zu nehmen und gegebenenfalls Anpassungen vorzunehmen. Agiles Vorgehen hilft, die notwendigen Entscheidungen im richtigen Zeitpunkt zu treffen.

    Die Zeiten eines starren BA/REs sind sicher vorbei aber auch ein Product Backlog ist im weitesten Sinn ein „Verzeichnis“ von Anforderungen. Herangehensweisen und Ausgestaltung sind zwar anders als in der Vergangenheit und doch können gewisse Fähigkeiten der BA/REs wahrscheinlich von Vorteil sein. So wird auch im agilen Umfeld jeder Sprint genau beschrieben (vollständig, widerspruchsfrei…), bis und mit Akzeptanzkriterien.

    Wenn wir uns den typischen traditionellen RE-Baum vorstellen, der in allen Bereichen bis ins letzte Detail durchspezifiziert ist, so müssten wir in der agilen Welt erlauben, dass dieser Baum erst bei der tatsächlichen Sprintplanung wirklich konkrete Formen annimmt. Bekannte Requirements Engineering Werkzeuge umfassen ebenfalls user stories und KANBAN Mechanismen, so dass der Übergang vom „traditionellen“ RE in die agile Welt problemlos realisiert werden kann.

    Lasst uns ganz selbstlos das Beste aus beiden Welten nehmen!

Leave a Reply