„Scrum ist Gold wert, um risikoarme Innovation voranzutreiben.” 5 Antworten zum Innovations-Wert von Scrum

Ohne Veränderung und Anpassung können Unternehmen nicht bestehen. Das war schon immer so – die Abstände, in denen Anpassung erforderlich wird, scheinen jedoch heute kürzer zu sein als noch vor einigen Jahrzehnten.

Unabhängig davon, ob es um veränderte betriebliche Rahmen-Bedingungen geht (wie Fachkräftemangel und Materialknappheit) oder um eine Markt-Veränderung (wie Rückgang der Produktnachfrage, steigender Wettbewerb) – es Bedarf stetiger Innovation, um drohende Verluste auszugleichen.

Zum anderen ist nur allzu deutlich, 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.

Wie können Unternehmen risikoarm innovativ sein?

Die Frage enthält ein Paradox.

Innovation ist hochgradig risikobehaftet. Denn Innovation kann weder geplant werden, noch stehen die Erfolgschancen dabei automatisch 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. Nur so lernen wir auch am schnellsten, ob die Entscheidung richtig war.

Wie kann das Management risikoarme Innovation, d.h. schnelles Dazulernen fördern?

Die in Managementkreisen bereits bekannte Antwort auf diese Frage geht auf Peter Drucker, den Gründer des „modernen Managements“, zurück:

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

Führungskräfte müssen also einen Weg finden, Lernerfolge 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 das Management 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 beträgt in diesem Beispiel 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. Dieses Risiko übersteigt die eigentlichen Entwicklungskosten maßgeblich. Denke nur an all die Folgeentscheidungen, die auf einer Annahme von vor neun Monaten getroffen wurden, und die sich eventuell im Lernprozess als falsch erweisen.
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 zur Time-to-Learn.

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

Was sind die Vorteile einer kurzen 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 aufgewendeter Arbeitszeit.
  
• Niedrige Änderungskosten: Änderungskosten 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 in der Produktentwicklung, haben wir alles, was wir brauchen, um durch die Feedbackschleife mit Kunden und Stakeholdern die Time-to-Learn sichtbar zu machen. 

Wie lässt sich die Time-to-Learn in Scrum 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önnen 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 benötigen wir ein Instrument, um die Time-to-Learn zu verkürzen. 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 Unternehmerinnen und 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 nochmal 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.