Das Vorhaben wurde als Wasserfall-Projekt gestartet, «agilisiert» und zwischenzeitlich als «Taskforce» geführt. Schlussendlich nach 3 Jahren «Berg- und Talfahrt» dann mit einem verkleinerten Scope und einer DevOps Organisation stabil und zuverlässig gelauncht.
Die Euphorie
Voller Zuversicht wurde das Vorhaben gestartet. Nach Jahren ohne echte Innovation sollte ein bestehendes Kundenerlebnis erweitert und auf ein neues Level gebracht werden. Die Experience war schnell definiert und die Anforderungen unkompliziert festgehalten. Mit einem Wechsel von einem „Wasserfall-Projekt“ auf ein agiles Vorgehen wurde parallel eine Transformation in die Wege geleitet. Eine schnelle Reaktionsfähigkeit und höhere Transparenz sollten bereits nach kurzer Zeit zu besseren Arbeitsweisen und nachhaltigen Ergebnissen führen.
Die Berg- und Talfahrt
Schnell hat sich gezeigt, dass dieses Projekt doch nicht so einfach verlaufen wird wie ursprünglich geplant. Das Vorhaben wurde geprägt durch 3 Herausforderungen:
Basisinfrastruktur
Die Implementierung des Service sollte auf einer neuen und noch zu erstellenden Cloud-Infrastruktur erfolgen. Um Zeit zu sparen wurde die Entwicklung vom Service parallel zur Infrastruktur gestartet. Die Infrastruktur wurde zudem mehrmals geändert. Auch haben unterschiedliche Versionen von Testumgebung und Produktion, eine fehlende Staging-Möglichkeit und eine hohe Störungsanfälligkeit dazu geführt, dass einerseits die Entwicklung und das Deployment mehrmals durchgeführt wurden, als auch das manuelle Testing divergierende Resultate geliefert hat.
Leistungsumfang
Der Fokus einen „Out of the Box“ Service zu implementieren sollte ein Garant sein, dass die Funktionen zeitnah zur Verfügung stehen. Die kundenspezifischen Erweiterungen sollten auf einem Standard basieren und dem Service einen innovativen „Finish“ verpassen. Mit diesem Scope sollte ein klarer Mehrwert geschaffen und eine Differenzierung gegenüber Mitbewerbern ermöglicht werden. Die Funktionen waren zwar weitgehend fertig entwickelt konnten aber nicht fehlerfrei betrieben werden. Eine Scope-Reduktion wurde regelmässig diskutiert, jedoch nie zugesprochen.
Transformation
Die Verwirrung im neuen agilen Setup war gross und die Unsicherheit spürbar. Ein Crashkurs für Mitarbeiter wurde durchgeführt. Die Arbeiten wurden in einen Backlog geführt und es wurde mit PostIt gearbeitet. Dies bedeutete noch lange nicht, dass man Cross-funktional agil zusammenarbeitet. Es reichte auch nicht aus nur die Tools anzuwenden oder Zeremonien durchzuführen. In der Anfangsphase war von Co-Location auch keine Spur und Teammitglied in Teilzeit eine häufige Regel. Zumindest zum PI hat man sich physisch getroffen. Nicht erledigte Arbeiten wurden auf das nächste PI verschoben und dann mit den geplanten neuen Arbeiten kumuliert.
Die Gewitterfront
Durch die Einführung einer Taskforce wollte das Management das Steuer herumreissen. Gegen aussen konnte man damit zumindest Dringlichkeit signalisieren. Gegen Innen war das Signal jedoch eher kontraproduktiv. Überstunden wurden angehäuft, auf Schulung wurde verzichtet und viele agile Zeremonien wurden ausgesetzt. Zusätzliche Meetings und ein wöchentlicher Projekt-Update für Stakeholder haben zu einer Mehrbelastung und Doppelspurigkeit geführt.
Die nötige Qualität für eine kommerzielle Markeinführung war schwer zu erreichen. Das Projektteam musste sich immer wieder neue Herausforderungen stellen. Mit fortlaufendem Projekt wurde zusehends absehbar, dass ein Launch mit «Full Scope» kaum realistisch war. Eine mögliche Markteinführung wurde deshalb innerhalb des Managements kontrovers diskutiert und ein «Go Live» Entscheid mit reduziertem Scope und Verzicht auf Vermarktung getroffen. Die erste Phase des Projekts und somit unser definiertes „MVP“ des Frühjahrs 2018 entspricht dem heutigen Leistungs- und Serviceumfang.
Der Ausblick
Das Team hat zum Glück dem Sturm standgehalten und hat einen riesigen Fortschritt gemacht. Die Zusammenarbeit im und mit dem Team stimmt, die Transparenz über die geleistete Arbeit besteht und durch Ausbildung konnten neue Skills erworben werden. Die Arbeit kann nun auf mehrere Schultern verteilt und dem T-Shape Anspruch so besser gerecht werden. Die Abhängigkeit zu Lieferanten und Gerätehersteller besteht noch immer. Die nächsten Monate werden nun zeigen, ob die ursprünglich in den Service gemachten Hoffnungen noch erfüllt werden können.
Das Fazit
Die Komplexität vom gesamten Kundenerlebnis, die verschiedenen Abhängigkeiten bei der Infrastruktur und das Zusammenspiel der Lieferanten wurde unterschätzt. Das Vorhaben war überladen, denn die Stakeholder von Business und Entwicklung wollten zu viel gleichzeitig diametral erreichen. Ungeübte Personen wollten im hochalpinen Gelände eine neue Route begehen, statt die Basics auf der grünen Wiese zu erlernen. Experten für agiles Zusammenarbeiten predigen: «Abhängigkeiten gilt es zu reduzieren, die Batchsize zu verkleinern und eine Transformation geht nicht von heute auf morgen». Es braucht den richtigen Fit, kontinuierliche Anpassung und stetiges Lernen. Man muss die agile Idee, die Prinzipien und die Werte verstehen, verinnerlichen und anwenden. Einfach nur ein Framework über die Organisation stülpen bringt nicht den erwünschten schnellen Erfolg.
