Auch agile Projekte brauchen Vorbereitung!

Wenn wir ein agiles Framework wie Scrum betrachten, so startet die Entwicklung mit einem Backlog, einer Liste von zu erledigenden Aufgaben. Im Scrum-Guide wird neutral von Backlog-Items gesprochen; in der Scrum-Praxis sind das immer noch User-Stories. User-Stories sind allerdings nur eine Möglichkeit, Anforderungen zu definieren. Als Einstieg sicher sehr praktisch, da sie bewusst in Anwender-Sprache und Anwender-Denke formuliert sind. Dass im weiteren Verlauf eines Projektes detailliertere Spezifikationen notwendig sind und dafür andere Formate als User-Stories notwendig sind, werde ich in einem späteren Newsletter behandeln. Hier beschränke ich mich auf den Hinweis, dass eine Liste von Anforderungen in Anwender-Sprache bei weitem nicht ausreicht, um die Anforderungen an eine IT-Anwendung ausreichend zu beschreiben. Für nicht-funktionale Anforderungen sind sie unpraktisch. Anstatt: Maximale Antwortzeit 1 Sekunde für 90 % der Transaktionen, könnte man natürlich eine User-Story schreiben, die so lauten könnte: „Als Anwender des Systems möchte ich in 90 % der Fälle ein Ergebnis innerhalb einer Sekunde ab Abschluss der Dateneingabe angezeigt bekommen, damit ich nicht zu lange warten muss.“ Also im Ernst: wo ist hier der Mehrwert einer User-Story? Gleiches könnte ich auch für Anforderungen an Schnittstellen zu externen Systemen, an Usability-Features etc. argumentieren.

Während für nicht-funktionale Anforderungen User-Stories „nur“ unpraktisch sind, gibt es in anderen wichtigen Themenfeldern Lücken, die den Erfolg von IT-Projekten massiv gefährden. Ein IT-Projekt besteht aus viel mehr als der Software-Entwicklung, wie sie mit Scrum oder XP beschrieben und gestaltet wird. Die frühen Phasen eines IT-Projektes sind mein heutiges Thema. Damit stelle ich nicht den Wert von Scrum, XP oder Lean für die Entwicklungsphase selbst infrage, will aber auf die notwendigen Vorbereitungsaktivitäten hinweisen.

Ein Standard, der alle Phasen eines agilen IT-Projektes abdeckt

Ein Vorgehensmodell, das den vollständigen Lebenszyklus eines Projektes abdeckt, ist DSDM (Dynamic System Development Method), das seit einigen Jahren unter dem weniger sperrigen Namen Agile Business Consortium (ABC) firmiert. Für Mitglieder stehen dort umfangreiche Dokumente inklusive Templates zur Verfügung, aus denen ich hier auszugsweise zitiere. Hier zunächst die Übersichtsgrafik, auf die ich mich in der Folge beziehe. Übrigens war Arie van Bennekum als Vertreter von DSDM im Jahr 2001 einer der 17 Autoren und Unterzeichner des Agilen Manifests.

Dieses Modell macht deutlich, dass auch bei agilen Projekten eine angemessene Planungsphase (Machbarkeit, Grundlagen) vorzusehen ist, bevor eine Umsetzung in Iterationen bzw. Sprints startet. Ebenso sind beim Projektabschluss die erforderlichen Berichts- und Dokumentationspflichten zu erfüllen. Die „evolutionäre Entwicklung“ kann sich an Scrum, XP oder Lean orientieren, das konkrete Setup ist in der Phase „Foundations“ (Grundlagenplanung) zu erarbeiten. Ich kenne kein anderes Vorgehensmodell, das ein solches Vorgehen so klar, einfach und praxisgerecht darstellt.

Es gibt für jede Phase ein oder mehrere ausführliche Templates. Ich finde es auch elegant, dass die Templates nicht Formulare mit mehr oder minder selbsterklärenden Überschriften sind, sondern zu jedem Punkt ausführlich und auch anhand von Beispielen erläutert wird, welche Inhalte an dieser Stelle zu erarbeiten sind.

Für alle, die meinen, von DSDM noch nichts gehört zu haben, möchte ich die Priorisierung von Anforderungen nach dem MoSCoW-Modell erwähnen, die von DSDM stammt. MoSCoW ist ein mit dem Vokal o angereichertes Akronym für Must, Should, Could, Won’t.

Die Vorbereitungsphasen

In der Vor-Projekt-Phase geht es darum, die Entscheidung zu treffen, ob ein Projekt gestartet wird und die Ziele festzulegen. Es sind die typischen Aufgaben eines Projekt-Portfolio-Managements, die hier nicht weiter erläutert werden müssen.

Die Machbarkeitsstudie ist kein Spezifikum dieses Vorgehensmodells, wird aber in den agilen Frameworks nicht explizit genannt. Auch bei SAFe, wo man es am ehesten erwarten würde, sind solche Überlegungen nur partiell an verschiedenen Stellen vorgesehen, so unter dem Titel „Lean Business Case“ und als Teil des PI-Planning-Events. Ich finde es logisch und geradezu zwingend, eine Machbarkeitsstudie vor dem Start eines Software-Entwicklungsprozesses durchzuführen. Das ganz im Sinne des Postulats Nr. 10 des agilen Manifests, dass „die Kunst, die Menge nicht getaner Arbeit zu maximieren“, essenziell ist.

Im DSDM-Template für die Machbarkeitsstudie wird deren Soll-Ergebnis so beschrieben (von mir übersetzt, gekürzt und bearbeitet):

• Skizzenhafte Beschreibung einer oder mehrerer Lösungen, mit denen die Geschäftsanforderungen und Projektziele erreicht werden können.

• High Level Business Case mit einem in dieser Phase noch großen Schätzkorridor, einschließlich dem erzielbaren Nutzen, einem vertretbaren Budget, den kritischen Erfolgsfaktoren sowie den wesentlichen Annahmen, die den Aussagen zugrunde liegen.
• Eine (gemäß MoScoW) priorisierte Anforderungsliste.
• Je nach Umfang des Projektes und Relevanz für die Geltung der Machbarkeitseinschätzungen auch eine Definition der Lösungsarchitektur, des Entwicklungsansatzes, des Projektmanagementansatzes und der Roadmap der Umsetzung.

Auf Grundlage der Machbarkeitsstudie ist wieder eine Entscheidung über das weitere Vorgehen zu treffen, einschließlich der Entscheidung, das Vorhaben nicht mehr weiterzuverfolgen. Wenn möglich, sind Lösungsvarianten bereits jetzt auszuscheiden, so z.B. der Einsatz von Standard-Software versus Individualentwicklung.

Meines Wissens in keinem anderen agilen Vorgehensmodell so klar gefordert und beschrieben ist der nächste Schritt, die Grundlagenplanung. Deren Lieferobjekte sind (von mir übersetzt, stark gekürzt und bearbeitet):

• Projektziele.
• Beschreibung des ausgewählten Umsetzungsszenarios (Lösungsarchitektur, Organisation der Umsetzung, Phasenplan für die Umsetzung, Lieferobjekte).
• Projektorganisation, insbesondere Vorgehensmodell (Wasserfall, Scrum, Kanban, hybrid), Gremien und Rollen, Qualitäts- und Risikomanagement, Projektcontrolling, Projektkommunikation, Stakeholder- und Change-Management.
• Meilenstein-Terminplan.
• Interne und externe Aufwände (Sourcing).
• Budget.

Auch hier ist wieder zu entscheiden, ob und wie mit dem Projekt weiter verfahren wird. Es kann z.B. eine neuerliche Durchführung der Grundlagenplanung mit geänderten Parametern beauftragt oder das Vorhaben gänzlich verworfen oder neu aufgesetzt werden.

Wenn nach diesen Vorbereitungsarbeiten ein Umsetzungsprojekt beauftragt wird, so ist diese im Verständnis des ABC immer eine iterative Entwicklung (sie wählen den in der IT-Branche nicht vorbelasteten Begriff „evolutionär“). Diese kann verschiedene Vorgehensmodelle kombinieren und es wird so gut wie immer auch Teilprojekte geben, die am besten gemäß einem Wasserfallmodell abgewickelt werden, weil das gewünschte Ergebnis hinreichend klar definiert werden kann. Das gilt immer für die Beschaffung von Lizenzen und Infrastruktur, aber auch für den Zukauf von Leistungen externer Partner, für die ein klassischer Werkvertrag mit allen damit verbundenen Vorteilen geschlossen werden kann.

Die Post-Projekt-Phase

Je nach Umfeld eines Projektes und den spezifischen Gegebenheiten sind nach erfolgtem Deployment eine Reihe von Aktivitäten erforderlich, deren Relevanz bei agilen und nicht-agilen Projekten gleich ist.

Ich habe dazu den AI-Chatbot von PMI (PMI Infinity) befragt und folgende Antwort bekommen (das gleich als Hinweis auf dieses großartige Angebot von PMI, gratis für alle Mitglieder):

Hier sind einige wichtige Aktivitäten, die zum Abschluss eines Projekts erforderlich sind:

• Überprüfung der Projektziele und -anforderungen, um sicherzustellen, dass alle Ziele erreicht wurden.
• Überprüfung des Projektbudgets und der Ressourcen, um sicherzustellen, dass alle Kosten und Ressourcen effektiv genutzt wurden.
• Überprüfung des Projektzeitplans, um sicherzustellen, dass alle Meilensteine und Fristen eingehalten wurden.
• Überprüfung der Qualität des Projektergebnisses, um sicherzustellen, dass alle Anforderungen erfüllt wurden.
• Dokumentation des Projektergebnisses und der Erfahrungen, um zukünftige Projekte zu verbessern.
• Abschlussbericht erstellen, um das Projekt offiziell abzuschließen.

Diese Aktivitäten können je nach Art und Umfang des Projekts variieren. Es ist wichtig, dass alle Aktivitäten sorgfältig geplant und durchgeführt werden, um sicherzustellen, dass das Projekt erfolgreich abgeschlossen wird.

Einordnung des DSDM-Vorgehensmodells

Mein Bezug auf PMI im vorherigen Abschnitt sollte schon zeigen, dass das Vorgehensmodell des Agile Business Consortiums (ABC) sich gut mit dem Standard von PMI verträgt. PMI hat immer schon und nach wie vor den gesamten Lebenszyklus von Projekten im Fokus. Wieder habe ich PMI Infinity befragt und folgende Antwort erhalten:

Diese Phasen bilden den klassischen Projektmanagement-Lebenszyklus:

1. Projektinitiierung: In dieser Phase wird das Projekt konzipiert und geplant. Es werden Ziele und Anforderungen definiert, Ressourcen und Budgets zugewiesen und ein Projektplan erstellt.
2. Projektplanung: In dieser Phase wird der Projektplan weiter ausgearbeitet und detailliert. Es werden Arbeitspakete definiert, Meilensteine festgelegt und ein Zeitplan erstellt. Auch die Risiken werden identifiziert und bewertet.
3. Projektdurchführung: In dieser Phase werden die geplanten Aktivitäten durchgeführt und gesteuert. Der Fortschritt wird überwacht, Abweichungen werden erkannt und korrigiert und die Qualität wird sichergestellt.
4. Projektabschluss: In dieser Phase wird das Projekt offiziell abgeschlossen. Das Ergebnis wird überprüft und dokumentiert, Erfahrungen werden ausgewertet und ein Abschlussbericht wird erstellt.

DSDM differenziert die Planungsphase in Machbarkeitsstudie und Grundlagenplanung, was eine sinnvolle Unterteilung ist, bei kleineren Projekten aber auch in einem Schritt erledigt werden kann. Auch die Durchführungsphase wird bei DSDM in Evolutionäre Entwicklung und Deployment unterteilt.

Diese Querverweise von DSDM auf PMI sollen demonstrieren, dass verschiedene Frameworks unterschiedliche Schwerpunkte setzen und man daher mehr als ein Framework kennen und nutzen sollte. PMI stellt zweifellos den umfassendsten Ordnungsrahmen zur Verfügung, der eine projektspezfische Anpassung (Tailoring) ausdrücklich vorsieht und fordert. Dafür bietet DSDM eine Fülle an wertvollen Inhalten.

Nach einem durchaus aufwändigen Zertifizierungsprozess darf ich mich übrigens als „Agile Business Catalyst“ bezeichnen, also als jemand, der qualifiziert ist, die Anwendung von DSDM als Berater und Coach zu unterstützen.

In diesem Beitrag habe ich mich auf die Vorbereitungsphase von agilen Projekten konzentriert und die Impulse vorgestellt, die ABC dazu bietet. ABC stellt über die oben genannten Templates hinausgehend umfangreiches Material zur Verfügung, so z.B. auch Vertragsmuster, Checklisten und Planungsdokumente für Planung, Reviews, Abnahmen etc. Ich kann die Mitgliedschaft bei ABC für Personen oder auch für Organisationen sehr empfehlen.