3. AGILE VALUE CREATION LEADERSHIP

Die Herausforderungen aus dem Kapitel 2 beschreiben den Eisberg unter der Wasseroberfläche. Um diese Aufgaben bewältigen zu können, brauchen Sie einen unternehmensweiten Change. Die Auseinandersetzung mit den Kernfragen ist entscheidend:

• Wie sieht eine agile Aufbau-Organisation in der agilen Welt aus und wie lässt sie sich steuern?

• Wie kann die Zusammenarbeit der neuen Rollen mit der Linienorganisation gestaltet werden?

• Welche Rolle spielen noch die bestehenden Prozesse - und insbesondere das Portfoliomanagement?

Welche neuen Prozesse werden benötigt - und welche alten nicht mehr?

• Welche Kennzahlen passen in die agile Welt?

• Welches Bonifikationssystem macht Sinn? Usw.

Mit diesen ersten Kernfragen beginnt der eigentliche und vielmals schwierigere Change in Ihrem Unternehmen. Das „Agile Value Creation Leadership“ liefert vier Ansatzpunkte, wie diese Herausforderungen angegangen werden können:

• Unternehmensweites Product Backlog

- als zentrales Steuerungsinstrument im Unternehmen, über alle Hierarchie-Ebenen hinweg.

• Agile Aufbauorganisation

- wie kann eine solche Organisation aussehen, um nicht nur Kompetenzgerangel zu verhindern, sondern die neu entstandenen Rollen in der agilen Welt optimal zu unterstützen?

• Value Creation als Prozess

- wie können schlanke Prozesse die Value-Maximierung unterstützen?

So ganz ohne Prozesse geht es nicht. Wie können diese so gestaltet werden, dass sie als Hilfe und als Beschleuniger verstanden und gerne genutzt werden?

• One KPI Leadership

- wir werden sehen, dass operativ genau eine Kennzahl ausreicht, um den nachhaltigen Erfolg im Bereich der Entwicklung zu messen.

A. UNTERNEHMENSWEITES
PRODUCT BACKLOG

Die erste Disziplin beim „Agile Value Creation Leadership“ ist der Aufbau eines unternehmensweiten Product Backlogs mit allen existierenden Entwicklungsthemen.

Mit Sicherheit ist es keine einfache Aufgabe. Ganz im Gegenteil - die meisten Unternehmen werden sich dabei schwertun und mehrere Monate benötigen, um ein arbeitsfähiges, unternehmensweites Product Backlog zu erarbeiten. Es ist eine Frage von Erfahrung, die User Storys in der benötigten Granularität zu konzipieren. Die ersten Versuche werden mit Sicherheit nicht das gewünschte Ergebnis liefern. Über den Lernprozess werden die User Storys mit der Zeit an Qualität gewinnen.

Die Abbildung „Product Backlog“ zeigt einen typischen High-Level Aufbau eines Product Backlogs. Das Business Epic stellt dabei die höchste Ebene dar. Es steht für ein Thema, dessen Mächtigkeit von dem jeweiligen Themenzuschnitt abhängt. Ein Product Backlog hat typischerweise mehrere solcher Business Epics. Ein Business Epic als Thema besteht wiederum aus mehreren Epics, welche als eine Art Funktionalität oder Teil-Thema zu verstehen sind.

Jedes Epic hat diverse User Storys15, welche aus Kundenperspektive aufgebaut sind. Hier wird im Sinne der Customer Journey mit einfachen Worten der Anwendungsfall beschrieben. Zu einer User Story gehören neben den konkreten Aufgaben (=ToDos) auch die Abnahmekriterien für die Entwicklung.

Es folgt ein Beispiel aus der Versicherungswelt. Nahezu alle Versicherungsunternehmen bieten ihren Endkunden Web-Portale mit einem persönlichen Login an. Hier werden digitale Services angeboten, wie z.B. die Vertragsübersicht, der Schriftverkehr oder diverse Kommunikationsmöglichkeiten.

Die Vertragsservices wären in diesem Beispiel das Business Epic. Die Vertragsübersicht im Sinne einer Funktionalität könnte als Epic definiert werden. Unter dem Epic „Vertragsübersicht“ könnten mehrere User Storys untergeordnet werden.

1. User Story KfZ-Versicherungsverträge

   „Als Endkunde möchte ich im persönlichen Bereich meine KfZ-Versicherungsverträge einsehen, um die wesentlichen Informationen zum KfZ-Vertrag auf einen Blick zu haben“. Aus technischer und fachlicher Sicht ergeben sich mehrere Fragestellungen. Welches System liefert die Daten und wie aktuell müssen diese sein? Welchen Detailgrad sollten die notwendigen Vertragsdaten haben? Wie sieht die technische Schnittstelle aus? Sollten dem Kunden auch seine historischen und mittlerweile u.U. ungültigen KfZ-Verträge angezeigt werden?

2. User Story Vertrags-Dashboard

   „Als Endkunde möchte ich in einem Dashboard alle meine Versicherungsverträge sehen können, um einen transparenten Überblick von allen bestehenden Verträgen zu haben“. Auch hier stellen sich zahlreiche Fragestellungen, welche bei der Ausarbeitung der ToDos und der Abnahmekriterien zu beantworten sind. Wie soll das Design dieses Dashboards sein? Worauf wird der Fokus gelegt? Wie können Cross- und Up-Selling Potenziale optimal berücksichtigt werden? Welche digitalen Self-Services sollen an den jeweiligen Verträgen angeboten werden?

ENTERPRISE EPIC EBENE

Einen Product Backlog mit allen vorhandenen Entwicklungsthemen des Unternehmens aufzubauen kann zu weiteren Herausforderungen führen. Die Ebene Business Epic könnte zu mächtig bzgl. der Anzahl von Einträgen sein. Das operative Management des Product Backlogs wäre deutlich erschwert. Zudem könnte für die Kommunikation und die Kollaboration mit dem Vorstand die Business Epic Ebene zu feingranular sein. Es macht durchaus Sinn, sich noch eine weitere Ebene aufzubauen: Wir definieren eine weitere Ebene im Product Backlog - die Ebene der Enterprise Epics.

• Beispiel für die Enterprise Epic Ebene

Im letzten Beispiel könnte das Web-Portal das Enterprise Epic darstellen. Auch vorstellbar wäre eine noch stärkere Bündelung, so dass die „Digitalen Kundenschnittstellen“ ein Enterprise Epic bilden könnten. Business Epics wären u.U. die Konzern-Webseite, Social Media, Webportal (dann als Business Epic), Apps, …

Wichtig ist, dass das unternehmensweite Product Backlog als das zentrale Steuerungselement verstanden wird. Alle Entwicklungsvorhaben sind im Product Backlog zu integrieren - unabhängig davon, ob es sich um strategische Vorhaben handelt, oder nicht. Es mag an dieser Stelle die Frage aufkommen, wie denn mit strategischen und geheimen Business Epics oder gar Enterprise Epics umgegangen werden soll. Eine notwendige Geheimhaltung kann mit einem entsprechenden Legitimationskonzept auf das Product Backlog realisiert werden. Andererseits wäre es auch eine Überlegung, sich mit der Frage zu beschäftigen, inwiefern nicht die Transparenz am Ende wichtiger ist und die Enterprise Epics bzw. Business Epics von Anfang an offen kommuniziert werden.

Schließlich sind in der heutigen Zeit die Abhängigkeiten zu hoch, als dass ein Geheimprodukt vollständig abgeschirmt entwickelt werden kann. Je früher die Verantwortlichen das klare Gesamtbild kennen, umso effizienter gelingt die Zusammenarbeit in Bezug auf das Management der Abhängigkeiten.

DIE RICHTIGE STRUKTUR IM PRODUCT BACKLOG

Das Ziel eines werthaltigen Product Backlogs ist eine intelligente Strukturierung, welche ein effizientes Abarbeiten ermöglicht. Dabei sollten insbesondere die folgenden drei Aspekte mit hoher Sorgfalt berücksichtigt werden:

1. Pro Epic ein Team

   Im Optimalfall kann jedes Epic von genau einem Team entwickelt werden. Effizient wäre es auch die Wartung der entwickelten Software (oder des Epics bzw. Business Epics) im selben Team zu allokieren. Das bedeutet, dass die Systemverantwortung für ein Epic von genau einem Team übernommen werden sollte. Damit werden teure Übergabeprozesse und interne Abstimmungen zwischen den Teams vermieden.

2. Maximale Unabhängigkeit

   Jede Abhängigkeit im Product Backlog sollte aktiv gemanagt werden. Es wird bei gewissen Vorhaben nicht immer möglich sein, jedes Epic oder jede User Story ohne Abhängigkeiten zu Umsystemen zu strukturieren. Dennoch: Die Minimierung ist dabei eine wichtige Vorgabe - je weniger Abhängigkeiten zwischen Business Epics bzw. Epics existieren, umso effizienter wird die Entwicklung sein.

3. Intelligente Themen-Größen

   Schneiden Sie ein Thema so in Business Epics, dass ein Business Epic innerhalb von maximal...