Agile Projekte erfolgreich umsetzen

Mittlerweile haben sich agile Vorgehensweisen in IT Projekten etabliert, glaubt man den vielen Berichten zu solchen Projekten. Nicht alle diese Projekte sind wirklich erfolgreich und bei vielen Umsetzungen handelt es sich nicht wirklich um agile Vorgehensweisen. Die Einführung von „Sprints“ und „täglichen Stand Ups“ machen noch kein erfolgreiches IT-Projekt aus. In diesem Blogbeitrag möchte ich gerne auf Basis eines erfolgreichen Projekts, bei dem wir eine Entsorger Plattform für die Firma Redooo realisiert haben, auf die wesentlichen Erfolgsfaktoren eines agilen Projektes eingehen.

Vertrauensvolle Zusammenarbeit Von Auftraggeber und Projektteam

Grundvoraussetzung in einem agilen Projekt ist eine vertrauensvolle Zusammenarbeit zwischen Auftraggeber und dem ausführenden Projektteam. Beide Parteien müssen gemeinsam an dem Projekterfolg arbeiten und eine offene Kommunikations- bzw. Feedbackkultur leben. Nur so lassen sich die Herausforderungen, die sich in einem IT-Projekt immer ergeben, sinnvoll lösen und mit dem gemeinsamen Blick auf das gewünschte Ergebnis aus dem Weg räumen.
In diesem Zusammenhang ist es besonders wichtig, dem Auftraggeber genau zu erläutern, wie das Projekt ablaufen wird und wie die Rollen und Verantwortlichkeiten zwischen Auftraggeber und Projektteam verteilt sind. Nur mit einer umfangreichen Integration des Auftraggebers in das Projektgeschehen sowie einem transparenten Informationsaustausch wird ein agiles Projekt tatsächlich erfolgreich sein.

Rollenbesetzung und enge Einbindung der Auftraggeber

Eine der wichtigsten Faktoren im Rahmen einer agilen Vorgehensweise ist die klare Definition der Rollen sowie eine sehr enge Einbindung von allen beteiligten Personen des Auftraggebers in die Projektkommunikation.
Aus den Erfahrungen diverser Projekte zeigt sich hier insbesondere, wie wichtig die Rolle des Product Owners ist. Oft fehlt die entsprechende Erfahrung auf Seiten des Auftraggebers für die entsprechende Rolle. Gerade bei der Priorisierung des Backlogs – also der Anforderungen – sowie der Definition eines Ergebnisses, dass den minimalen Eigenschaften und Anforderungen entspricht (minimal viable product, MVP) für den nächsten Sprint ist es erforderlich, alle Details zu betrachten und zielführend zu bewerten.
Wir haben daher gute Erfahrungen damit gemacht, einen erfahrenen Architekten bzw. Business Analysten auf Seiten des Projektteams als „Proxy Product Owner“ zu etablieren. Dieser sollte in der Lage sein, die Prozesse des Kunden sowie dessen Anforderungen zu verstehen und diese mit den Herausforderungen einer IT-Umsetzung abzugleichen. Ziel des Proxy-Product Owner ist es die wahren Anforderungen bzw. die wirklich wichtigen Details heraus zu arbeiten und mit dem Kunden gemeinsam die Kriterien für die kleinst mögliche Anforderung, die zu dem gewünschten Mehrwert führt abzustimmen.

Story Mapping als Bindeglied zwischen IT und Fachbereich

Auch im Kontext eines agilen IT-Projekts ist die größte Herausforderung ein gemeinsames Verständnis von Fachbereich und Entwicklern hinsichtlich der Anforderungen bzw. der gewünschten Ergebnisse zu erzielen. Ziel der agilen Vorgehensweise ist es u.a., innerhalb eines festgelegten Sprints, immer ein nutzbares Ergebnis zu liefern, welches dem MVP entspricht.
Damit dies gelingt und der Fokus des Kunden bzw. des Auftraggebers immer im Vordergrund steht, werden die notwendigen Aktivitäten gemeinsam ermittelt und aus Benutzersicht grob beschrieben. Auf dieser groben Ebene können dann Geschichten (Stories) aus den Aktivitäten zusammengestellt werden.
Ich möchte dies nun anhand unseres Projektes erläutern: Redooo ist eine Plattform, mit der Container zur Müllentsorgung bestellt werden können. Eine mögliche Story in diesem Projekt wäre also zum Beispiel die Bestellung eines Containers. Diese Story teilt sich u.a. in folgende Aktivitäten auf:

• Benutzeranmeldung
• Container auswählen
• Liefertermin festlegen
• Bestellung absenden

Unterhalb der jeweiligen Aktivitäten werden dann Unteraktivitäten (Sub-Tasks) definiert, die Varianten, Sonderfälle oder sonstige Detailaktivitäten beschreiben. Auch diese werden wieder nur grob aus Benutzersicht beschrieben.

Abb. 1: Die Story-Map einer Bestellung

Irgendwann gelangt man dann zu dem Gesamtbild der umzusetzenden Anwendung, in der möglichst alle Stories mit ihren Aktivitäten und Unteraktivitäten aufgeführt sind. Natürlich können diese im Laufe des Projektes auch wieder ergänzt oder verändert werden.
Mit der so entstandenen Story-Map (Landkarte aller Aktivitäten) lassen sich einzelne Releases bzw. die jeweiligen Sprints recht gut planen. Wichtig hierbei ist immer, dass man die Prioritäten im Hinblick auf den aktuell größten Mehrwert für den Auftraggeber definiert und danach die jeweiligen Arbeitspakete schneidet.

Automatisierte Entwicklungsumgebung und die richtige Architektur

Der Erfolg eines agilen Projekts hängt aber nicht nur von Einführung von SCRUM als agile Vorgehensweise ab. Wirklich agil wird man nur, wenn man es schafft, den gesamten CI/CD Prozess zu automatisieren (Continuous Integration/Continuous Deployment). Was nutzt es, wenn die Entwicklung schnell und flexibel in entsprechenden Sprints abläuft und man dann an den Stellen hängt, wenn es darum geht die Ergebnisse zu testen und in Betrieb zu geben.
Dies schafft man nur, wenn man einen vollständig automatisierten Softwareentwicklungsprozess (Development Pipeline) implementiert und dafür sorgt, dass auch möglichst sämtliche Tests automatisiert ablaufen und im Fehlerfall ein automatisiertes Feedback an die Entwickler gegeben wird. In unserem Portal-Projekt haben wir mittlerweile die Automatisierung so weit getrieben, dass auch die Bereitstellung der Apps in den jeweiligen Stores quasi mit dem Einchecken des Softwarecodes voll automatisiert abläuft.
Wesentlicher Bestandteil einer solchen automatisierten CI/CD-Strecke ist auch die Wahl einer geeigneten Architektur. Bei neuen Systemen, wie die entwickelte Entsorger-Plattform, kommt man um eine Microservice Architektur nicht mehr vorbei. In unserem Fall haben wir eine Docker-Architektur in Verbindung mit Kubernetes innerhalb der Microsoft Azure-Cloud realisiert.
Das Gesamtergebnis von Architekturkonzept und automatisierter Development Pipeline sorgt dafür, dass ohne Downtime neue Funktionen oder Anpassungen bestehender Funktionen quasi per Knopfdruck produktiv gesetzt werden können. Spezielle Zeitpunkte für Releasewechsel sind damit Geschichte. Sobald ein neues Feature bereitgestellt werden soll, kann dieses direkt eingeführt werden.

Fazit

Der Erfolg eines agilen Projektes hängt von vielen Faktoren ab und wird nicht allein durch die Einführung von agilen Vorgehensweisen, wie z.B. SCRUM, erreicht. Eine offene und transparente Zusammenarbeit zwischen Auftraggeber und IT-Team ist genauso wichtig, wie die Wahl der Architektur und der Automatisierungsgrad bei der Anwendungsentwicklung.