Skip to main content

Risikoarme Innovation: Business-Case für Scrum und warum Manager eine zentrale Rolle in der agilen Transformation spielen

October 3, 2024

Viele Manager befinden sich in einer Zwickmühle:

  • Zum einen wissen sie, dass Veränderung sehr risikoreich ist. Veränderungsvorhaben können Widerstand bei Mitarbeitern hervorrufen, wenn neue Prozesse für Verunsicherung sorgen, da sie etablierte Arbeitsweisen infrage stellen. Veränderungsprojekte kosten viel Geld. Nicht selten müssen Mitarbeiter geschult oder neue Technologien gekauft werden. Fehlgeschlagene „Change-Initiativen“ gefährden ihr Ansehen und ziehen ihre Kompetenz in Zweifel.
  • Zum anderen wissen Manager auch, dass Innovation der Schlüssel zum Erfolg ist. Im Buch „Agile Project Management“ beschreibt es Jim Highsmith treffend: „Innovation bietet in der Regel den höchsten Grad an Wertschöpfung in einem Unternehmen.“ Für Unternehmen, die primär „Wissensarbeit“ durchführen, ist diese noch wichtiger. Ihr „Wissen“ ist viel vergänglicher als physische Produkte. Ihre Fähigkeit, innovativ zu sein, stellt den Grad ihrer Überlebensfähigkeit am Markt dar.

Die Frage, die wir uns also stellen müssen:

Wie können Unternehmen risikoarm innovativ sein?

Die Frage ist allerdings paradox.

Innovation ist hochgradig risikobehaftet. Innovation kann weder geplant werden, noch stehen die Erfolgschancen dabei sehr gut. Denke nur daran, wie viele Start-ups letztlich überleben. Gleichzeitig besteht die Aufgabe für jeden Manager darin, das Risiko, dem das Unternehmen ausgesetzt ist, zu minimieren. Dies gilt für jede Management-Position gleichermaßen. Disziplinarische Führungskräfte versuchen, mit der Einstellung der richtigen Talente das unternehmerische Risiko zu senken. Das mittlere Management tut dies durch die Auswahl der richtigen Projekte. Das Top-Management durch strategische Ausrichtung und langfristige Partnerschaften.

Die Antwort auf die Zwickmühle, risikoarm innovativ zu sein, liegt in der Geschwindigkeit.

Genauer gesagt in der Antwort auf die Frage:

Wie schnell kann ein Unternehmen lernen?

Der Erste mit dieser Einsicht war wohl Chris Argyris. Er war renommierter Professor in Yale und gilt als der Vater des organisatorischen Lernens. Bekannt ist er durch dieses Zitat:

„Der Erfolg auf dem Markt hängt zunehmend vom Lernen ab, aber die meisten Menschen wissen nicht, wie sie lernen sollen.“

Was für Menschen gilt, gilt auch für Teams und somit zwangsläufig für das Unternehmen.

Ein Unternehmen, das dies frühzeitig für sich erkannt hat und dem seither viele nacheifern, ist Spotify. Wie Lernen auf Unternehmensebene aussieht, drückt Daniel Ek, der CEO von Spotify, schon mit diesem Zitat aus:

„Wenn du dich für die erste Version deines Produkts nicht schämst, hast du es zu spät auf den Markt gebracht.“

Risikoarm innovativ zu sein, bedeutet also nicht, die vermeintlich besten Entscheidungen zu treffen. Es bedeutet, Entscheidungen am schnellsten zu treffen. Dadurch lernen wir am schnellsten, ob die Entscheidung richtig war.

Wenn in der Geschwindigkeit, mit der Unternehmen lernen können, die Antwort auf das Dilemma liegt, wie Unternehmen risikoarm innovativ sein können, dann bleibt nur noch die Frage:

Wie können Manager risikoarme Innovation fördern?

Die Antwort ist nicht nur in Managementkreisen bereits bekannt. Sie geht auf Peter Drucker, den Gründer des „modernen Managements“, zurück:

„Was du nicht messen kannst, kannst du nicht lenken.“

Manager müssen also einen Weg finden, „Lernen“ auf Ebene des Unternehmens messbar zu machen.

In einer „Evidence-Based Management“-Schulung stelle ich hierzu die Time-to-Learn vor. Die Time-to-Learn erfasst genau die Geschwindigkeit, mit der ein Unternehmen lernt. Und damit macht sie Feedbackschleifen, die wir aus Scrum kennen, für Manager lenkbar. Sie ist das Werkzeug, um risikoarme Innovation zu steuern. Denn die Feedbackschleifen durch das Sprint-Review in Scrum verschaffen erst einmal nur Klarheit darüber. Sie zeigen, ob Teams das Richtige tun. Aber liefern die Feedbackschleifen diese Informationen auch schnell genug?

Betrachten wir die Lernschleife, die üblicherweise bei Softwareentwicklung entsteht. Sie besteht vereinfacht gesagt aus sechs Schritten:

  1. Entdecken
  2. Entwickeln
  3. Testen
  4. Liefern
  5. Benutzen
  6. Lernen

Angenommen, jeder dieser Schritte benötigt sechs Wochen. Dann würde die Lernschleife für ein Feature nach neun Monaten einmal durchlaufen sein.

Die Time-to-Learn wäre also neun Monate.

Für das Management im Unternehmen bedeutet dies: Sie wissen nach neun Monaten, ob die Entscheidung, in dieses Feature zu investieren, die richtige war.

Die neun Monate Wartezeit stellen für sich genommen bereits ein erhebliches finanzielles Risiko für das Unternehmen dar. Aber dieses Risiko übersteigt die eigentlichen Entwicklungskosten maßgeblich. Denke nur an all die Folgeentscheidungen, die auf der Annahme von vor neun Monaten getroffen wurden, dass in dieses Feature investiert werden sollte. Vielleicht wurden Marketing-Kampagnen gestartet, Kunden versucht zu gewinnen, Kundensupport aufgebaut, Fehler behoben, oder es befinden sich bereits weiterführende Features in Arbeit. Sowohl die Kosten für das Feature als auch die Anzahl der Folgeentscheidungen stehen in Relation mit der Time-to-Learn.

Die Einsicht daraus: Je kürzer die Time-to-Learn ist, desto geringer ist das Risiko für das Unternehmen.

Hier eine Liste von Vorteilen, die sich durch eine kürzere Time-to-Learn für das Unternehmen ergeben:

5 Vorteile einer kürzeren Time-to-Learn

  • Geringe Verzögerungskosten: Je länger Arbeit liegen bleibt, desto teurer wird es, an ihr weiterzuarbeiten. Verantwortlich für die Kosten ist die Zeit, die ein Mitarbeiter aufwenden muss, um sich wieder in die Arbeit einzufinden. Je komplizierter die Arbeit, desto mehr Zeit muss dafür aufgebracht werden. Verzögerungskosten sind schwer messbar. Ein erster Indikator ist das Verhältnis zwischen Durchlaufzeit und tatsächlich aufgewandter Arbeitszeit.
  • Niedrige Änderungskosten: Diese Kosten verstärken sich durch Aussagen wie diese: „Wir haben bereits so viel investiert, da machen wir besser weiter.“ Änderungskosten gehen auf die „Sunk Cost Fallacy“ zurück. Diese kognitive Verzerrung beschreibt unsere Tendenz, trotz der negativen Aussichten weiter zu investieren, weil wir die bereits investierten Mittel nicht „verschwenden“ wollen.
  • Geringere Lagerkosten: Die Rede ist von der Lagerung fertiger Produkte. Wenn ein Feature der Software fertiggestellt wurde, aber nicht ausgeliefert ist, entspricht dies der gleichen Situation. Nur mit dem Unterschied: In einer Fabrik wäre es offensichtlich, in der Softwareentwicklung fällt es häufig nicht auf. Aber in beiden Fällen ist das Geld zur Fertigstellung bereits investiert, aber kein Ertrag generiert. Somit sinkt die Liquidität des Unternehmens.
  • Weniger Kontextwechsel: Studien haben gezeigt, dass Multitasking zu mehr Fehlern führt. Die Reparatur von Fehlern und die Bearbeitung von Fehlern durch den Kundensupport sind eine weitere Quelle für Kosten.
  • Gesteigerte Mitarbeitermotivation: Studien haben gezeigt, dass neben Geld die Anerkennung für gute Arbeit der größte Faktor für zufriedene Mitarbeiter ist. Durch frühes Kundenfeedback erhalten Teams Anerkennung für ihre Leistung und dies steigert die Motivation.

Wir können also festhalten:

Eine niedrigere Time-to-Learn bedeutet eine Verbesserung auf vielen Ebenen des Unternehmens, insbesondere der wirtschaftlichen. Nutzen wir Scrum, um die Feedbackschleife mit den Kunden zu etablieren. Dadurch können wir die Time-to-Learn sichtbar machen. Somit haben wir einen Business-Case für die Verwendung von Scrum geschaffen.

Jetzt denkst du dir vielleicht, die Messung der Time-to-Learn birgt viele Vorteile. Dann muss sie bestimmt schwierig zu messen sein. Oder ich brauche spezielle Software dafür.

Wie lässt sich die Time-to-Learn messen?

Die Time-to-Learn lässt sich sehr einfach messen.

Kommen wir nochmal zurück zum Beispiel der sechs Schritte der Softwareentwicklung:

  1. Entdecken
  2. Entwickeln
  3. Testen
  4. Liefern
  5. Benutzen
  6. Lernen

Damit kannst du die Time-to-Learn berechnen. Sie stellt die Differenz zwischen Lerndatum und Entdeckungsdatum dar. Notiere bei der Erstellung eines Eintrags im Product-Backlog, was den Beginn der Entdeckungsphase markiert: das Datum. Und notiere dir auch das Datum, wann das Team zusammenkommt und die Daten über die Nutzung des Features diskutiert. Dieser Zeitpunkt stellt das Lerndatum dar. Daten über die Nutzung des Features können Usage-Index, Umfragen, Interviews, Kundensupportanfragen usw. darstellen.

Für Scrum Teams gibt es mindestens zwei Gelegenheiten, zu lernen:

  1. Im Sprint-Review können die Daten über die Nutzung des Features diskutiert werden. Dies stellt die erste Lernschleife dar. Diese Erkenntnisse bilden die Grundlage für neue Ideen und schaffen die Möglichkeit für Innovation im Produkt.
  2. In der Sprint-Retrospektive können die Erkenntnisse aus dem Sprint-Review noch einmal systematisch aufgegriffen werden. Diese Erkenntnisse könnten genutzt werden, um mehr über die Arbeitsweise des Teams zu lernen. Dieses Lernen hilft, Fehler zu verringern und den Arbeitsprozess so zu gestalten, dass sich mehr Möglichkeiten bieten, Ideen und Verbesserungen am Produkt zum Vorschein zu bringen.

Das Messen der Time-to-Learn allein wird wahrscheinlich nicht ausreichen.

Soll Innovation risikoarm gefördert werden, dann muss die Time-to-Learn verkürzt werden. Dies minimiert die finanziellen Risiken und ermöglicht häufigeres Lernen, was die Innovationsfähigkeit verbessert. Denn:

Innovation kann niemals geplant werden, aber es kann ein Umfeld geschaffen werden, in dem sie häufiger passieren kann.

Warum sollten Unternehmer, die Innovation risikoarm fördern wollen, Scrum nutzen?

Scrum basiert auf Sprints.

Sprints dienen gerade dazu, das finanzielle Risiko in der Entwicklung von Produkten auf 30 Tage oder weniger zu beschränken. Spätestens nach vier Wochen kommen die Stakeholder des Produkts und das Team zusammen. Sie diskutieren den Fortschritt in der Entwicklung. Danach entscheiden sie, wie es weitergehen soll.

Wenn wir noch mal auf das Beispiel der sechs Schritte der Softwareentwicklung zurückschauen, dann sehen wir, dass mit Scrum diese drei Schritte innerhalb von 30 Tagen passieren müssen:

  • Entwickeln
  • Testen
  • Liefern

Somit hilft uns Scrum, bereits einen Teil der Time-to-Learn zu verkürzen. Es bietet einen guten Startpunkt für Unternehmen, die risikoarm innovativ sein wollen. Da Manager einen wesentlichen Anteil am Erfolg der Einführung von Scrum haben, stellen sie damit die Weichen für ein Unternehmen, das risikoarm Innovation fördern will. 

Nachdem sich Scrum im Team etabliert hat, können wir mit der Bestimmung der Time-to-Learn die Innovationsfähigkeit steuern.


What did you think about this post?