Herzlich willkommen zu unserer heutigen Folge der Expertengespräche zum Thema Digitalisierung.  Wir haben uns in den letzten Folgen mit den Themen Wachstum und Agilität beschäftigt. Beide Themen sind wichtig für die Entwicklung von digitalen Produkten.

Heute wollen wir einen etwas intensiveren Blick auf die Entwicklung von Produkten werfen. Insbesondere darauf, dass diese Entwicklung ins Stocken geraten kann. Warum das passiert und wie man es dann wieder ins Laufen bekommt, wird unser heutiges Thema sein sowie die Frage: Kann Agilität dabei helfen?

Dazu sprechen wir, wie schon gewohnt, mit unserem Experten Martin Meister

Martin, Du hast in zahlreichen Kontexten und unterschiedlichen Situation digitale Produkte entwickelt. Häufiger bist du auch in Situationen geraten, in denen es nicht mehr so rund lief.

Weil das Thema nicht so einfach zu behandeln ist, werden einige Charts gezeigt, die Sie sich gerne downloaden können.

Die Entwicklung von digitalen Produkten ist vergleichsweise komplex und es braucht eine Menge Voraussetzungen, damit sie funktioniert.

Zunächst will ich möglichst einfach erklären, wie die Entwicklung von digitalen Produkten generell funktioniert. Dann werden wir auch schnell erkennen, was dabei schiefgehen kann.

Als erstes werfen wir einen Blick auf ein einzelnes Team. Auch hier gilt wieder: Es gibt viele Varianten, aber in der Regel wird so ein Team einen Product-Manager oder Product-Owner haben, mehrere Entwickler, Fachleute für UX und UI, einen Scrum-Master, vielleicht Leute für BI und ggf. weitere Teammitglieder. Wie sich das genau zusammengesetzt, hängt auch von der Ausbildung und den Qualifikationen der Team-Mitglieder ab.

In der Regel haben Unternehmen nicht nur ein derartiges Team, sondern mehrere, die auf einem oder mehreren Produkten arbeiten. Damit die Teams wissen, was zu tun ist, hat jedes Team einen Auftrag.

Ein Team muss irgendwie wissen, was es zu tun hat, sonst ist es orientierungslos und Orientierungslosigkeit ist nicht Agilität. Wir erinnern und an das Beispiel mit dem Piloten, der seinen Jet auf einem Flugzeugträger landen will.

Der Auftrag

Man kann sehr unterschiedliche Formen wählen, dies zu transportieren. Deswegen spreche ich hier ganz allgemein von einem Auftrag.

So ein Auftrag kann je nach Situation langfristige und kurzfristige Aspekte enthalten. Je nach Reifegrad der Organisation kann der Auftrag als Lieferung von Features oder als Erreichung von Zielen formuliert sein.

Bei mehreren Teams sorgt die Leitung des Produktmanagements oder eine andere Instanz dafür, dass sich die Aufträge nicht widersprechen und dass sie einen Zusammenhang zu Vision und Strategie haben.

Über diesen letzten Satz kann man im Detail noch lange sprechen. Ich möchte aber etwas anderes in den Mittelpunkt stellen, weil ich glaube, dass man so am besten Ordnung schafft.

Zentrales Element der Produktentwicklung mit einem oder mehreren Entwicklungsteams ist der Auftrag. Weil dieser Auftrag die Handlungen des Entwicklungsteams steuert.

Die Ausgestaltung des Auftrags hängt von vielen Dingen ab und kann sehr unterschiedlich sein.

Ein Auftrag muss mehrere Anforderungen erfüllen.

Er muss:

• sinnvoll,
• durchführbar,
• ambitioniert und
• motivierend sein.

Nehmen wir noch einmal den Piloten, der seinen Kampfjet landen soll.

Sinnvoll ist der Auftrag, wenn man davon ausgeht, dass er in einem größeren Kontext zur Sicherung der Verteidigungsfähigkeit steht und Training wichtig ist.

Durchführbar ist er, wenn die Rahmenbedingungen stimmen und der Pilot über die notwendige Ausbildung verfügt.

Dass dieser Auftrag ambitioniert ist, muss man nicht erklären.

Und motivierend ist er, weil er sinnvoll und ambitioniert ist und gleichzeitig die Entwicklung des Piloten fördert, der auch eine Gelegenheit erhält zu zeigen, was er kann.

Jetzt schauen wir uns das mal in Bezug auf den Auftrag für ein Entwicklungsteam an.

Sinnvoll ist ein Auftrag, wenn er einen Beitrag zur Strategie leistet und/oder auf die Unternehmensziele einzahlt. Das Oder kommt daher, dass nicht alle Unternehmen sofort eine ausgefeilte Strategie haben, aber trotzdem die Notwendigkeit sehen, das Produkt weiterzuentwickeln.

Und damit ein Auftrag sinnvoll ist, müssen Ziele, Ressourcen und Restriktionen konsistent und widerspruchsfrei sein.

Durchführbar ist ein Auftrag, wenn ein Team die notwendigen Kompetenzen hat und über die notwendige Ausbildung verfügt oder sich die Ressourcen beschaffen kann.

Und: wenn ein Team bei der Umsetzung nicht von anderen Teams abhängig ist.

Ein Auftrag sollte aber nicht nur sinnvoll und umsetzbar sein, sondern wenn wirklich gute Produkte entstehen sollen, ist er auch ambitioniert und motivierend.

Ambitioniert ist er, wenn er einen echten Fortschritt für das Unternehmen bringt, die Beteiligten fordert aber nicht überfordert.

Motivierend ist er, wenn er als Beitrag zu den Unternehmenszielen verstanden und geteilt wird und wenn die Teammitglieder Gelegenheit haben, zu zeigen, was sie können und der Erfolg das Ergebnis guter Zusammenarbeit ist.

Ein Auftrag sollte mindestens die Aspekte zeitliche Dimension, Ziele, Lieferleistungen, Rahmenbedingungen, Ressourcen und Abgrenzung enthalten. Hier gibt es zahlreiche Anleitungen, wie ein solcher Auftrag aussehen kann.

Er sollte dialogisch zustande kommen und nicht einfach hierarchisch diktiert sein. Dabei unterstelle ich immer, dass Teams etwas leisten und stolz auf ihre Arbeit sein wollen. Es ist nicht zielführend aus der Angst zu agieren, dass sie alle gar nicht arbeiten wollen.

Der Dialog muss vor allem sicherstellen, dass Ziele, Restriktionen und Ressourcen im Einklang stehen. Das klingt zunächst einmal sehr einfach, ist es aber in der Praxis nicht.

Jedes dieser Elemente stellt eine Quelle von Störungen dar. Ohne Anspruch auf Vollständigkeit hier ein paar Beispiele:

Häufig findet Ausbildung nicht mehr statt, weil es das Missverständnis gibt, dass alles Eingreifen von Vorgesetzten in Abläufe Micro-Management sei. Das führt dann zu der Situation, dass Teams sich selbst überlassen werden und verwahrlosen. Es ist die Aufgabe von Führung permanent zu prüfen, ob Anforderungen existieren, die so durch die Qualifikation der Mitarbeiter nicht abgedeckt sind und dann für Abhilfe zu sorgen.

Abhängigkeiten sind ein großes Thema, weil es häufig aufgrund unzureichender Architektur dazu kommt, dass Teams bei der Erreichung ihrer Ziele davon abhängig sind, dass andere Teams technische Voraussetzungen dafür schaffen. Diese Abhängigkeiten können gegenseitig oder zirkulär sein.

Es zeigt sich immer wieder, dass es nicht so einfach ist:

• eine konsistente Strategie zu formulieren und die Aufträge in Zusammenhang mit dieser Strategie zu formen,
• das passende Team zusammenzustellen,
• alle wichtigen Aspekte im Auftrag zu berücksichtigen,
• daran zu denken, den Auftrag im Vorfeld mit den Teammitgliedern zu besprechen, um deren Meinung zu hören etc.

Was macht man nun, wenn man feststellt, dass der Entwicklungsprozess nicht mehr funktioniert?

Zunächst mal muss man sicherstellen, dass Aufträge sinnvoll und umsetzbar sind. Wenn das nicht gegeben ist, wird der Entwicklungsprozess überhaupt keine Ergebnisse mehr liefern.

Wenn wenigstens die beiden Anforderungen gegeben sind, liefert der Entwicklungsprozess zwar keine optimalen Ergebnisse, aber zumindest Ergebnisse.

Da die Entwicklung der Strategie und daraus resultierende Aufträge in aller Regel nur über einen längeren Prozess zu bewältigen sind, stellen Ambition und Motivation wichtige Kriterien für die erfolgreiche Umsetzung der Aufträge dar.

Die Bedeutung der Architektur

Schwierig wird es, wenn die Teams auf einer fachlichen und technischen Architektur arbeiten, die immer wieder dazu führt, dass sich die Teams in Abhängigkeiten verstricken. Dies ist häufig nur durch einen fast immer langwierigen Umbau der Architektur zu beheben.

Diesen Umbau scheuen viele Unternehmen, aber letztendlich stehen sie damit vor der Frage, ob sie dauerhaft eine hochgradig ineffektive Produktentwicklung akzeptieren wollen, die eher schlechter wird oder ob und wann sie den Schritt gehen, ihre Architektur umfassend umzubauen.

Gerade im Private Equity-Bereich, wo Unternehmen häufiger einmal den Besitzer wechseln, findet man das Phänomen, dass keiner diesen Schritt gehen will. Bis irgendwann einer den „schwarzen Peter“ behält und das Unternehmen in wirtschaftliche Schwierigkeiten gerät, weil es z.B. von Wettbewerbern abgehängt wird.

Je kompetenter Unternehmen in die Due Diligence einsteigen und auch eine Architektur beurteilen lassen, desto schwieriger wird die Entscheidung für das weitere Vorgehen und am Ende ist das auch gut so.

Ich habe ja ein paar Mal gesagt, dass Digitalisierung zu technisch gesehen wird. Hier muss man aber sagen, dass Architektur und Architekturmanagement natürlich ganz entscheidend dafür sind, langfristig erfolgreich zu sein.

Mit guter Architektur allein ist man noch nicht erfolgreich. Dazu braucht es eine gute Strategie.

Die wiederum kann man aber nur umsetzen, wenn die fachliche und technische Architektur des eigenen Produktes darauf vorbereitet ist.

Kurze Zusammenfassung:

• Teams brauchen einen sinnvollen, umsetzbaren, ambitionierten und motivierenden Auftrag.
• Um das herzustellen, braucht es eine Menge Voraussetzungen.
• Darüber hinaus haben wir festgestellt, wie entscheidend Architektur ist, um eine Strategie umzusetzen.

Darüber werden wir in unseren weiteren Folgen sprechen.

In unserer nächsten Folge widmen wir uns erst einmal einem anderen Thema. Die Digitalisierung stellt hohe Anforderungen an diejenigen im Unternehmen, die diese vorantreiben sollen.

Deswegen werden wir in der nächsten Folge darüber sprechen, inwieweit Interim Management dabei helfen kann, diese Herausforderungen zu bewältigen und warum das in einigen Situationen sogar der beste Weg ist.