Agile Projekte: Schluss mit der Intransparenz

Agile Projekte leben von Kommunikation. Allerdings: Agile Methoden fördern zwar die Kommunikation innerhalb des Teams. Stakeholder, die nicht zum Team gehören, bleiben dagegen oft ausgeschlossen. 

Eine Kombination aus dem traditionellen Wasserfall-Ansatz, in dem nach Phasen reportet wird, und einem Reporting, das den Reifegrad der einzelnen Features darstellt, schafft Transparenz auch nach außen, erleichtert die Arbeit der Teams und fördert die Qualität der Ergebnisse.

Ein wesentliches Merkmal von agilen Projekten ist: Sie sind unterteilt in Sprints, in denen Teilfunktionen des Endprodukts umgesetzt werden. Im Laufe des Projekts wird das Produkt wie ein Puzzle aus den einzelnen Funktionen zusammengesetzt. Da sich jedes Feature zum Zeitpunkt X in einem anderen Reifegrad befinden kann, weist das agile Projekt während seines Entstehens viele Features in unterschiedlichen Zuständen auf.

Das wirkt auf Außenstehende oft chaotisch – und macht sie misstrauisch. Schnell kommt die Frage auf: „Was machen die da eigentlich?“ Und wenn dann das Team diese Frage nicht klar und strukturiert beantworten kann, beginnen die Spekulationen, und der Weg für Fehlinterpretationen ist geebnet. Die Außenstehenden stellen das Projekt in Frage, obwohl womöglich schon wertvolle Teilergebnisse zu verzeichnen sind. Das einzige, was hier hilft, ist Transparenz.

Phasen oder Sprints

Dies leistet eine Kombination aus dem traditionellen Wasserfall- und dem agilen Ansatz: die Feature Progression Map. Vor allem in Projekten mit hoher Skalierung und vielen verschiedenen Implementierungspartnern und Nutzergruppen sorgt sie für einen klaren Überblick. 

Im traditionellen Wasserfall-Ansatz wird in der Regel nach Phasen reportet, in die das gesamte Projekt unterteilt ist. Jede Phase enthält eine bestimmte Menge von Teilerzeugnissen, sogenannten Artefakten, die für das Endprodukt notwendig sind, damit es stabil betrieben und weiterentwickelt werden kann. Das kann ein Architekturentwurf sein, ein Datenbankmodell oder einfach Sourcecode. 

Anhand dieser Teilergebnisse lässt sich der Fortschritt der einzelnen Phasen und damit der Fortschritt des gesamten Projektes ablesen. Sind die Meilensteine erfolgreich, läuft auch das Projekt erfolgreich.

Beim agilen Ansatz wird das Gesamtprojekt nicht in Phasen, sondern in deutlich kleinere Einheiten unterteilt, die sogenannten Sprints. In den Sprints setzt das Projektteam Teilfunktionen des Produktes in Form von Features oder User Stories um. Ziel ist es, möglichst früh ein nutzbares Produkt zu haben. Dabei ist explizit gefordert, das Produkt auf die Features zu reduzieren, die den höchsten Nutzen bringen. Das erste Ergebnis ist ein sogenanntes Minimum Viable Product.

Eine User Story ist ein Leistungsmerkmal, das der Kunde braucht beziehungsweise nutzen will – und zwar nur dessen mindestens erforderliche Funktion, damit es operativ einsetzbar ist. Unter Feature versteht man in der Regel einfach eine Softwarefunktion mit verschiedenen Leistungsmerkmalen – den User Stories.

Damit ein Feature produktiv einsetzbar ist, sind beim agilen Ansatz die gleichen Artefakte notwendig wie beim Wasserfall-Ansatz, nur eben begrenzt auf den Basis-Funktionsumfang des jeweiligen Features. Jede für die Funktion eines Features nicht zwingend notwendige Erweiterung ist ein weiteres Feature beziehungsweise eine oder mehrere weitere User Stories. Während des Entwicklungsprozesses kann sich theoretisch jedes Feature in einer anderen Phase befinden.

Die Feature Progression Map 

Ein gutes Mittel, um dennoch Klarheit über Status und Fortschritt des Gesamtprojekts zu schaffen, ist eine Feature Progression Map. In ihr werden die Zustände der einzelnen Elemente übersichtlich auf einer Karte dargestellt. Dabei werden die Phasen und Artefakte auf der X-Achse eingetragen, die Features auf der Y-Achse. Gut geeignet dafür ist eine Excel-Datei, da sie ausreichend Platz in beide Dimensionen bietet. Und sie erlaubt, den einzelnen Features bei Bedarf zusätzliche Informationen hinzuzufügen.

In die Kreuzungspunkte von Features und Artefakten trägt man den Reifegrad des jeweiligen Artefakts ein, zum Beispiel mit einer Bewertung zwischen 0 und 10. Weist man den Reifegraden Farben zu, ergibt sich auf einen Blick ein gutes Bild über den Fortschritt des Projektes. 

Wichtig ist es, den Reifegrad möglichst eindeutig festzulegen. Dies geschieht anhand der sogenannten Definition of Done (DoD) für jedes Artefakt. Sie definiert, was das jeweilige Artefakt enthalten muss, damit es einen bestimmten Reifegrad hat. Auf diese Weise lässt sich einigermaßen verbindlich festlegen, was beispielsweise ein Reifegrad von 5 bedeutet. Ein einheitliches Verständnis der Bewertungskriterien ist hier entscheidend.

Die Artefakte nach Phasen

Bei den Artefakten ist es in der Regel sinnvoll, nach den Phasen Design, Implementierung (Build /Test) und Betrieb/Rollout zu unterscheiden.

• In der Designphase wird der Zustand der Design-Artefakte bewertet: Anforderungsliste, Usecase, Funktionsmodell, Datenmodell, Prozessmodell, Testfälle zum Beispiel.
• Implementierungs-Artefakte sind beispielsweise Sourcecode, automatisierte Tests und Build-Skripte. In dieser Phase geht es darum, wie viele der geplanten User Stories schon fertig im Sinne ihrer DoD sind. Da sie unterschiedliche Beiträge zum Gesamtnutzen leisten, lässt sich ihr Reifegrad zusätzlich nach ihrem Business Value gewichten. Bei komplexen Features mit mehreren Implementierungspartnern kann es sinnvoll sein, auch den Reifegrad der Integration zu bewerten.
• In der Rollout Phase wird bewertet, wie weit das jeweilige Feature im Sinne der DoD live beim Kunden ist. Artefakte hierfür sind beispielsweise Installationsskripte und Umgebungskonfigurationen, Monitoringkonzept, Handbuch und Benutzerdokumentation. 

Entscheidend: Wie alle Reporting Instrumente ist auch die Feature Progression Map nur so gut wie sie befüllt wird. Dazu ist eine ehrliche, an der Sache orientierte Auseinandersetzung mit dem Entwicklungsfortschritt anhand der Definitions of Done notwendig. Je genauer der Begriff „fertig“ für ein Artefakt definiert ist, desto weniger Interpretationsspielraum gibt es. Und desto klarer der Überblick.

Fazit

Eine nach Art der Feature Progression Map verfeinerte Wasserfall-Methode ist sehr gut geeignet, auch agile Projekte für Stakeholder außerhalb des Teams transparenter zu machen. Wichtig dabei ist, die Stakeholder nicht mit zu viel Detailtiefe zu überfordern. Sie müssen nicht alle Details kennen, die der Projektleiter braucht, um operative Entscheidungen etwa anhand des Prognoseinstruments „Burndown Chart“ zu treffen. Und natürlich funktioniert auch die Feature Progression Map nur, wenn alle Artefakte und Zwischenschritte sowie deren jeweiliger Reifegrad dokumentiert sind.

Als besonders wertvoll erweist sich diese Art des Reportings in Projekten mit hoher Komplexität und vielen verschiedenen Implementierungspartnern und Nutzergruppen. In solchen Projekten sorgt die Map für einen klaren Überblick. Das schafft Vertrauen und damit den nötigen Freiraum, sich inhaltlich voll auf das Projekt zu konzentrieren. 

Kostenlos die Feature Progression Map-Vorlage (Excel) herunterladen

Konrad Krafft ist Gründer und geschäftsführender Gesellschafter des Beratungs- und Softwarehauses doubleSlash Net-Business GmbH mit Sitz in Friedrichshafen. Er hat Allgemeine Informatik mit Schwerpunkt Künstliche Intelligenz studiert und beschäftigt sich seit mehr als 20 Jahren mit der Entwicklung digitaler Services, insbesondere im Bereich von Unternehmensprozessen und Softwareprodukten. Unter anderem befasst er sich mit der Industrialisierung von Software-Entwicklung und neuen digitalen Geschäftsmodellen.

www.doubleslash.de