Wer bin ich – und wenn ja, wieviele? Requirements Engineers in der Sinnkrise…

Und es trifft nicht nur die Requirements Engineers (REs), es trifft auch die Business Analysten (BAs), wie ich im Gespräch mit einer Teilnehmerin am Scrum Day erfuhr: „Unsere Entwicklung arbeitet jetzt mit Scrum – und ich weiß gar nicht mehr, was meine Aufgabe ist…“. Dabei ist das Arbeiten als RE/BA in einem Scrum Team herrlich. So vielfältige Aufgaben und Möglichkeiten, sich und sein Wissen einzubringen, habe ich bisher nur beim Arbeiten in einem agilen Team gehabt. Der Transfer der agilen Werte und Prinzipien auf das Requirements Engineering und die Rolle Requirements Engineer in einem agilen Umfeld ist eine Herausforderung für viele Menschen und Organisationen. Die heutigen Zertifizierungen am Markt zu Scrum/Agile und Requirements Engineering haben eines gemeinsam: Sie konzentrieren sich entweder auf das Thema Agilität/Scrum oder auf das Thema Requirements Engineering. Auch “Agile Extensions”, wie sie der BABoK oder das PMI veröffentlicht haben, ergänzen nur die agile Sichtweise, sie bieten keine übergreifende integrierte Sicht. Meine Erfahrung in der Arbeit mit agilen Teams und Organisationen auf dem Weg zu mehr Agilität zeigt jedoch, dass gerade die Verbindung beider Themen in der Praxis Schwierigkeiten macht. Die Transferleistung gelingt nicht oder nur schwer.

Umstellung auf agile Entwicklung im Unternehmen. Die Umstellung auf agile Entwicklung bedeutet für Unternehmen große Änderungen in allen Bereichen. Angefangen von den Entwicklungsprozessen selbst über organisatorische Änderungen bis hin zum Umgang mit Anforderungen. Bekannte Rollen, wie Requirements Engineer oder Business Analyst, werden nicht explizit in den agilen Methoden erwähnt. Scrum schafft mit dem Product Owner eine neue Rolle, die Aspekte des Business Analysten, des Produktmanagers, des Projektmanagers und des Requirements Engineers in sich vereint.

---

„Der Product Owner ist für die Wertmaximierung des Produkts sowie die Arbeit des Entwicklungsteams verantwortlich. Wie dies geschieht, kann je nach Organisation, Scrum Team und Einzelpersonen stark variieren. Der Product Owner ist die einzige Person, die für das Management des Product Backlogs verantwortlich ist.“ (www. Scrum.org/Scrum-Guide)

---

In der Praxis führt das zu vielen Verunsicherungen. Es ist nicht klar,

• inwieweit die Rollen Business Analyst, Requirements Engineer und Produktmanager in der Rolle des Product Owners aufgehen oder
• ob sie diese Rolle ergänzen oder diesem im Rahmen eines Product Owner Teams zuarbeiten.

Häufig fehlt dem Product Owner das geeignete Handwerkszeug, um mit Anforderungen im agilen Sinn zu arbeiten. Das Entwicklungsteam ist in hohem Maße am Requirements Engineering beteiligt, da Anforderungen (in Form von User Stories) sehr früh und in einem oftmals vagen Zustand vorgestellt werden. Die Aufgabe des Teams ist es dann, die Anforderungen durch das Stellen geeigneter Fragen besser zu verstehen, abschätzbar zu machen und die erforderliche Detaillierung mit dem Product Owner abzustimmen. Der Product Owner muss in der Lage sein, Business Anforderungen und die Ziele, die damit verfolgt werden, in geeigneter Weise dem Team zu vermitteln. Wann, wo und wie können REs/BAs mit Ihrem nützlichen Wissen/Praktiken ein agiles Team (PO und Dev.-Team) unterstützen bzw. mitarbeiten? Wie also kann die Rolle Product Owner besetzt werden?

Der Requirements Engineer als Product Owner. Das IREB benennt folgende Haupttätigkeiten eines Requirements Engineers in Projekten:

• Ermitteln,
• Dokumentieren,
• Prüfen/Abstimmen
• und Verwalten von Anforderungen.

Dazu benötigt er neben praktischer Erfahrung und dem entsprechenden RE-Handwerkszeug (das wir voraussetzen) auch folgende Eigenschaften

• Analytisches Denken
• Empathie
• Kommunikationsfähigkeit
• Konfliktlösungsfähigkeit
• Moderationsfähigkeit
• Selbstbewusstsein
• Überzeugungsfähigkeit

Das hilft auch beim Product Backlog-Management, das folgende Tätigkeiten umfasst:

---

• „Product Backlog-Einträge klar formulieren
• die Einträge im Product Backlog so sortieren, dass Ziele und Missionen optimal erreicht werden können,
• den Wert der Arbeit optimieren, die das Entwicklungsteam erledigt,
• das Sicherstellen, dass das Product Backlog sichtbar, transparent und für alle klar ist sowie
• das Anzeigen, woran das Scrum Team als nächstes arbeiten wird und das Sicherstellen, dass das Entwicklungsteam die Product Backlog-Einträge im erforderlichen Maße versteht“

---

Die Aufgaben und Eigenschaften des RE passen also soweit auch für den Product Owner. Aber es gibt 3 ganz entscheidende Unterschiede, derer sich ein Requirements Engineer bewusst sein muss: Als Product Owner übernimmt er die (1)Product-(2)Ownership und trifft (3) Entscheidungen.

1. Product Es geht nicht um die Abwicklung von Projekten; sondern um die Entwicklung eines Produktes – von der Idee bis zur Abkündigung. Sie können ein Produkt auch als Projekt entwickeln, entscheidend ist jedoch, was nach der Entwicklung passiert.

• Ihr Unternehmen entwickelt eine Software, die es dann selbst benutzt oder für das es Services für seine Kunden anbietet, oder die es an Kunden verkauft. Ihr Unternehmen wartet die Software und entwickelt sie weiter. Die Product-Ownership bleibt also in Ihrem Unternehmen.
• Ihr Unternehmen entwickelt eine Software für einen Kunden. Nach Fertigstellung übergibt es die Software an den Kunden, der sie selbst wartet und weiterentwickelt (oder die Weiterentwicklung beauftragt). Das war dann ein Projekt für Sie. Der Kunde wird zum Product Owner.

2. Ownership Der Product Owner ist Eigentümer des Produktes, wie der Name schon sagt. Die Verantwortung für das Produkt liegt bei ihm – von der ersten Idee bis zum letzten Tag, an dem das Produkt besteht. Es geht nicht um die Abwicklung von Projekten, sondern darum, die Verantwortung für ein Produkt vollumfänglich und langfristig zu übernehmen.

3. Entscheidungen treffen Wo Pflichten, da auch Rechte: Mit der langfristigen Product-Ownership kommt auch das Recht, entscheiden zu dürfen, was umgesetzt wird. Damit das Unternehmen erfolgreich bleibt, ist die oberste Maxime für diese Entscheidung immer Wertmaximierung (für den Kunden/für das Unternehmen).

Beweisen Sie Ihre Expertise als Agile Requirements Engineer hier!

Demnächst: Der Business Analyst als Product Owner

PS: Herzlichen Dank für das Leihen des Titelsatzes an Richard David Precht