» Bedeutung von Agilität und Kundenzentrierung «

Nachdem wir in der letzten Folge kurz in das Thema Strategie eingestiegen sind, wollen wir uns in dieser Folge mit einem ganz heißen Eisen befassen, nämlich dem Thema Agilität.

Martin hat versprochen, dass er ganz am Ende dieses Gesprächs einen Zusammenhang herstellt zwischen Strategie, so wie wir sie in der letzten Folge besprochen haben und Agilen Methoden

Agilität ist auch so ein Begriff, der stark polarisiert. Einige meinen, Agilität funktioniere überhaupt nicht, Agilität sei tot ist sogar manchmal zu hören. Andere glauben nach wie vor, dass Agilität die einzig selig machende Methode sei. Wo stehst Du in diesem Glaubenskrieg?

Aus Glaubenskriegen versuche ich mich rauszuhalten. Mein Handeln ist auf Effektivität ausgerichtet und da sind Glaubenskriege nicht hilfreich.

Leider ist es bei solchen Themen immer so, dass durch Fehlinterpretationen und Missverständnisse irgendwann Dinge und Phänomene Agilität genannt werden, die damit gar nichts zu tun haben.

Bei Agilität hält sich bereits über lange Zeit das Missverständnis, der Kern von Agilität sei Unverbindlichkeit. Es gibt keine Ziele, keine Termine und ähnliches. Wer das einfordert, sei Wasserfall und ganz „Old School“.

Das siehst Du aber nicht so?

Es lohnt sich wie bei anderen Themen auch, mal in die Ursprünge des Themas zu schauen.

Du meinst das agile Manifest.

Sich damit auseinanderzusetzen ist sicher sinnvoll. Allerdings ist es sehr geprägt durch seinen Ursprung in der Softwareentwicklung.

Deswegen benutze ich zur Herleitung gerne Beispiele für Agilität, die nicht aus der Softwareentwicklung stammen.

Jeff Sutherland (Der Erfinder von Scrum) erläutert Agilität am Beispiel eines Düsen-Jets, der auf einem Flugzeugträger landen soll und bei dem der Pilot während des Landeanflugs ständig überprüft, ob er auf dem richtigen Weg ist und dementsprechend handelt sowie, gemäß seinen Kenntnissen, etwas anpasst oder nicht.

Vielleicht hat es damit zu tun, dass viele Autoren Amerikaner sind, aber viele Beispiele stammen aus dem Bereich Fliegerei und Militär.

Ist das gut oder schlecht?

Na ja, auf der einen Seite sind diese Beispiele dann etwas martialisch, aber der Vorteil dieser Beispiele ist, dass alle verstehen, dass ein Scheitern massive Konsequenzen hat.

Und wo entsteht dann die Agilität?

In unserem Beispiel ist das Ziel sehr klar, das Ergebnis ist klar und die Restriktionen und Rahmenbedingungen sind klar. Und diese können auch nicht verändert werden.

Der Pilot kennt die Position des Flugzeugträgers, die Länge der Landebahn etc. und er weiß, dass seine Auftraggeber das nicht einfach verändern werden.

Er kann nun nicht sagen, dass er heute mal ein bisschen weiter hinten landet oder heute gar nicht, weil er dann entweder im Wasser landet oder sein Sprit ausgeht und schlimmeres passiert.

Der Pilot trifft auf dabei ständig eigenständige Entscheidung auf Basis von Daten und auf Grundlage seiner Ausbildung und Erfahrung.

Also wir sehen hier keine Unverbindlichkeit, sondern sehr klare Ziele und am Ende will der Pilot mit stolz geschwellter Brust aus dem Cockpit steigen, weil er es einmal wieder geschafft hat.

Und wie überträgt man das jetzt auf die Digitalisierung?

Zunächst mal lässt sich das auf die Software-Entwicklung übertragen. Ein Team soll bis zu einem bestimmten Termin einen bestimmten Funktionsumfang liefern oder einen Prozess bis zu einem bestimmten Teil digitalisiert haben.

Der Auftrag unseres Piloten war ambitioniert, aber umsetzbar und er verfügte über die notwendigen Ressourcen, Kenntnisse und Fähigkeiten, ihn auszuführen. Der Auftrag war ausführbar.

Das gleiche gilt auch für den Auftrag an ein Team, das Software entwickeln soll. Ein idealer Auftrag ist sinnvoll, umsetzbar, ambitioniert und motivierend.

Wir können uns an anderer Stelle noch damit befassen, wie das zustande kommt. Wichtig ist hier erst einmal das Thema „umsetzbar“.

Das geht nur, wenn das Team über die notwendigen Skills und die notwendige Ausbildung verfügt. Wenn das nicht der Fall ist, hilft die Agilität auch nicht. Um das etwas überspitzen: Wenn du oder ich versuchen würden, den Jet zu landen, würde uns Agilität vermutlich auch nicht retten.

Ok. Im Kern geht es also um den Auftrag und darum, dass ein Team in der Lage ist, diesen grundsätzlich zu erfüllen und dann sein Verhalten immer wieder darauf überprüft, ob das Ziel erreicht wird und dann das Verhalten entsprechend anpasst.

Genau. Das Verhalten wird angepasst, nicht das Ziel. Der Flugzeugträger wird sich nicht auf den Jet einstellen.

Es kann immer einmal dazu kommen, dass der Pilot abdrehen muss und einen neuen Anlauf nimmt. Genauso kann ein Team feststellen, dass sich der Rahmen verändert hat, Ressourcen nicht zur Verfügung stehen oder ähnliches. Das muss aber die Ausnahme bleiben, sonst stimmt etwas nicht an den Aufträgen, den Skills, den Ressource usw.

Und dann muss man sich das genau anschauen.

Und wenn die Ziele nicht sinnvoll sind, wenn die Ausbildung fehlt und man auch sonst alles falsch macht, was nur falsch zu machen ist, wird die Agilität es auch nicht retten.

Also Agilität ist notwendig. Das richtige Verständnis von Agilität ist notwendig. Aber Agilität allein rettet nichts.

So würde ich es beschreiben

So und jetzt hast Du versprochen, dass Du noch einen Zusammenhang zwischen der letzten Folge und Agilität herstellst.

Gerne, aber vorher möchte ich noch etwas anderes sagen.

Mir ist wichtig, an dieser Stelle über das Thema „Stolz“ zu sprechen und ich meine damit nicht Eitelkeit oder Größenwahn, sondern Stolz. Der Pilot will stolz aus seinem Flieger steigen. Die Teams wollen stolz auf ihre Leistung sein und Unverbindlichkeit, wie laufend Termine zu verschieben, macht nicht stolz und macht auch nicht zufrieden. Deswegen sind Ziele und Verbindlichkeit wichtige Bestandteile der Zusammenarbeit, damit Teams ihre Motivation nicht verlieren.

Jetzt aber zum Zusammenhang von Strategie und Agilität

In der letzten Folge haben wir über Strategie gesprochen, und darüber, dass ein wesentlicher Teil dieser Strategie sich aus Kundenzentrierung speist.

Man muss noch dazu sagen, dass wir in dieser Folge die Beispiele auf Software-Entwicklung bezogen haben, es aber in der Digitalisierung um die Entwicklung von Produkten geht.

Einer der wesentlichen Unterschiede besteht darin, dass Produktentwicklung auf den Kunden bezogenen Mehrwerte liefert und im Kern nicht die Auslieferung von Features steht. Man spricht von Outcome statt Output.

Wesentliche Elemente der Kundenzentrierung sind:

  • Definition der Zielgruppe
  • Bedürfnisse und die Ableitung der daraus zu erzielenden Mehrwerte sowie
  • das Aufsetzen eines Dialogs und streng datengetriebenen Arbeiten.

So und jetzt ist auch schon klar, warum hier agiles Vorgehen so wichtig ist.

Man spricht mit dem Kunden, um rauszufinden, was seine Bedürfnisse sind, und daraus leitet man ab, welches Produkt man ihm anbietet.

Dann baut man möglichst kleine Produkte oder Erweiterungen, bietet sie dem Kunden an, schaut wie er reagiert, und baut die nächste Version in kleinen Schritten, ohne dabei das übergreifende Ziel aus den Augen zu verlieren.

Agiles Vorgehen ist also ein notwendiger Bestandteil von Kundenzentrierung.

Wenn man die beiden Folgen in 3 Sätzen zusammenfassen wollte, könnte man das so versuchen.

Agilität ist kein Selbstzweck.

Kundenzentriertes Vorgehen ist die Voraussetzung für erfolgreiche digitale Produktentwicklung und damit für Wachstum durch Digitalisierung.

Agiles Vorgehen ist ein notwendiger Bestandteil von Kundenzentrierung.

Das kann man dann schon so stehen lassen. Jetzt wissen wir, was die fundamentalen Voraussetzungen sind, für eine erfolgreiche Entwicklung von digitalen Produkten sind.

In der nächsten Folge beschäftigen wir uns damit, warum die Produktentwicklung so häufig ins Stocken kommt.

Ihre Ansprechpartnerin

Christiane Fuhrmann
Head of Marketing I Business Development