10.02.2016  Verfasst von Kai Schikowski in Agile Methoden  

Ein Sprint dauert länger als 90 Minuten.

Scrum-Sprints und technische Schuld sind eng verbunden, wie kann man es lösen?

„Nach dem Spiel ist vor dem Spiel“ lautet ein bekanntes Zitat von Sepp Herberger, man könnte für agile Entwicklungsmodelle auch sagen: „Nach dem Sprint ist vor dem Sprint.“ Was bei Fußballspielern zu einer Fokussierung auf den nächsten Gegner führen sollte, ist für Entwicklungsteams eine Ausrichtung auf das nächste Feature oder das nächste Release. Beide Male soll vergessen werden, was davor einmal war. Darüber hinaus soll zielorientiert an der nächsten Herausforderung gearbeitet werden. Daran ist doch nichts auszusetzen, oder? Diese Herangehensweise ist doch im Gegenteil sehr löblich, oder etwa nicht?

Im Mikrokosmos eines Fußballspiels mag das stimmen, denn jedes Spiel beginnt bei 0:0, doch in der Softwareentwicklung ist diese Betrachtung nicht ganz zutreffend. Die Systemarchitektur und der Programmcode, auf dem aufgesetzt wird, sind weiterhin vorhanden, unabhängig davon, wie sehr sich der Mensch auf das nächste Feature konzentriert. Die Technik vergisst nicht.

Eine vollständige Konzentration auf die kurzfristige Time-to-Market von Produktentwicklungen ist somit langfristig gesehen kontraproduktiv. Stellen Sie sich vor, dass Sie mit einem Auto auf der Autobahn fahren. Sie fahren so dicht wie möglich auf den vor Ihnen fahrenden Wagen auf und jeder andere tut das auch. Es entsteht eine Kette von schnell aufeinanderfolgenden Wagen, die sich schnell vorwärts bewegt. Dieses Prinzip funktioniert solange, bis einer der Wagen auf die Bremse tritt. Die anderen Wagen verlieren nicht nur Geschwindigkeit, sie sind zu nah dran und es kommt zu einem Unfall. Das gesamte System steht und es kommt zum Stau. Sie wollen nicht, dass ein bremsendes Feature ihr gesamtes Unternehmen anhält.

Wie kann man dem Stau vorbeugen und trotzdem schnell an das Ziel gelangen? Die Antwort darauf mag auf den ersten Blick irritierend erscheinen: Indem man Geschwindigkeit aus jedem einzelnen Wagen nimmt und den Abstand vergrößert. In agilen Entwicklungsmethoden spricht man von der Einführung von Slack.

Die Einführung von Slack hat aus meiner Sicht zwei zentrale Vorteile. Als erster Aspekt ist hier die technologische Komponente zu betrachten. Durch die gezielte Entschleunigung der Softwareentwicklung werden Freiräume geschaffen. Diese Freiräume können durch gezielte Maßnahmen effizient ausgefüllt werden. So können architektonische Konzepte ausprobiert und technologische Schuld abgebaut werden. Es können Teststrategien und Automatisierungen analysiert werden und Ableitungen und Verbesserungen für die zukünftige Qualitätssicherung getroffen werden. Kurzum, die Software und Architektur wird langfristig wettbewerbsfähig gehalten.

Der zweite Aspekt ist die menschliche Komponente im Entwicklungsprozess. Durch die veränderte Entwicklungsstrategie werden Möglichkeiten offeriert, die persönliche Entwicklung voranzutreiben und Hindernisse in der täglichen Arbeit mit der Software abzubauen. Entwicklungsprozesse und interdisziplinäre Zusammenarbeit über Teamgrenzen hinaus können verbessert werden und zum nachhaltigen Erfolg der Unternehmung beitragen. Das Ziel ist es, den Stau zu lösen bzw. zu verhindern und das System im Fluss zu halten.

Yerkes, R.M. & Dodson, J.D.: The relation of strength of stimulus to rapidity of habit-formation. Journal of Comparative Neurology and Psychology, 18 (1908) 459-482

Abbildung: Motivations- und Produktivitätskurve nach Yerkes und Dodson (Yerkes, R.M. & Dodson, J.D.: The relation of strength of stimulus to rapidity of habit-formation. Journal of Comparative Neurology and Psychology, 18 (1908) 459-482)

Im oben dargestellten Graphen lässt sich erkennen, dass eine Forderung nach immer mehr, immer schneller, kontraproduktiv für die Mitarbeitermotivation ist. Ein Fluss im Arbeitsprozess stellt sich dann ein, wenn man herausgefordert, aber nicht überfordert wird. Aus eigener Erfahrung kann ich berichten, dass Entwicklungsteams, die sich seit Jahren im „Sprint-Modus“ befinden, selbst immer weiter ausbremsen und an Produktivität verlieren, sofern sie Feature an Feature reihen. Selbiges Phänomen lässt sich ebenso auf die Software und IT-Architektur als solches übertragen. Eine ständige Ausreizung aller kurzfristigen Möglichkeiten führt langfristig dazu, dass die technische Schuld das System und die Entwicklung in ihm auf natürlichem Wege ausbremst.

Es gibt verschiedenste Möglichkeiten in agilen Entwicklungsprozessen auf diese Herausforderung zu reagieren. Im Folgenden sind einige Varianten kurz skizziert:

  • Freie Tage zwischen den Sprints:
    Einen festen Zeitraum bis zu zwei Tagen zwischen dem Sprintende und dem Sprintbeginn für Verbesserungen reservieren.
  • Reservierung von Sprints:
    Einen dedizierten Rhythmus festlegen, nach dem ein Slack-Sprint durchgeführt wird, z.B. vier Featuresprints ein Slacksprint.
  • Entwicklertage:
    Feste Tage im Monat reservieren, an denen die gesamte Entwicklungsabteilung Innovationen vorantreibt.

Neben diesen genannten Beispielen gibt es weitere Optionen, die individuell auf die jeweilige Unternehmenssituation adaptiert werden sollten. Mein Favorit ist eine Kombination aus einem festen Zeitraum in jeder Woche (vier Stunden) und einem dedizierten Sprint (eine Woche lang) mit abschließender Retrospektive und Teamevent in einem festen Rhythmus.

Die langjährige Zusammenarbeit mit Entwicklungsteams hat mich zu der Erkenntnis gebracht, dass die langfristige Systemeffizienz und die Mitarbeiterproduktivität nur dann im Fluss zu halten sind, wenn sie als eine zentrale Herausforderung des Managements für ein nachhaltiges Bestehen am Markt betrachtet werden. Dieses muss in der Kultur gelebt werden und dafür müssen den Mitarbeitern Räume zur Gestaltung gegeben werden.

Denn: Wenn das System erst einmal antwortet: „Mailand oder Madrid: Hauptsache Italien!“(Zitat von Andreas Möller), dann ist ein schwerwiegender Fehler aufgetreten und die technische Schuld gefährdet das Geschäft.

Der Autor

Kai Schikowski
Consultant