Das „Kekssystem“ hilft agilen Teams bei der Lösung ungewohnter Betriebsaufgaben

Der Entwicklungsprozess mit Scrum bringt es mit sich, dass die beteiligten Teams Software-Versionen schnell und kontinuierlich veröffentlichen. Bei der Implementierung in den Betrieb kommt es allerdings auch immer wieder zu Problemen, die Entwicklung und Betrieb nur gemeinsam lösen können. Im Scrum-Prozess ist dieser zusätzliche Aufwand jedoch so nicht vorgesehen. Damit es nicht zu Frustration auf einer der Seiten oder sogar beiden kommt, braucht es eine Methode, um mit solchen Herausforderungen umzugehen.

Bei AUSY Technologies haben wir in verschiedenen Projekten gute Erfahrungen mit dem „Kekssystem“ gesammelt. Dabei handelt es sich um eine innovative Methode, die an den Scrum-Prozess angelehnt ist und mit kommunikativen Elementen angereichert ist. Den Namen bezieht das Kekssystem daraus, dass die Kekse darin eine Art „Währung“ darstellen, die Bonus-Zeit für unerwartete Probleme abbildet. Im Folgenden sehen wir uns an, wie dies genau funktioniert.

Betriebsaufgaben schlagen sich auch im Scrum-Prozess nieder

Auch wenn DevOps sich immer größerer Beliebtheit erfreuen, ist die – zumindest organisatorische –Trennung zwischen Entwicklung und Betrieb in vielen Unternehmen nach wie vor Realität. Und: Wird die Entwicklung nah am Scrum-Lehrbuch praktiziert, finden Betriebsthemen keine Berücksichtigung. Treten also Störungen im Betrieb auf, erschwert dies die Planung des Sprints und führt zu technischen und funktionellen Störungen des Produktivsystems. Hierdurch lassen sich geplante Sprintziele nur noch schwer erreichen. Der agile Motor kommt ins Stottern – als wäre Sand oder Zucker in den Tank geraten...

Eine Möglichkeit, diese Herausforderung ohne zusätzlichen Prozess zu lösen – und damit eine Alternative zum Kekssystem – ist die Umstellung auf Kanban. Diese sollte noch erwähnt sein, bevor wir uns das Kekssystem genauer ansehen. Kanban schreibt im Gegensatz zu Scrum nämlich keinen Sprintzyklus und damit keine Sprintplanung vor. Deshalb lassen sich (zusätzliche) Betriebsaufgaben leichter in den Entwicklungsprozess integrieren. Sollte der notwendige Puffer für Ungeplantes über einem Wert von über 35 Prozent liegen, ist ein Wechsel zu Kanban naheliegend. Zu erwähnen bleibt allerdings, dass hierzu gegebenenfalls noch eine große Umstellung liegt, wenn die Entwicklung bisher mit Scrum gearbeitet hat. Es ist also abzuwägen, ob sich ein Wechsel im Hinblick auf den damit verbundenen Aufwand wirklich lohnt.

Das Kekssystem ermöglicht Scrum plus Betriebsaufgaben

Da es viele gute Gründe gibt, Scrum beizubehalten, kommt in vielen Fällen das Kekssystem in Spiel. Hier geht es um Projekte, in denen fünf bis maximal 35 Prozent der Zeit als Puffer für Betriebsaufgaben zurückzustellen sind. Die Grundfunktion des Kekssystems besteht darin sicherzustellen, dass die Sprintplanung trotz der Betriebsaufgaben erfüllbar bleibt.

Pro Sprint ist also ein Zeitpuffer für Unerwartetes einzuplanen. In jedem Sprint wird der zu erwartende Aufwand neu geschätzt und gegebenenfalls an die Schätzung angepasst. Dieser Puffer ermöglicht es den Entwicklern, Betriebsaufgaben zu beheben und gleichzeitig die Sprintplanung einzuhalten. Die Größe des Puffers lässt sich wie folgt berechnen: Zunächst wird der Umfang der zur Verfügung stehenden Personalzeit geschätzt und daraus ein prozentual bemessener Puffer definiert.

Dieser Puffer wird nun in eine Anzahl von Keksen übersetzt. Jeder Keks entspricht einer Zeiteinheit, zum Beispiel einer Stunde. Ist das Team mit einer ungeplanten Aufgabe von über 15 Minuten beschäftigt, darf es die jeweils benötigte Anzahl an Keksen aus der Schale entnehmen. Behandelt ein Entwickler also zum Beispiel einen unvorhergesehenen Incident über eineinhalb Stunden hinweg, darf er sich dafür zwei Kekse nehmen.

Die Sprintplanung gilt erst dann als verfehlt, wenn die gesamte Schale an Keksen verbraucht ist. Damit ist zugleich ein „Frühwarnsystem“ in den Scrum-Prozess integriert. Der Product Owner kann daraus entsprechende Maßnahmen ableiten, zum Beispiel die Stakeholder über das verfehlte Ziel informieren oder weniger dringliche User Stories aus dem Sprint nehmen.

Sinnvoll ist darüber hinaus, eine eigene Dokumentation für das Kekssystem anzulegen, aus der ersichtlich wird, wie viele Kekse für welche Aufgaben entnommen wurden. Dies bietet eine gute Basis, um Optimierungen an der Schätzung und den Workflows vorzunehmen. Sollte Puffer über mehrere Sprints ungenutzt bleiben, lässt sich dies in einer in einer neuen Planung abbilden.

Zusammenfassend lässt sich also festhalten, dass es eine gewisse Modifizierung des Scrum-Prozesses braucht, um auch Betriebsaufgaben entsprechend zu berücksichtigen. Das Kekssystem hat sich als einfache und effektive Methode erwiesen, dies zu bewerkstelligen. Die Arbeit mit den Keksen hat dabei nicht zuletzt auch für einigen Spaß gesorgt, was für ein gelungenes Projekt ein nicht zu übersehender Faktor ist.