Mein Weg vom Skeptiker zum Agile-Enthusiasten

Was die Kolleg*innen bei der Software-Entwicklung längst verinnerlicht hatten, war bei der Betriebs IT noch Neuland: Vorhaben nach der agilen Methode SCRUM abzuwickeln. Wie ist das gelungen und was waren meine Schritte?

Erster Kontakt mit agilen Methoden

Kurz nach meinem Studienabschluss im Jahr 2000 kam ich mit agilen Methoden wie Timeboxing (vorgegebene Zeit für definiertes Ergebnis) in Meetings und Workshops in Kontakt und hatte diese dankbar in meinen Werkzeugkasten integriert. Den ersten Kontakt mit der agilen Methode SCRUM hatte ich bei einer App-Entwicklung mit einem externen Partner. Nach anfänglich grosser Skepsis (Bürokratie, starr), hatte ich bald die Vorzüge als Kunde kennen und schätzen gelernt, z.B. Taktung der Reviews nach jedem zeitfixen Sprint.

Entwicklung vs. IT Infrastruktur

Was in der (Software-)Entwicklung selbstverständlich war, wollte mich für Infrastruktur und Lifecycle Projekte nicht in gleichem Masse überzeugen. In den KMUs wo ich tätig war, waren die Herausforderungen zudem mehr in der Wahl der geeigneten Projekte und erst dann der geeigneten Methode. So beschäftigte ich mich mit dem Aufbau eines schlanken, geschäftsweiten Portfolio-Prozess zur Priorisierung und Strukturierung von Ideen und Vorhaben. Dies führte unmittelbar zur Reduktion von scheinbar wichtigen, aber mangels Business Case wenig rentablen Vorhaben.

Agile Reporting Factory

Nach einem SCRUM-Kurs baute ich eine Agile Reporting Factory auf. Vorausgegangen waren viele hektische adhoc-Aufträge an die IT zur Erstellung von Auswertungen und KPIs.
Die Liste der offenen Aufgaben wurde in einen priorisierten Backlog überführt: Tasks mit gutem Business Case rutschten hoch, waren aber nur ganz oben, wenn sie vollständig definiert waren (Definition von «Done»).
Mit Fit-to-Budget wurden nur so viele «Backlog Items» (Aufgaben) in einen Sprint Zyklus geplant, wie Ressourcen budgetiert waren.
Stakeholder mussten sich jetzt gemeinsam über die Priorisierung, Definitionen der KPIs und Business Cases unterhalten. Es entstand Ruhe für die Entwicklung.

SCRUM Projekt

Im aktuellen Job hatte ich die Neuimplementierung der Fieldservice Lösung (Sprung um drei Version) als geeignetes Vorhaben gewählt, um erstmals im Bereich nach SCRUM zu arbeiten und Vertrauen zu schaffen. Das musste parallel zum Projekt SAP Update auf S/4 HANA laufen, da die Systeme stark verzahnt sind. Es war erwartungsgemäss eine Entwicklung Richtung einem sich bewegenden Ziel und Spezifikationen waren (zu) lange nicht verfügbar. Hier kommen die Vorteile von SCRUM gegenüber klassischen Wasserfall-Projekten besonders gut zum Tragen.

Wie waren wir organisiert?

Der Lieferant stellte das System für den priorisierten Backlog und das Sprint Planning zur Verfügung. Die Sprintdauer legten wir auf vier Wochen fest, um den Meeting-Overhead möglichst klein zu halten. Als SCRUM Master war ich für das methodische Coaching und die Förderung der Zusammenarbeit zuständig. Der Service Verantwortliche übernahm die Product Owner Rolle, und stimmte sich mit Stakeholdern aus dem Business ab. Die Daily Stand-Ups zur Entwicklungskoordination wurden nur beim Lieferanten durchgeführt. Gemeinsam stimmten wir uns wöchentlich ab und bei Bedarf ad hoc.
Am Beginn jeden Sprints wurde das Backlog nach Priorität und Reifegrad sortiert (Backlog Groaming) und die fixen Ressourcen mit Aufgaben belegt (Sprint Planning). Am Ende des Sprints wurden die Resultate allen gezeigt (Sprint Review) und entschieden, was abgenommen wurde (Done).

Dank Neu-Priorisierung bei jedem Sprintbeginn, konnte ein Fit-to-Budget gemacht werden und kurzfristige, aber kritische Korrekturen weitgehend berücksichtigt werden.

Wegen der kurzfristig entschiedenen dreimonatigen Verlängerung des SAP Projekts, wurde auch das Fieldservice Update Vorhaben entsprechen um 3 Monate verlängert. Dies führte zu einem kleinen Budget Überzug, aber auch zu mehr Testing und damit einem ruhigen und erfolgreichen go live.

Erkenntnisse

1. Agile Methoden z.B. Timeboxing oder priorisierter Backlog können auch einzeln ihre Wirkung entfalten.
2. Agile Methoden ermöglichen einen effizienten Umgang mit den Herausforderungen der VUKA-Welt (volatil, unbestimmt, komplex, ambivalent).
3. SCRUM ist eine nützliche Grundlage. Insbesondere kann Komplexität und Kurzfristigkeit besser begegnet werden. Anpassungen können sinnvoll sein, falls sie gut begründbar sind.

Weiterführende Links zum Thema

• SCRUM in 3min erklärt: https://www.youtube.com/watch?v=Ibz9STVjtzI
• Was ist Timeboxing? https://youtube.com/shorts/OyCUgyt71sk?si=pF7fZQNUz0dghZpS
• Agile Grundsätze: https://agilemanifesto.org/iso/de/manifesto.html