Nicht nur Startups und Kleinstprojekte beschäftigen sich mit aktuellen Methoden der Softwareentwicklung, sondern auch Großprojekte und Konzerne. Da hier durch die großen Organisationsstrukturen kein einheitliches und kleines Team gebildet werden kann, müssen andere Ansätze bzw. Erweiterungen angewandt werden, um diesen speziellen Anforderungen zu begegnen. Hiermit möchte ich einen Einblick geben, wie das Scaled Agile Framework (SAFe) in einem schon seit Jahren fortentwickelten Projekt zum Einsatz kommt und wie ich dies miterlebt und auch gestaltet habe.
Ausgangssituation
Ein seit über 10 Jahren laufendes Projekt, welches die Softwareentwicklung eines Kassensystems durchführt, sollte vom bestehenden Wasserfall-Vorgehen in ein agiles Vorgehen überführt werden. Hierbei waren ca. 50 Mitarbeiter betroffen, wobei die wenigsten davon schon praktische Erfahrungen in agiler Softwareentwicklung sammeln konnten.
Im Projekt wurde neben der Weiterentwicklung auch die Wartung von den gleichen Personen betrieben. Durch das Wasserfall-Vorgehen konnten nur ca. alle 10 Monate, also faktisch nur zwei Releases pro Jahr, ausgeliefert werden. Nur bei sehr kritischen Fehlern, waren Bugfixes mit großem Einsatz und viel bürokratischem Aufwand zusätzlich zu den geplanten Terminen möglich.
Auf der Auftraggeberseite waren eine Vielzahl von Ansprechpartnern für die verschiedenen Teilsysteme, bzw. mit einer anderen Sicht auf das Gesamtsystem, vorhanden, z.B. Multikanalvertrieb, der teilweise konkurrierende Anforderungen einbrachte und dies durch vielfältige und aufwändige Consulting-Leistung in Einklang gebracht werden musste.
Im Konzern wurden vor dem Start immer wieder Forderungen an das Projekt gestellt, dass von der Idee bis zur Auslieferung weniger Zeit eingeräumt werden kann und dadurch mehr Releases pro Jahr entstehen sollen. Dazu sollten die Projekte mehr Transparenz gewähren und schneller auf aktuelle Themen reagieren. Darüber hinaus wollte das Management mit Scaled Agile Framework (SAFe) ein standardisiertes Vorgehen etablieren und die bestehenden Tools mit einem der am meisten verwendeten Werkzeuge Jira und Confluence ersetzen bzw. ergänzen.
Vorbereitende Maßnahmen
Bevor die bestehende Organisation geändert wurde, traf man einige vorbereitende Maßnahmen. Hierzu zählen SAFe Trainings für alle zukünftig in den Teams arbeitenden Kollegen, SCRUM Master Trainings für die beiden zukünftigen Scrum-Master und Produktschulungen zu den neu einzusetzenden Tools Jira und Confluence.
Nach der Teamzusammenstellung in sieben Teams, die grob in Frontend, Backend, Stammdaten und Infrastruktur aufgegliedert wurden, konnten sich diese über mehrere Tage finden und ihre zukünftige Zusammenarbeit gestalten. Daneben wurden zusätzlich übergreifende Projekte mit einigen Mitarbeitern gestartet, die hierbei Unterstützung geben sollten und gerade die bestehenden Prozesse und Vorgehensweisen für die agile Arbeitsweise anpassen sollten.
Der große Start - Big Bang
Nun kam der große Tag, an dem alle der ca. 50 Mitarbeiter mit der Agilität starten sollten. Ausgerechnet zu dieser Zeit brach aber Covid-19 über die Welt ein und nun sollte sich zeigen, ob alle Vorbereitungen auch diese Situation meisterten.
Wir starteten in das in SAFe vorgesehen Release-Train Product Increment (PI) Planning und waren wohl, mangels der Erfahrung noch etwas ideenlos, wie wir an den anfänglich 3 Tagen über ein paar Stunden hinweg, die Arbeit für ein 10 Wochen PI erledigen konnten. Aber wie es oft so ist, entstand eine passable Eigendynamik in den Teams, so dass wir uns doch helfen konnten und einen guten Plan hatten, was wir liefern können und welche Abhängigkeiten zu den anderen Teams existieren. Also starteten wir in unseren ersten 2-Wochen-Sprint.
Rituale
Die Teams selbst führten in ihren Sprints fünf Regeltermine ein, die für Ihre Arbeit wichtig erschienen und versuchten dabei sich an bestehende Standards aus Scrum und SAFe zu orientieren. Unter den Terminen wurde ein tägliches 15 Min. Daily für einen Statusbericht abgehalten, zum Sprintwechsel eine Vorstellung der eingeplanten User Stories in einem Review-Termin, eine Retrospektive für einen kontinuierlichen Verbesserungsprozess und ein Sprint Planning für neue abzuarbeitende User Stories.
Auch wenn anfänglich noch nicht alles rund lief und man von einem sehr gut funktionierenden Projekt bzw. einer funktionierenden Organisation kam, z.B. taten sich einige Mitarbeiter schwer im neuen Vorgehen und lehnten es schon fast ab in Teams zu arbeiten. Aber wir fanden uns in den Teams immer besser zurecht und konnten immer besser in Eigenverantwortung Aufgaben übernehmen und zuverlässig erledigte Arbeitspakete (User Stories) liefern.
Dadurch, dass wir durch Corona alle im Home-Office arbeiteten, wurde nach jedem Daily ein 15 minütiger “Parkplatz” installiert, in dem wir allgemeinere Themen, die nicht speziell das Projekt betrafen, kommunizierten. Hier wurden z.B. Änderungen an der Infrastruktur, Ergebnisse aus dem kontinuierlichen Verbesserungsprozess, Personalveränderungen oder andere Spezialthemen beantwortet, die ggf. auch nicht das ganze Team betrafen.
Darüber hinaus gab es wiederholt alle 10 Wochen das Release-Train PI Planning, in dem auf Epic-Ebene alle Teams gemeinsam ein Releaseplanning vornahmen und die zeitlichen Abhängigkeiten in ihrer Tätigkeit zu den anderen Teams auflösten. Hierbei bemerkte man auch von Mal zu Mal, dass wir weniger Zeit dafür benötigten und so reichte uns an zwei Tagen ein 2-3 Stunden Zeitfenster dafür.
Zusammenfassung und Fazit
Nach ca. einem halben Jahr konnte man feststellen, dass trotz der Vorbereitung in der Gesamtheit viel Erfahrung in agiler Entwicklung fehlte, von der profitiert werden konnte. So war der Start sehr holprig und man stellte immer wieder fest, dass in alte Muster verfallen wurde, z.B. wurde bei Personalengpässen das Management hinzugezogen und dadurch auf Lösungen außerhalb des Teams gewartet.
Auch der kontinuierliche Verbesserungsprozess wurde anfangs falsch verstanden, so dass jedes Problem vom Scrum-Master mitgenommen wurde und kaum eine Verbesserung aus dem Team erfolgte. Es zeigte sich, dass in einem halben Jahr in Summe kein höherer Output erreicht werden konnte, andererseits aber alle zugesicherten Softwarelieferungen erreicht wurden.
Leider haben einige Verbesserungsvorschläge nicht sofort funktioniert und wurden deshalb schnell verworfen, da sie nicht konsequent verfolgt wurden. Deswegen sollte am kontinuierlichen Verbesserungsprozess gearbeitet und nicht am Status Quo festgehalten werden. Ich denke auch, dass Impulse von außen, z.B. durch ein Coaching, viel Potential freisetzen könnten. Dennoch kann man hier von einem Erfolg sprechen, denn nun kann man mit ca. 5 statt 2 Releases sehr viel öfter liefern als noch im alten Vorgehen. Außerdem wurden nicht nur zum PI Planning, sondern auch zu jedem Sprintwechsel auf neue Gegebenheiten und somit sehr flexibel auf die aktuelle Tageslage reagiert.
Im Gegensatz zu einer konzernweiten Umstellung, bei der wahrscheinlich mehrere Tausend Mitarbeiter gleichzeitig ein agiles Vorgehen beginnen, hat es bei einer projektbezogenen Umstellung der Softwareentwicklungsmethode den Charme, dass schon umgestellte Projekte Ihre Erfahrungen über ein Coaching mit weiteren Projekten teilen könnten. Somit dauert es zwar länger, bis ein Gesamtunternehmen umgestellt werden kann, aber meines Erachtens wird der zu erwartende Produktivitätseinbruch bei einer stufenweise Einführung geringer ausfallen.
