10 Erfolgsfaktoren für das Anforderungsmanagement in agilen Software-Großprojekten

Eine der Hauptaufgaben des Product Owners in agilen Softwareprojekten ist es, die Produktanforderungen mit dem Kunden abzustimmen und in sogenannten User Stories zu beschreiben. Diese werden dann von den Entwicklern Stück für Stück in Form von darin heruntergebrochenen Tasks umgesetzt. Nach jeder Entwicklungsiteration – dem Sprint – entsteht ein auslieferfähiges Ergebnis. Die Abstimmung der User Stories und Akzeptanzkriterien ist ein zentraler Prozess der agilen Entwicklungsmethodik, der in der Praxis meist mehrere Abstimmungschleifen durchläuft.

Was aber, wenn der Product Owner und sein Team nicht alleine an einem Softwareprodukt arbeiten, sondern 17 weitere Teams mit vielen Abhängigkeiten untereinander beteiligt sind? Wenn es auch viele Kunden mit konkurrierenden Zielen gibt, die teilweise international verteilt sind und zum Teil selbst große Softwareprojekte mit eigenen Zeitplänen repräsentieren? Dann wird das Anforderungsmanagement im Projekt zu einer besonderen Herausforderung auf dem Weg vom Wunsch zur Wirklichkeit.

Mit unseren Erfahrungen aus der agilen Entwicklung webbasierter Softwareanwendungen haben wir die 10 wichtigsten Erfolgsfaktoren zusammengefasst, damit das Anforderungsmanagement auch in agilen Großprojekten gut und effizient funktioniert:

1. Die Scrum-Rollen „Kunde“ und „Product Owner“ werden beide ausgefüllt.

In Filmsprache übernimmt der Kunde die Rolle des Produzenten und der Product Owner die Rolle des Drehbuchautors. Der eine fordert das Produkt an, der andere gestaltet es. In vielen Projekten werden diese beiden Rollen vermischt bzw. eine davon wird gar nicht gelebt. Das führt zu einem Vakuum bei der Entwicklung der Produkt-Vision und der fachlichen Prioritäten.

2. Der Kunde trägt die Produkt-und Release-Vision mit.

Die Produkt-Vision ist sowohl fachliche Klammer als auch Motivationsfaktor für die Teams. Deswegen ist es eine wichtige Aufgabe des Product Owners, diese Vision permanent dem Team zu vermitteln. Aber nur wenn der Kunde diese Vision voll mitträgt, wird das Produkt letztendlich seine Anforderungen treffen.

3. Die Teams kennen die übergreifende Produkt- und Release-Vision.

Die Teams sollen nicht nur die Vision für das eigene Team, sondern für das ganze Produkt kennen. Nur so verstehen sie sich als Teil des Ganzen und unterstützen im Bedarfsfall auch gerne andere Teams.

4. Der Kunde steht für das Review zur Verfügung.

Agile Projekte leben von einem ständigen Lernzyklus. Wird das Review vom Kunden nicht wahrgenommen, fehlt eine wichtige fachliche Feedbackschleife zum Produkt und damit zum Entwicklerteam.

5. Scrum of Scrum wird für Product Owner, Scrum Master und technische Architektur gelebt.

Wenn viele Scrum Teams an einem Produkt arbeiten, werden Product Owner und Scrum Master jeweils in eigenen Gruppen – im sogenannten Scrum of Scrum – organisiert. In diesen Gruppen werden teamübergreifende Fragen geklärt. Nur wenn das Konzept des Scrum of Scrum auch die technische Architektur umfasst, können softwarearchitektonische Inkonsistenzen verhindert werden.

6. Es gibt nicht zu viele Teams.¹

Nach unserer Erfahrung sind mehr als 7 Teams in einem Projekt nicht effizient mit klassischen Scrum-Methoden steuerbar. Die Gruppe der Product Owner und Scrum Master überschreitet dann die optimale Teamgröße. In einem Software-Großprojekt ist allerdings oft eine größere Skalierung notwendig. In diesem Fall sind die Teams in einzelnen Zellen z.B. nach Features oder Produktkomponenten zu organisieren, um die Komplexität beherrschbar zu machen und die Teamgrößen immer übersichtlich zu halten.

7. Die Abhängigkeiten zwischen den Teams sind gering.

Starke Abhängigkeiten zwischen den Teams führen zu ungeplanten Anforderungen, die außerhalb des Backlogs vorbeigesteuert werden. Das ist Gift für eine effiziente Abarbeitung der User Stories und demotiviert die Teams.

8. Anforderungen von abhängigen Teams werden über die Product Owner eingesteuert.

Wenn sich größere Abhängigkeiten zwischen den Teams nicht vermeiden lassen, sind diese im Scrum of Scrum über die Product Owner einzusteuern. Das bremst zwar scheinbar die schnelle Hilfe für das Nachbarteam aus, sichert aber auf Dauer eine bessere Planbarkeit des Gesamtprojekts.

9. Es gibt ein übergreifendes Anforderungsmanagement für Großprojekte mit vielen Anforderern

Wenn es nicht mehr den einen Kunden gibt sondern viele Anforderer aus unterschiedlichen Initiativen und Projekten, dann ist für große strategische Anforderungen ein vorgeschaltetes Anforderungsmanagement sinnvoll. Nur so bekommen die Product Owner die Anforderungen mit ausreichender Stabilität und fachlicher Tiefe.

Die Aufgaben eines solchen Anforderungsmanagements sind:

a.    Sicherstellung der Ende-zu-Ende-Betrachtung der Anforderungen über alle Projekte hinweg.
b.    Prüfung der unternehmerischen Relevanz angeforderter Themen.
c.    Herbeiführung der Entscheidungen im Change Control Board.
d.    fachliche Aufbereitung von Themen für die Product Owner.
e.    Verdichtung der Sprintergebnisse und Schaffung von Transparenz über den Stand der Anforderungen für die anfordernden Projekte.

10. Das übergreifende Anforderungsmanagement ist Teil des Multiprojektmanagements bei sehr großen anfordernden Initiativen.

Das Multiprojektmanagement sorgt für die richtige Auswahl und den richtigen Schnitt der Projekte. Dazu leistet das übergreifende Anforderungsmanagement einen zentralen Beitrag, da es die verschiedenen Fachbereichsanforderungen aus Unternehmenssicht strategisch zusammenführt.