Wir wollen agil arbeiten – aber wo gehts los? Die Herausforderung des ersten agilen Projekts in einem Konzern

Kurzzusammenfassung der Lessons Learned

• Wenn keine Erfahrung im agilen Arbeiten vorhanden ist – mindestens zum Start und der Projektvorbereitung einen Agile Coach dazunehmen, um effizient die Methodik zu verinnerlichen und Doppelarbeit zu vermeiden
• Einfluss auf Kultur und Organisation eines Unternehmens nicht unterschätzen – Mitarbeiter von Anfang an mitnehmen und einbinden
• Mut haben, Prozesse neu zu denken – insbesondere Projektcontrolling und -dokumentation aus dem Wasserfall lassen sich nicht 1:1 auf agiles Vorgehen abstrahieren

Agil arbeiten – das möchten und versuchen gerade viele. Der Mehrwert davon ist schnell klar – als Projekt mit klarer Vision aber noch unklarem Weg dorthin, kann man sich dank der agilen Vorgehensweise seinem Ziel iterativ und flexibel nähern.

So weit, so gut. Aber wie arbeitet man denn richtig agil und wo und wie startet man am besten, wenn man das noch nie gemacht hat?

Vor diesen Fragen stand unser Kunde, ein Konzern im Energiesektor, als er sein erstes agiles Projekt in der Konzerngeschichte ins Leben gerufen hat: Ziel war die Implementierung eines Kundenportals. Und es kam direkt noch eine weitere Herausforderung hinzu, denn es sollte zeitgleich auch noch das erste Cloud-Projekt des Konzerns werden.

Ausschreibung

Aufgrund der Größe musste dieses Vorhaben europaweit ausgeschrieben werden. Hier kommen wir schon an die erste und mit größte Herausforderung bei einem derartigen Vorhaben: Das Definieren des Ausschreibungsgegenstands. Denn wenn man noch nicht genau weiß, wie das Produkt ausgestaltet sein soll, wie kann man die konkreten, inhaltlichen Anforderungen formulieren und auch das Budget und damit den zu erwarteten Preis planen?

Unsere Erkenntnis: Allein und ohne Vorkenntnisse im agilen Arbeiten und in der Softwareentwicklung geht das nicht.
Bei unserem Kunden wurde für die Ausschreibung bereits ein Backlog definiert bis hinunter auf die User Story-Ebene und darauf basierend ein Budget geplant. Nach knapp einem Jahr Projektlaufzeit kann man sagen, dass dieses ursprüngliche Backlog (definiert ca. vor 3,5 Jahren) nur noch kleinste Überschneidungen hat mit dem Scope, den wir nun wirklich im Projekt umsetzen. Dies liegt zum einen daran, dass sich oft über einen meist langen Ausschreibungszeitraum die Anforderungen ändern, zum anderen, dass die Anforderungen sich ohne Kenntnisse von möglichen Umsetzungsoptionen nicht zielführend formulieren lassen.

Wir empfehlen daher hier zwei Ansätze: 

1. Wenn das Ziel und die Anforderungen schon relativ konkret sind: Bei der Grobplanung Experten hinzuziehen (agile Business Analysten, erfahrenen Developer, Agile Coach) und gemeinsam grob die Anforderungen abstecken. Per z.B. Magic Estimation eine Grobindikation vornehmen, darauf noch mind. 15-20 % Puffer dazurechnen.
2. Wenn die Anforderungen sehr unkonkret sind: Ebenfalls Experten hinzuziehen und gemeinsam eine sinnvolle Sprintanzahl und/oder fixe Sprintkosten definieren. Über die Sprintanzahl ist die Zeit abgesteckt, dann sollte der Inhalt eher vage gehalten werden. Alternativ kann ein grobes Ziel definiert werden, dann sollte der Zeitraum allerdings offen gelassen werden.

Vorbereitung

Das Projekt wurde von unserem Kunden ab ca. 6 Monaten vor Projektstart intensiv vorbereitet. Dies ist sehr hilfreich für einen möglichst temporeichen Projektstart, wenn z.B. erste Anforderungen schon definiert und auch Stakeholder informiert und vorbereitet sind.

Für Projekte in einem nicht-agilen Projektumfeld empfehlen wir folgende Vorbereitungspunkte:

• Definieren der Produktvision und Abstimmen mit allen (!) Stakeholdern
• Herunterbrechen der Produktvision in abschließbare Epics
• Klären und Vorbereiten technischer Abhängigkeiten
• Schulen und Informieren der Stakeholder sowie betroffenen Mitarbeiter im agilen Arbeiten
• Identifizieren der wichtigen fachlichen, wie technischen Ansprechpartner und eine frühzeitige Einbindung 

Wenn noch kein agiles Wissen im Konzern vorhanden ist, sollte diese Vorbereitungsphase unbedingt in Zusammenarbeit mit einem Agile Coach (und ggfs. auch einem Business Analysten) passieren. Ansonsten wird oft mit unrealistischen Annahmen und in die falsche Richtung gearbeitet, was dazu führen kann, dass z.B. Epics für das Umsetzungsteam nicht brauchbar sind. Es birgt daher ein großes Risiko, diese Phase kosten- und zeitaufwändig durchzuführen, aber keinen Mehrwert für das Umsetzungsprojekt zu generieren.
So auch geschehen bei unserem Kunden, hier wurde das detaillierte Backlog für die  Ausschreibung bereits vertieft. Aufgrund des fehlenden Vorwissens war der Schnitt und die Inhaltsabgrenzung der Epics teilweise nicht umsetzbar, technische Abhängigkeiten wurden nicht optimal festgesteckt und Lösungen zu wenig weit gedacht – das Resultat war eine Verlagerung der Erarbeitung des Gesamtscopes in die Umsetzungsphase.

Projektstart

Im Juni 2020 ging unser Projekt nun los und beide Seiten hatten eine sehr große Vorfreude und Vorerwartung. Um keinen Leerlauf im Team zu riskieren, haben wir mit einer Ramp-Up-Phase von 2 Sprints (à 2 Wochen) und dafür auch mit einer verminderten Teamgröße gestartet. Ziel hierbei war es, die Rahmenbedingungen des Projekts zu klären (Stichwort: Working Agreements), schnell die Basisarbeiten zu erledigen (z.B. Aufbau der benötigten Infrastruktur und eine initiale Backlogerstellung) und alle offenen Punkte zu klären, die vor einem konkreten Start mit dem Gesamtteam erforderlich sind (Einrichten der Berechtigungen, Aufbau Projekt im Ticketsystem, erste Struktur für die Doku usw.).
Der Ramp-Up-Ansatz hat sich für uns sehr bewährt. Er gibt die Möglichkeit, die Rahmenbedingungen für das Projekt aufzubauen ohne den Druck zu haben, ein komplettes Umsetzungsteam auslasten zu müssen. Zu beachten hierbei ist jedoch, dass das Startteam erfahren sein und alle Disziplinen abdecken sollte (Fachlichkeit, Entwicklung, Infrastruktur und Agile Coaching). Nur so kann das  fehlende Know-How des Kunden bezüglich des agilen Arbeitens und Cloud-Anwendungen entwickelt werden. 

Projektdurchführung

Unser Kunde entschied sich dazu nach Scrum zu arbeiten, was aufgrund eines überschaubaren Projektteams für uns eine gute Entscheidung war und wir dieses Vorgehen auch recht nah am Lehrbuch leben können. Über unseren Projektalltag mit Scrum und die Erkenntnisse daraus wollen wir in einem separaten Blogartikel berichten.

Nur soviel sei gesagt – eine große Herausforderung für Kunden ohne Erfahrungen im agilen Arbeiten ist das Priorisieren im Projektalltag. Wenn die Anforderungen an ein Produkt aus allen Ecken herein flattern, die ersten Reviews gut liefen und das Feedback und die Ideen der Stakeholder immer mehr werden, dann ist es schwer, auch einmal “Nein” zu sagen. Auch hier greift die Rolle des Agile Coachs bzw. Scrum Masters, der den Product Owner auch in dieser wichtigen Funktion unterstützen muss und ihm hilft, die richtigen Dinge oder die Dinge richtig umzusetzen gemeinsam mit dem Team.

Projektcontrolling/-steuerung

Ein Thema, was man im agilen Kontext selten hört, ist das Thema Steuerung und Controlling. Für alle agilen Gurus ist dies meist ein rotes Tuch, aber insbesondere in einer Mischwelt aus Agile und Wasserfall ist eine gute Planung und Steuerung essentiell.

Grundsätzlich heißt agil schon einmal nicht ungesteuert! Es gibt zwar keine Schätzungen auf Personentage oder ähnliches, aber man möchte und muss als Scrum Team Aussagen darüber treffen können, wo man steht und wie man den nächsten Meilenstein erreichen möchte. Wichtig dabei ist, es kann und darf Abweichungen vom Plan geben, diese sollten aber erklärbar bzw. nachvollziehbar sein.

Die ideale Welt, in der “es dauert, so lange es dauert” von allen Stakeholdern akzeptiert wird, gibt es nicht – zumindest nicht in einem Dienstleistungsverhältnis oder in den meisten Konzernen. Die Themen Velocity, Planning Poker und Magic Estimation sind daher beim agilen Arbeit ein wesentlicher Faktor und bieten in der agilen Welt eine gute Basis für eine präzise Planung.

Auch hier kommt allerdings wieder das Thema erfahrenes Team zu tragen. Bei einem eingespielten Team funktionieren Story Point-Schätzungen über Planning Poker meist sehr früh, wodurch schon nach wenigen Sprints eine stabile Velocity ableitbar ist. Sobald eine stabile Velocity erreicht ist und das Backlog einen guten Stand erreicht hat, kann man eine sogenannte Magic Estimation einsetzen, welche es einem Team ermöglicht in kurzer Zeit eine Vielzahl von Stories zu schätzen und damit eine Grobindikation für ein Gesamtbacklog zu erhalten. Wendet man nun die Velocity auf die Ergebnisse der Magic Estimation an, ergibt sich eine Planungsmöglichkeit auf hoher, aber verarbeitbarer Flughöhe. Mit dieser Flughöhe können anschließend Meilensteine bzw. Releases geplant und Priorisierungen durchgeführt werden. Für eine gute Meilensteinplanung reicht jedoch die interne Sicht nicht aus – Abhängigkeiten zu Umsystemen dürfen nicht außer Acht gelassen und Meilensteine müssen unbedingt übergreifend abgestimmt werden.

Insbesondere bei einem ständig wachsenden Backlog (und es ist schlicht normal, dass das Backlog dauernd wächst…) sollten Magic Estimations und Priorisierungs-Workshops in regelmäßigen Abständen durchgeführt werden, um zum einen Abweichungen der aktuellen Planung zu identifizieren und zum anderen die Planung bzw. Priorisierung sinnvoll anpassen zu können.

Unser Fazit daher für die Planung:

• Agil Arbeiten heißt nicht ungeplant / ungesteuert arbeiten!
• es ist eine andere Art von Controlling notwendig und dies ist auch abhängig vom jeweiligen Vertragsmodell
• es sollte die verfügbare Kapazität im Auge behalten werden (Messung und Dokumentation pro Sprint für Hochrechnungen)
• Magic Estimation eignet sich als bewährtes Modell, um relativ früh eine Grobindikation zu erhalten
• es sollten klare Meilensteine benannt werden, insbesondere auch wenn große Abhängigkeiten zu Umsystemen bestehen
• Abhängigkeiten zu Umsystemen sollten frühzeitig identifiziert und eingeplant werden

Fazit

Agil Arbeiten macht Spaß – ja! Und ist oft der richtige Weg für Projektvorhaben. Aber dieser Ansatz erfordert ein ganz anderes Denken, ein gewisses Werteverständnis, Offenheit, Mut, Ehrlichkeit, Spaß an der Kommunikation und der Teamarbeit und ein hohes Maß an Selbstständigkeit. Der Einstieg in die agile Welt ist daher oft eine echte Herausforderung für Unternehmen und für deren Mitarbeiter, denn man muss vieles hinterfragen, anders arbeiten und viele Prozesse umkrempeln. Er sollte daher sorgsam geplant und in Kooperation mit erfahrenen Coaches und Experten vorbereitet werden.
Wir haben jetzt schon viele Unternehmen bei ihrer agilen Transformation begleitet und freuen uns immer wieder, dass dieser Ansatz große Begeisterung und Motivation bei Mitarbeitern auslösen kann. So werden z.B. unsere Reviews bei unserem Kunden derzeit von immer mehr Menschen besucht, die sich über neue Funktionen freuen, Spaß daran haben, mit zu gestalten und immer wieder live den Fortschritt zu sehen.

Dies bestärkt uns darin, dass es sinnvoll ist, diese am Anfang oft hohen und vielen Hürden zu überwinden und den Einstieg in das agile Arbeiten zu wagen – wir haben noch kein Unternehmen erlebt, was wieder zurück in die alte Welt wollte!