Im ersten Teil haben wir gesehen, dass am Anfang eines agilen Veränderungsprozesses zum einen das Commitment von Seiten des Managements vorhanden sein sollte und zum anderen die Agile Transition mit einem kompetenten Team steht und fällt, das den Wandel von Anfang an begleitet. Ist das Team aufgestellt, kann es nun endlich losgehen – nur wie anfangen?

Statt viel Zeit mit der Erstellung eines theoretischen Konzepts und eine Projektplans für die Agile Transition zu verbringen (was ja eigentlich üblich ist, wenn man einen "Top-Management-Auftrag" erhält), hat man sich früh im Bereich "Digital Business Unit" dafür entschieden, "einfach mal anzufangen".

Die Umsetzung erfolgte entlang eines ersten Piloten in einem Produktteam aus dem Bereich "Mediencenter", einer Cloud-Lösung für Privatkunden der Deutschen Telekom zur Speicherung und Verwaltung von elektronischen Dateien wie Fotos und Videos. Die Kollegen wurden in Scrum geschult, es wurde ein Coaching-Pair aus einem internen Kollegen des "Agile Transition Teams" und einem externen agilen Coach gebildet. Und man hat einfach angefangen, agil zu arbeiten.

Probleme identifizieren und lösen

Sehr schnell tauchten die ersten Hindernisse auf. Einkaufsprozesse, die nicht zu agilem Arbeiten passten, Teamräume, die nicht zur Verfügung standen, Management-Reportings aus der klassischen Projektwelt, die nicht in Einklang zu bringen waren mit der agilen Vorgehensweise und vieles mehr.

Das "Agile Transition Team" hat sich darauf konzentriert, diese Probleme sukzessive abzuarbeiten. Für ganz konkrete Fälle wurden Lösungen gefunden, die häufig der "Blueprint" für eine veränderte Arbeitsweise und Prozesswelt waren. Noch heute arbeiten wir mit dieser Vorgehensweise, um die agile Transition effizient und nachhaltig zu verankern.

So war beispielsweise die Projektsteuerung und Ressourcenallokation für unsere Produkt-Roadmap auf klassisches Projektmanagement nach Wasserfall ausgerichtet und zwar für Projekte, die Monate dauern konnten. Es gab eine klare Unterscheidung der Prozessschritte in

1. Definition der Anforderungen,
2. Prüfen auf Machbarkeit und Schätzen der Realisierungsaufwände,
3. Realisierung der Anforderungen und
4. Testen und Rollout.

Zu jedem dieser Prozessschritte gibt es eigene Anforderungen, die erfüllt sein müssen, und in entsprechenden Entscheidungsvorlagen offiziell genehmigt werden müssen. Also ein klassischer "Stage-Gate-Prozess".

Neue Wege finden und beschreiten

Dieses Vorgehen funktioniert allerdings in Scrum mit seinen kurzen Sprints nicht mehr, an deren Ende nach wenigen Wochen ein lauffähiges Produktinkrement steht, das beim Kunden ausgerollt werden kann – und danach wiederholt sich das Ganze mit neuen Anforderungen.

Genauso gibt es auch kein Lastenheft für die Anforderungen mehr, sondern ein Product Backlog, in dem nur die am höchsten priorisierten Anforderungen genauer beschrieben sind. Kurzum: der bislang genutzte Prozess passte hinten und vorne nicht mehr.

Gemeinsam mit dem Scrum-Team des Mediencenters, dem "Agile Transition Team" und den Prozessverantwortlichen wurden Wege zur Lösung gesucht. Dazu musste bei den Prozessverantwortlichen zuerst einmal ein Verständnis für die Arbeit nach Scrum geschaffen werden. Die Kollegen zeigten dabei eine große Hilfsbereitschaft und Kreativität in der Lösungsfindung. Beispielsweise wurde das Scrum-Artefakt "Backlog" anstatt eines klassischen Lastenheftes akzeptiert. Und für die eigentliche Umsetzungsphase, die in mehreren Sprints über mehrere Monate laufen kann, musste nur noch eine initiale Gate-Freigabe erfolgen. Man vertraute darauf, dass während der Realisierung im Sinne der Produktvision und auf Basis des Product Backlogs das Team bestmögliche Leistungen bringen wird, die nicht kleinteilig kontrolliert werden müssen.