Wie behalte ich bei großen, agilen Digitalisierungsvorhaben die fachliche Übersicht?
Im Juni habe ich Sie an den digitalen genetischen Code erinnert und eine Reihe von Beiträgen aus der täglichen Projektpraxis der PPI angekündigt. Und kaum 4,5 Monate später erscheint der nächste Teil….
Mittlerweile ist eine Erkenntnis bei sehr vielen unserer Kunden angekommen: Große Digitalisierungsinitiativen brauchen ein agiles Vorgehen!
Aber so leicht diese Erkenntnis auszusprechen ist, so anspruchsvoll ist sie in der praktischen Umsetzung – und dies insbesondere, wenn man aufgrund seiner Unternehmensvorgeschichte mit der Digitalisierungsinitiative ein großes Rad drehen will und muss…
Diese Ausgangssituation bedingt normalerweise, dass man seit vielen Jahren größere Investitionen in wesentliche Teile der Anwendungslandschaft unterlassen hat und jetzt erkennt (oft mit externer Hilfe), dass man ein größeres Vorhaben starten muss, um auch in zehn Jahren seine gute Marktposition noch erhalten oder womöglich ausgebaut haben will.
Der Start in unserem aktuellen Projekt, an dem ich Sie teilhaben lassen möchte, war noch relativ geschmeidig. Die kritische Analyse der Ist-Situation hat ergeben, dass für eine erfolgreiche Zukunft eine Digitalisierungsplattform vonnöten ist. Es sind knapp 50 Applikationen identifiziert, die im Rahmen dieser Initiative abgelöst werden sollen. Das Unternehmen wähnt sich bereits auf einem guten Weg in eine agile Vorgehensweise und ein entsprechendes Budget steht auch bereit….
Und voller Enthusiasmus startet man los. Doch schon nach einiger Zeit kommen die Klassiker in Rahmen einer agilen und digitalen Transformation eines Versicherungsunternehmens zu Tage:
- Natürlich sind wir agil, aber ich möchte schon, dass sie mir heute sagen, welches Detailfeature Sie mit dem Release 4/2021 in Produktion bringen wollen (Rolle Vorstand).
- Das wichtigste ist ein gepflegter Product Backlog, in dem alle 3000 Detail-User-Stories jederzeit in aufsteigender Priorisierung so detailliert beschrieben sind, dass die Entwicklung jederzeit starten kann (Rolle Teilzeit-Scrum-Master).
- Natürlich sind wir ein erfahrenes Entwicklungsteam, aber einfach selbstständig auf die Idee zu kommen, wie ich bei der Umsetzung eines fachlichen Geschäftsvorfalls mit mehreren technischen Komponenten so vorgehe, dass ich durch Kapseln von Teilfunktionalitäten auch in einzelnen Sprints Ergebnisse mit echtem Mehrwert zeigen kann, passt nicht zur Kultur unseres Hauses (Rolle Entwickler).
Sie haben natürlich längst gemerkt, dass diese Aussagen überpointiert sind – aber trotzdem sind sie nach meinen Erfahrungen gar nicht so weit von der Realität entfernt.
Und jetzt die besondere Herausforderung: In einem solchen Umfeld sind Sie Teil eines Product-Owner-Teams, das eine Produkt-Roadmap und eine Übersicht über den Produkt–Scope liefern muss. Und Sie wollen mit vertretbarem Aufwand alle wesentlichen Stakeholder ins Boot holen.
Da helfen nur drei Dinge weiter: inhaltliche Kompetenz der Menschen, Durchhaltevermögen und einfache, aber wirksame Methoden/Tools. Diese Tools müssen helfen, zwei Kernfragen zu beantworten:
- Welchen fachlichen Scope wird meine Digitalisierungsplattform haben?
- Wie schaffe ich es, eine nachvollziehbare Priorisierung und Reihenfolge der Umsetzungsaktivitäten zu erlangen?
Zwei Tools/Methoden, die sich in der Praxis bewährt haben, sind User-Story-Map und Feature-Liste. Beide helfen auf unterschiedliche Art und Weise, den fachlichen Gesamtüberblick zu behalten und die richtigen und wichtigen Dinge zuerst zu tun.
Zur User-Story-Map lässt sich im Internet einiges an Informationsmaterial finden zum Beispiel bei www.realtimeBoard.com:
Nun ein paar Best-Practises aus PPI-Projekterfahrungen:
- Pragmatisch zu sein und nicht starr an Inhalt und Bestandteilen (insbesondere an Rollen) festzuhalten, ist für viele erfahrene Pragmatiker ein schwer verdauliches Konstrukt.
- Ziel ist, die Breite der Anforderungen abzudecken und nicht die Detailtiefe (Insbesondere für Menschen mit Erfahrung in Wasserfall ist dieses Mind-Set eine große Herausforderung.).
Doch nun noch ein, zwei Gedanken zur Feature-Liste, einem vermutlich weniger bekannten Werkzeug. Ein Kernpunkt agiler Vorgehensweisen ist die jederzeitige absolute Transparenz über die gewählte Priorisierung. Koste es was wolle, um sie herzustellen. Und eine solche Transparenz ist ja nicht einfach herzustellen – insbesondere aus fachlicher Sicht. Kernherausforderung ist hier, den richtigen Detaillierungslevel zu betrachten. Hier hilft das Denken in Features und auch die Priorisierung auf diesem Level. Definieren Sie Feature als ein auslieferungsfähiges Bündel fachlicher Funktionalität, dann hilft es hoffentlich, den richtigen Granularitätslevel zu erkennen. Auf dieser Ebene gelingt es nach unseren Projekterfahrungen sehr wohl, auch über einen längeren Zeitraum von mehreren Jahren sehr einfach eine gemeinsame Sicht auf die Gesamtprioritäten zu erhalten. Um Ihnen ein Gefühl für die konkrete Größenordnung zu geben: Im aktuellen Projekt gilt es, ca. 80 fachliche Features über einen Zeitraum von 5 Jahren umzusetzen.
Der Methodist unter Ihnen wird sich jetzt vermutlich die Frage stellen, wie beide Tools konsistent und 100% methodisch rein zusammenpassen. Hier habe ich eine Antwort: Falsche Frage…
Wollen Sie die Frage konkreter beantwortet haben, so kontaktieren Sie uns gerne.
In der Hoffnung, Sie nicht gelangweilt, sondern Ihnen ein paar Denkanstöße geliefert zu haben, verbleibe ich nach deutlich über einem Jahr digitale DNA bei PPI mit der Empfehlung:
„Finden Sie Ihre Ansätze und entwickeln Sie die digitale DNA Ihres Unternehmens (weiter).“
Beste Grüße
Tobias Kohl
