Agile Migration

Warum werden Migrationsprojekte gestartet?

Der häufigste Trigger zum Start eines Migrationsprojektes sind Lifecycle-Themen, oft technisch getrieben:

• Eine eingesetzte Software oder Plattform wird vom Lieferanten nicht länger unterstützt, es muss auf eine neue Version oder gar auf eine andere Technologie migriert werden.

• Eine eingesetzte Technologie entspricht nicht mehr dem aktuellen Stand der Technik. Dies führt zum Beispiel dazu dass Mitarbeitende mit dem nötigen Know-How schwierig zu finden sind, neue Features nicht mehr wunschgemäss umgesetzt werden können, die Software nicht Online- oder Mobile-fähig ist oder die Benutzer die Oberfläche als veraltet und umständlich wahrnehmen und schlussendlich abspringen.

Wozu braucht es einen Product Owner in einem Migrationsprojekt?

“Migrationsprojekte brauchen keinen PO, denn der Anforderungen sind klar: Alles was heute geht, soll morgen genauso funktionieren.”

Ich war in meinem letzten Mandat Product Owner für die Weiterentwicklung eines Content Management Systems (CMS).

Parallel zur Weiterentwicklung arbeitete die IT daran das CMS auf die nächste Version zu migrieren. Die Projekte wurden parallel geführt, da das Business “trotz Migration auch Features mit Business Value von der IT erwartete”, was durch die Migration nicht erfüllt werden konnte.

Das Team für die Weiterentwicklung war dasselbe wie für die Migration.

Dieses Setting warf die erste Frage auf: Woran soll das Team arbeiten? Es gab 2 Backlogs: eines für die Migration und eines für die Weiterentwicklung.

Durch den Weggang des Product Owners gab es Unklarheiten in Bezug auf Prioritäten und Verantwortlichkeiten. Um den aktuellen Arbeitsprozess zu visualisieren und Klarheit zu schaffen, haben wir von Scrum auf Kanban umgestellt. Zudem haben wir so die Anforderungen aus beiden Backlogs auf ein Board gebracht. Die Transparenz half uns dabei die wichtigsten Fragen sichtbar zu machen:

• Wie priorisieren wir die Anforderungen der beiden Backlogs gegeneinander?

• Wie gehen wir mit den Weiterentwicklungs-Anforderungen um?

  • jetzt umsetzen (Version 1)

  • 2x umsetzen (Version 1 + 2)

  • später umsetzen (Version 2)

• Wer trifft diese Entscheidungen?

Für das Fach sind Migrationsprojekte wertlos - sie bringen dem Kunden keinen direkten oder sichtbaren Mehrwert. Wenn man jedoch die Prozesse gleichzeitig optimiert oder neue Features mitliefert, dann wird das Migrationsprojekt auch für das Fach spannend. Kann man so noch von einem Migrationsprojekt sprechen? Gibt es überhaupt 1:1 Migrationen, sodass “vorher und nachher alles genauso funktioniert”? Oder anders gefragt: Macht es Sinn bei einer Migration “nur” technische Belange zu beachten?

Ich würde sagen es ist kein reines Migrationsprojekt mehr, wenn Prozessoptimierungen und neue Funktionalitäten Teil des Backlogs werden. Ich denke, dass es keine 1:1 Migrationen gibt, da die neue Version immer Änderungen gegenüber der alten Version enthält - das zieht aus meiner Sicht immer Anpassungen technischer oder fachlicher Art nach sich. Die letzte Frage bzgl. Sinnhaftigkeit ist nicht ganz so einfach zu beantworten… Ein wichtiger Punkt ist sicherlich der Zeithorizont. Wenn eine Migration sehr lange dauert, möchte das Fach zwingend auch Neues für die Endkunden mitliefern. Andererseits bedeutet mehr Arbeit auch immer mehr Zeit. Oder gibt es die Möglichkeit weniger wichtige Features durch neue Features zu ersetzen für den GoLive-Termin? Das würde jedoch bedeuten dass nachher nicht “alles genauso funktioniert wie vorher”. Bei der Migration von Standardsoftware kann möglicherweise auch das Customizing minimiert werden in der neuen Version.

All diese Punkte sind bei meinem Mandat aufgetreten. Zudem wurde nach einem halben Jahr Migration und Weiterentwicklung noch ein weiteres Projekt gestartet, welches auf die Version 2 einen grossen Impact hatte. So sah dann die Migration schlussendlich folgendermassen aus:

Die Weiterentwicklungen für die Version 1 mussten für Version 2 nochmals gebaut werden, deshalb haben ich im Austausch mit den Stakeholdern versucht diese Wünsche auf ein Minimum zu beschränken.

Damit das Team ganz klar wusste was sie zu tun haben, wurden all diese Anforderungen in ein Backlog übernommen und durch mich als Product Owner priorisiert. Natürlich erfolgte diese Priorisierung immer in Absprache mit den Stakeholdern.

Fazit: Es braucht einen PO für das Backlog Management in Migrationsprojekten - denn sie werden nie 1:1 Migrationen sein.

Plangetrieben versus wertgetrieben

Agile Projekte sind wertgetrieben. Durch die Veränderungen der Umwelt braucht es eine ständige Priorisierung der Anforderungen, damit nach der definierten Zeit und dem festgelegten Budget das aus Kundensicht wertvollste Produkt entsteht.

Das heisst, dass durch die oben genannten Veränderungen - zusätzliche Features aufgrund der Weiterentwicklung und dem Projekt X - trotzdem Geld- und Zeitvorgaben eingehalten werden können, wenn das Business bereit ist Anforderungen zu verschieben. Wenn keine Depriorisierung stattfindet, wird früher oder später doch am Budget oder am Zeitplan geschraubt. In meinem Mandat hat das folgendermassen ausgesehen:

Die strenge Einhaltung von Geld und Zeit hätten das Business gezwungen eine der folgenden Entscheidungen zu treffen:

1. keine Weiterentwicklungen mehr bis zum Launch von Version 2

2. Projekt X erst nach dem Launch von Version 2 starten

3. Backlogitems streichen, damit Zeit- und Geldvorgaben trotzdem eingehalten werden können

### Persönliche Learnings

• es gibt keine 1:1 Migration

• parallele Projekte führen zu Verzögerungen von Projektabschlüssen

• Migrationsprojekte werden seitens Business nicht als wertvoll für den Kunden betrachtet