Agile Requirements Engineering reloaded

Qualität ist mehr als Testen

Vor ein paar Tagen las ich in der S-Bahn einen CIO Artikel, in dem in einem knappen Abriss erläutert wurde, warum DevOps für CIOs so wichtig ist und worin die größten Herausforderungen bei der Einführung bestehen.

Interessante Darstellung dachte ich – und denke das immer noch.

Dann fiel mir auf, dass leider auch in diesem Artikel „Qualität erhöhen“ mit verstärkt Testen (zugegebenermaßen hier wenigstens mit „integriertem Testen“) gleichgesetzt wird. Dabei ist das nur ein Aspekt – und wir alle wissen, dass man Qualität nicht in ein Produkt hineintesten kann: Testen ist ein Messwerkzeug.

Für Qualität braucht es im Produktprozess (Entwicklung und Produktion/Betrieb) noch weitere Dinge: Software Craftsmanship zum Beispiel und, worum es mir heute geht, Requirements Engineering (altmodischer Begriff: Anforderungsmanagement – der bezeichnet heutzutage ja nur eine Teildisziplin). Ja, auch im Agilen benötigen wir Requirements Engineering, in diesem Umfeld zur Betonung des agilen Aspekts Agile Requirements Engineering genannt.

Was umfasst Agile Requirements Engineering?

Zum Agile Requirements Engineering zählt alles, was sich mit dem Herausfinden beschäftigt, was das Produkt erreichen und erfüllen soll. Dies dient dann dem Produktteam dazu, das Richtige zu tun. So vermeidet das Team Verschwendung, erhöht die Liefer- und Produktqualität und liefert den gewünschten Nutzwert (neudeutsch: Value).

Agile Requirements Engineering liefert Orientierung und Navigation

Hierzu gehören u.a.

• die Klärung der tatsächlichen Problemstellung – häufig ist die erste Problemaussage nicht das eigentliche Problem, das gelöst werden muss
• die Definition der Zielstellung, die mit dem Produkt verfolgt wird – enthält meist viele Hypothesen über die Auswirkungen auf die Problemstellung, die im weiteren Produktprozess überprüft werden müssen
• das Herausfinden einer Auswahl möglicher Lösungskonzepte, die dann agil auf Passgenauigkeit und Wirkungskraft im Team untersucht werden
• die Erhebung und Ableitung der Detailanforderungen zur Umsetzung der Lösungskonzepte – User Stories, Akzeptanzkriterien etc. sind hier die Stichworte
• die Überprüfung, inwieweit die gelieferten Lösungen die beabsichtigten Nutzwerte erreicht haben – genau dies wird häufig nicht oder unzureichend durchgeführt und ist in der in Nordamerika stark verbreiteten Business Analyse besser verankert

Das klingt nun ganz stark nach Wasserfall und gar nicht agil. Wo bleibt da der agile Gedanke?

Der ist ganz tief verwurzelt: Es ist nicht möglich, im Vorhinein all diese Punkte abzuarbeiten und dann ein perfektes Produkt zu bauen und zu ver- oder betreiben. Das haben unzählige Projekte bewiesen.

Sondern es handelt sich immer um einen Lernprozess. Bei diesem beeinflusst und verändert das über die Problemstellung und die Wirkung von Lösungen Hinzugelernte die Zielstellung, die Auswahl von Lösungskonzepten und auch die Detailanforderungen. Daher erfolgt das Agile Requirements Engineering iterativ inkrementell.

Fehlt die Rolle Agile Requirements Engineer in Scrum?

Wer führt das Agile Requirements Engineering durch? Brauchen wir jetzt Agile Requirements Engineers als neue Rolle im Scrum Team?

Natürlich nicht. All die Tätigkeiten, die unter Agile Requirements Engineering fallen, werden durch das Scrum Team durchgeführt. Auch jetzt schon. Nur häufig unbewusst und nicht im Sinne eines professionellen Engineerings. Eher im Sinne eines „ich hab da mal gehört, Anforderungen macht man jetzt mit User Stories“. Somit gibt es einiges an Qualität zu heben, wie wir in vielen Unternehmen feststellen.

Ein Großteil der Last des Requirements Engineering trägt in Scrum der Product Owner. Dabei ist er aber nicht allein. In einem guten Scrum Team ist er zwar verantwortlich, aber das komplette Team ist intensiv beteiligt. Siehe Uncle Bob:

We are not putting code at the center of everything. We are not turning inward and ignoring the business and the customer. […] We are not forgetting that our job is to delight our customers.

Wie kann ich für ein besseres Agile Requirements Engineering sorgen?

Ist Stand bei der Befähigung?

Wie schaffen wir es jetzt, das Produkt Team für ein systematisches Agile Requirements Engineering zu befähigen?

Die Erfahrung in vielen Fällen ist, dass die Developer aus einem Software-Enwickler Hintergrund kommen. Man hat User Stories schon gesehen und kennt eventuell sogar die INVEST Kriterien.

Beim Product Owner ist das häufig weniger der Fall, insbesondere, wenn er aus der Fachabteilung kommt. Mit viel Glück kommt bekommt er eine Schulung (PSPO oder CSPO). Bei meiner eigenen PO Schulung waren jedoch auch viele Teilnehmer, die schon ein oder zwei Jahre Product Owner waren, bevor sie zum ersten Mal eine Schulung besucht haben. Daneben liegt der Schwerpunkt einer PO Schulung in der Regel auf dem Scrum Prozess und weniger auf den Methoden des Agile Requirements Engineering. Ja, man kommt in Berührung damit, aber ohne Vorkenntnisse reicht das nur zu wenig mehr, als zum ersten Stolpern beim Laufen lernen.

Es wird also eine Befähigung speziell für die Vorgehensweisen und Methoden im Agilen Requirements Engineering sowohl für Product Owner als auch für das Development Team benötigt, die auf die speziellen Bedürfnisse eingeht.

Agile Requirements Engineering Schulungen modular an Bedarf anpassen

Aus diesem Grund haben wir bei NovaTec unser Schulungsangebot im diesem Bereich speziell drauf ausgerichtet, modular auf die Vorkenntnisse und Bedürfnisse der Teams anzupassen. Wir beginnen dabei zunächst bei Inhouse Schulungen mit dem neuen modularen Konzept. Folgende jeweils ein-tägige Module bieten wir ab sofort an:

• Agile Requirements Engineering – Grundlagen und Einführung
  Die Einführungsschulung vermittelt eine solide Grundlage in einem Schulungstag: Von der Zielstellung bis in die Tiefen des Requirements Engineering.
• Von Visionen und Werten – Ziele definieren und #ValueFirst
  Die Vertiefung vermittelt in einem Tag die notwendigen Kenntnisse, die Zielstellung zu klären, quantifiziert zu definieren und damit die Fokussierung auf die Lieferung eines Nutzwerts effektiv zu fördern.
• Rasiermesser statt Glaskugel – #NoEstimates und effektives Story Slicing
  Ein großes Thema für viele Teams ist das sinnvolle Schneiden der Stories. Diese Vertiefungsschulung vermittelt mit vielen praktischen Übungen die Kenntnisse effektiver Slicing Methoden.
• Eine User Story – Ein Team – Ein Verständnis
  Unsere bewährte Specification by Example Schulung vermittelt praxisbezogene Kenntnisse, wie BDD in Ihrem Entwicklungsprozess angewendet werden kann.

Das Angebot für die öffentlichen Schulungen stellen wir in der Folge ebenfalls auf das neue Schulungskonzept um.

Und was jetzt?

Der Hebel für die Qualität, den professionelles Agile Requirements Engineering bietet, ist um ein Vielfaches höher, als es in den „nachgelagerten“ Prozesschritten der Entwicklung und des Betriebs durch Software Craftsmanship, Testen etc. erreicht werden kann. Ignorieren wir nicht diesen Hebel, sondern nutzen wir ihn, um die Stakeholder zu begeistern! Ein erster Schritt dazu kann unsere neue Einführungsschulung Agile Requirements Engineering sein.

Die Schulungen sind natürlich nur ein Teil. Coaching und Vorleben in Teams ist der zweite Teil des NovaTec Angebots. Beides trägt wesentlich zur Qualitätsverbesserung im Agile Requirements Engineering und damit im gesamten Produktprozess bei. Qualität fängt ganz vorne an! Sprechen Sie uns an.