Rückblick „ModernRE 2019“ – KI vs. Agile?

Heute vor einer Woche, am 10. Oktober 2019, waren wir mit einem Vortrag auf der ModernRE in Berlin vertreten.

In unserem Vortrag mit dem Titel „Tools im (agilen) Anforderungsmanagement – Die Qual der Wahl?“ ging es uns darum aufzuzeigen, welche Arten von Werkzeugen im (agilen) Anforderungsmanagement eingesetzt werden können und welche verschiedenen Mehrwerte sie ermöglichen.

Den Vortrag haben wir damit begonnen, aufzuzeigen, weshalb Menschen grundsätzlich überhaupt Werkzeuge benötigen. Einerseits können uns Werkzeuge etwas ermöglichen, was wir von Natur aus nicht können (z.B. hilft uns ein Hubschrauber oder Flugzeug zu fliegen), andererseits erlauben uns Werkzeuge etwas besser / einfacher / schneller zu tun, als es uns ohne Werkzeug möglich wäre. So können wir uns von Natur aus zwar problemlos auf der Erde bewegen, aber ein Auto erlaubt uns natürlich viel schneller und bequemer an entfernte Ziele zu gelangen.

Typische Verbesserungsziele im Anforderungsmanagement

Den Vortrag haben wir dann schnell auf den Zweck von Werkzeugen im Umfeld des Anforderungsmanagements gelenkt. Um verschiedene Tools einordnen und bewerten zu können haben wir zunächst eine Matrix aufgebaut, die 12 typische Verbesserungen im Hinblick auf das Anforderungsmanagement aufzeigt. Die Zeilen der Matrix stellen dabei die vier Hauptaktivitäten des Anforderungsmanagements, also Ermittlung, Dokumentation, Überprüfung und Verwaltung dar, während die Spalten die Verbesserungsbereiche Ergebnis & Qualität, Zeit & Kosten sowie Einfachheit & Beherrschbarkeit abbilden.

In Summe haben wir damit folgende Verbesserung (ohne Anspruch auf Vollständigkeit) hergeleitet

  • Es werden weniger wichtige Anforderungen übersehen und weniger „falsche“ Anforderungen erhoben
  • Es werden weniger Arbeitsstunden benötigt, um eine geeignete Menge von Anforderungen zu ermitteln
  • Beteiligte tun sich leichter, Anforderungen gezielt zu ermitteln
  • Mehr Anforderungen sind präzise und vollständig formuliert
  • Es werden weniger Arbeitsstunden benötigt, um ein brauchbares Anforderungsdokument zu erstellen
  • Beteiligte tun sich leichter, Anforderungen adäquat aufzuschreiben
  • Es werden weniger Fehler in den Anforderungen übersehen
  • Es werden weniger Arbeitsstunden benötigt, um die Anforderungen verlässlich zu prüfen
  • Beteiligte tun sich leichter, Fehler in den Anforderungen zu finden
  • Mehr Anforderungen sind auf dem aktuellen Stand und ihre Abhängigkeiten klar
  • Es werden weniger Arbeitsstunden benötigt, um den aktuellen Stand der Anforderungen und ihre Abhängigkeiten zu pflegen
  • Beteiligte tun sich leichter auch in großen und ggf. verteilten Projekten den Überblick über die Anforderungen zu behalten

„Falsche“ Tools sind weit verbreitet

Basierend auf dieser Liste haben wir dann unseren Eindruck geschildet, dass bei der Auswahl eines Werkzeugs für das (agile) Anforderungsmanagement diese Zielsetzungen häufig vernachlässigt werden. Bereits seit Jahren besagt eine Gartner-Studie, dass 40-50% aller Unternehmen falsche (d.h. unzureichende) Werkzeuge für das Anforderungsmanagement einsetzen und über 30% der Produktmanager sich der Existenz spezialisierter RE/RM-Werkzeuge nicht einmal bewusst sind.

Aus unserer eigenen (Vertriebs-)Erfahrung haben wir typische Antworten von Personen ergänzt, die wir häufig beim Ansprechen auf ein bzw. unser RM-Werkzeug immer wieder hören:

  • „Wir haben schon XYZ im Haus“ (Anmerkung: was meistens kein RE/RM-Tool ist)
  • „Die Leute wollen kein neues Tool lernen“
  • „Bereich A oder Unternehmen B arbeitet auch mit XYZ“
  • „Es funktioniert auch so“

Folglich erschließt sich uns der Eindruck, dass häufig bei der Auswahl eines Werkzeugs für das eigene Anforderungsmanagement genau das Grundproblem des Anforderungsmanagements zum Tragen kommt, das man durch Anforderungsmanagement eigentlich zu vermeiden versucht. Nämlich: Man weiß was man will, aber nicht was man tatsächlich braucht (und meist auch nicht, was möglich ist).

Zu oft scheinen Firmen darin gefangen zu sein, wie sie arbeiten möchten oder „was nun mal da bzw. vorgegeben“ ist. Wie aus Best Practices des Anforderungsmanagements bekannt, wäre es aber viel wichtiger, sich davon einmal zu lösen, um zu hinterfragen, was man eigentlich erreichen möchte.

Das WARUM entscheidet, nicht das WIE

Im Vortrag haben wir dann auf den Golden Circle von Simon Sinnek verwiesen. Sinnek hatten in seinem bekannten Buch „Start with why“ aufgezeigt, dass erfolgreiche Firmen das „Warum“ in ihrem Tun in den Mittelpunkt stellen und ihr Handeln darauf (und nicht etwa auf das Wie oder Was) ausrichten.

Übertragen auf das Tooling im Bereich des Anforderungsmanagements sollten sich u.E. Firmen daher vielmehr der Frage „welches Tool sie brauchen, um das zu erreichen, was sie eigentlich möchten“ widmen, anstatt zu schauen „welches Tool sie brauchen, um soundso arbeiten zu können.“

Nach dieser längeren Grundmotivation sind wir dann auf die verschiedenen Werkzeugarten eingegangen, die im Rahmen des Anforderungsmanagements eingesetzt werden. Unser Ziel war dabei nicht die einzelnen Werkzeuge im Detail vorzustellen, sondern vielmehr ihre Unterschiede herauszuarbeiten und aufzuzeigen, für welche der oben genannten Verbesserungsziele im Anforderungsmanagement sie einen Beitrag leisten können (auf eine Diskussion der einzelnen Tools sei an dieser Stelle auf unseren Blogeintrag „Was ReqSuite® so besonders macht“ verwiesen).

Dabei konnten wir aufzeigen, dass die im (agilen) Anforderungsmanagement beliebten Werkzeugarten wie Wikis und Issue Tracking Systeme faktisch keinen signifikanten Beitrag zu den eigentlichen Verbesserungszielen, die viele Unternehmen haben, leisten, und Stand heute eigentlich nur fortschrittliche RM-Tools (also solche mit KI-basierter Assistenz) in der Lage sind, hier wirklich signifikante Mehrwerte zu erzielen. (Anmerkung: Das bedeutet natürlich nicht, dass die anderen Tools keinen Nutzen haben, nur haben sie kaum Nutzen für die oben genannten Verbesserungen)

Das Tooling hinterfragen hilft

Da aber natürlich nicht ausgeschlossen ist, dass auch andere Werkzeugarten im gegebenen Unternehmenskontext angemessen sind, haben wir als „Take Away“ den Zuhörern mitgegeben, ihr Tooling anhand von einfachen Leitfragen zu hinterfragen, die wir nachstehend mit einem kleinen Beispiel wiedergeben.

  1. Was sind eigentlich ihre echten Verbesserungsziele im Hinblick auf das Anforderungsmanagement bzw. die Entwicklung generell?
    • Beispiel: „Wir wollen alle 3 Monate eine neue Version ausliefern können.“
  2. Was sind die Gegebenheiten im Hinblick auf die Anforderungen, die es Ihnen erschweren, diese Ziele zu erreichen?
    • Beispiel: „Wir verlieren viel Zeit, weil Anforderungen unklar sind und erst geklärt werden müssen.“
  3. Welche konkreten Verbesserungen erachten Sie als notwendig?
    • Beispiel: „Wir wollen die Qualität der Anforderungen direkt beim Erfassen erhöhen.“
  4. Welches Tool bietet aktiv Unterstützung dafür?
    • Beispiel: „Wir brauchen ein fortschrittliches Tool wie beispielsweise ReqSuite® RM, das eine automatische Anforderungsprüfung beinhaltet.“

Natürlich, und das haben wir im Vortrag mehrfach betont, geht es auch anders, sprich kann man versuchen, fehlende Features in Werkzeugen durch (gute) Personen auszugleichen. Die Frage ist allerdings, ob dies effizient und skalierbar ist oder nicht die Zielsetzungen, die man sich ja eigentlich mit Agilität vorgenommen hat, torpediert.

KI vs. Agile – Wann löst sich dieser Gegensatz?

An diesem Konferenztag gab es im Übrigen noch zwei weitere Vorträge zum Thema „KI im Anforderungsmanagement“, was unterstreicht, dass wir mit unserer Idee „fortschrittlicher RM-Tools“ nicht mehr allein sind. Vielmehr scheinen solche Tools aus gutem Grund im Kommen zu sein, was aufgrund der weiten Verbreitung informeller Tools sich aktuell jedoch noch wie ein krasser Widerspruch anhört.

Es bleibt daher spannend zu beobachten, ob auch weiterhin agiles Anforderungsmanagement automatisch mit Tools wie JIRA und Confluence gleichgesetzt wird oder hier ein Umdenken, das nachweislich zu erheblichen Verbesserungen führen kann, stattfinden wird.

Sebastian Adam
Sebastian Adam
https://www.osseno.com

Dr. Sebastian Adam ist Geschäftsführer der OSSENO Software GmbH und operativ für die Bereiche Produktinnovation und Marketing verantwortlich. Vor seiner Zeit bei OSSENO arbeitete er 10 Jahre lang als Berater, Wissenschaftler und Teamleiter für Requirements Engineering am Fraunhofer-Institut für Experimentelles Software Engineering (IESE). Dr. Adam hat bereits mehrere Duzend Unternehmen begleitet und verfügt über branchenübergreifende Best Practices bezüglich der Einführung und Durchführung von Requirements Engineering.