Warum Digitalisierung mit agiler Transformation beginnen sollte
Es ist effektiver, zunächst das "Wie" eines Digitalisierungsprojekts zu betrachten – und dann erst das „Was“
Mitbewerber produzieren kostengünstiger oder haben einen Weg des Transfers des Geschäftsmodells in die digitale Welt gefunden. Technologien, die gehypt werden, aber nur zum Teil verstanden sind, drohen das notwendige Hilfsmittel für Newcomer im Marktsegment zu sein, die Markteintrittsbarriere massiv zu senken und rasend schnell Erfolge erzielen zu können. Im Extremfall hat das eigene Kernprodukt auf Dauer erkennbar keine Zukunft mehr und die Suche nach neuen Wegen der Wertschöpfung hat begonnen. So sehen beispielhaft Gründe aus, die ein Unternehmen dazu bewegen, Digitalisierungsprojekte zu starten. Schnell einigt man sich hierbei auf das „Was" – fachliches Projektziel und Rahmen. Über das „Wie" besteht eine gewisse Verunsicherung, da das Umfeld berichtet, dass heutzutage Dinge „agil" gemacht werden sollten, um flexibel auf zukünftige Marktanforderungen reagieren zu können.
Fokussierung auf das „Wie“
Also wird nachgelagert dazu eine agile Transformation ausgerufen, die nach der eigenen Wunschvorstellung das Digitalisierungsprojekt befeuert und zum Erfolg desselben beiträgt. Der Minimalkonsens ist hierbei, dass die Entwicklungsteams mit Serum arbeiten sollen ... Ich bin der Überzeugung, dass diese Herangehensweise – insbesondere die Reihenfolge – das Risiko des Scheiterns der Digitalisierungsinitiative erheblich erhöht. Das Wissen darum, ,,wie" ich Digitalisierungsprojekte durchführe, ist gerade in der Anfangsphase maßgeblicher als „was" ich umsetze. Der Fokus auf das „Wie" schafft die Voraussetzung einer nachhaltigen Organisationsentwicklung und bewahrt das Unternehmen vor (wenigstens finanziellen) Schaden.
Agile Softwareentwicklung rettet kein falsch definiertes „Was". Der klassischen Denkweise folgend, investieren Unternehmen typischerweise viel Zeit und Geld in die Definition des „Was" des Digitalisierungsprojektes. Fachliche und technische Architekturen, Projektpläne und Aufwandsschätzungen für Budgetanträge werden erarbeitet. Am Ende steht mehr oder weniger der Umriss eines fachlichen Ergebnisartefakts und vielleicht einer neuen Prozesslandschaft (mit Einsparungen ... ). Budgets sind geschnürt – im schlimmsten Fall bereits für Jahre – und Verantwortliche benannt. Schicksale im Unternehmen sind an den Erfolg der Initiative gebunden.
„Viel hilft viel“ – direkt in die Skalierungsfalle
Dann wird die agile Entwicklungsorganisation aufgesetzt. Der fachliche Weg ist bereitet, der interne Druck hoch. Gerne begibt man sich nach dem Motto „Viel hilft viel" direkt in die agile Skalierungsfalle, obwohl eigentlich noch gar kein agiles Denken in den einzelnen Teams verankert ist. Der Agilitätsfokus liegt so auf den Teams. Die Product-Owner-Rolle ist im Hinblick auf echten Kundenkontakt gestutzt und dient eher als Proxy zur technischen Übersetzung dessen, was sich ein noch weitestgehend klassisch denkendes Produkt-/Portfoliomanagement ausgedacht hat.
In einem solchen Umfeld kann sich der wahre Nutzen agilen Arbeitens nicht entfalten. Denn der selbstlernende Zyklus beschränkt sich in den Teams auf das „Wie" der Softwareentwicklung, nicht auf das „Was", das letztlich das Unternehmen erfolgreich machen soll. Demzufolge sind auch maßgebliche strategische Korrekturen ausgeschlossen: Methodisch werden sie nicht gestützt, und die schiere Größe des aus dem Boden gestampften Apparats entwickelt unmittelbar Trägheitskräfte.
Agilität liefert auch Antworten in der Erarbeitung des „Was"
Viel zielführender ist es, bevor ich über das „Was" beginne nachzudenken, das „Wie" in Augenschein zu nehmen – und zwar auf Basis von Methoden, die auf dem agilen Mindset aufbauen. Agile Methoden in der Softwareentwicklung einzusetzen, ist nur die halbe Miete.
Ein Kernaspekt agilen Mindsets ist die Kundenorientierung – und genau die brauche ich, wenn ich über das „Was" valide reden können will. Dieser Erkenntnis folgend hat sich ein ganzes Ökosystem von Innovations- und Produktentwicklungsansätzen basierend auf dem agilen Mindset entwickelt, die kleinschrittig, selbstreflektierend und vor allen im Austausch mit den echten Kunden den tatsächlichen Bedarf schärfen und die Digitalisierungsideen plausibilisieren.
Solche agilen Designvorgehen sind nahtlos mit der agilen Softwareentwicklung verbunden. Preto-Typing, Proto-Typing, Proof of Concepts und Minimum Viable Products liefern auf unterschiedlichen Investitionsebenen immer wieder neue Erkenntnisse zum tatsächlichen Bedarf und zur notwendigen Ausrichtung des Produkts. Es wird klein begonnen, validiert, plausibilisiert, experimentiert, erfolgreiche Ansätze weiterverfolgt und fehlgeleitete verworfen. Das volle Potenzial agilen Denkens wird ausgeschöpft, das wohlbekannte Prinzip des agilen Manifests „Responding to change over following a plan" ganzheitlich gelebt (und nicht nur bezogen auf die technische Komponente der Softwareentwicklung).
Budgets kann ich trotzdem definieren. Ich beginne mit kleinen Tranchen, die je nach Reifegrad des Entwicklungsschritts immer größer werden. Nach jeder fachlichen Iteration validiere ich aufs Neue die Potenziale. Grundlegend ist die Bereitschaft, so früh als möglich Handlungsstränge fallen zu lassen (und damit dies bisher getätigten Investitionen tatsächlich abzuschreiben) als auf einem wenig erfolgversprechenden Pfad zu bleiben. Auf diese Art und Weise sichere ich die Investition nachhaltig ab. Mit dem „Wie" beginnen bedeutet m1it der agilen Transformation zu beginnen
Eine geeignete Fehlerkultur ist unerlässlich
Will ich tatsächlich in der dargestellten Weise das Digitalisierungsvorhaben starten, muss ich bereits agiles Denken in der Organisation verankert haben. Benötigt wird eine geeignete Fehlerkultur (im Sinne von Fehlerbereitschaft, siehe auch Beitrag auf LinkedIn), Experimentierfreudigkeit, ein selbstorganisiertes, Kreativität förderndes Arbeitsumfeld und letztlich Methodenkenntnis in moderner Produktentwicklung. Das kommt nicht von ungefähr. Es ist das Ergebnis einer agilen Transformation – und sei es nur in einer lokal beschränkten Zelle. Habe ich diese aufgebaut, ist auch die Grundlage für eine langsam skalierende, zunehmend agile Entwicklungsorganisation gelegt. Gleichzeitig vermeide ich methodische Brüche, die potenziell durch klassische Marktangangs- und Produktentwicklungsstrategien in Wechselwirkung mit einer agilen Entwicklung entstehen.
Auch wenn diese – womöglich lokale – Transformation Zeit und Geld kostet, so bin ich der festen Überzeugung, dass eine solche Herangehensweise sich unmittelbar lohnt. Das am Ende entstehende Produkt wird in besserer Weise die Kundenbedürfnisse widerspiegeln. Und der Zeitpunkt des Markteintritts – trotz des vermeintlichen Zeitverlusts durch die Transformation – früher sein!
