Umgang mit Betriebsaufgaben im Scrum-Prozess Wie Kekse dem DevOps-Team Scrum schmackhaft machen

Nimmt ein Scrum Team einmal Fahrt auf, geht die kontinuierliche Veröffentlichung von Software-Versionen schnell zu Lasten der Zusammenarbeit zwischen Entwicklung und Betrieb. Mit einer ebenso einfachen wie leckeren Methode lässt sich das Effizienzproblem aber beheben.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Windhoff Group

Das Scrum Team umfasst meist Entwickler, Tester und einen Product Owner, der sich um die Features, Priorisierung und den Kunden kümmert – nur der Betrieb ist nicht berücksichtigt. Um dem entgegenzuwirken, verfolgen manche Unternehmen den Ansatz, Betriebler in Scrum Teams zu integrieren – also ein sogenanntes eingebettetes DevOps-Scrum-Team gründen.

Wenn ein Produkt betrieben werden muss um Gewinn zu erwirtschaften, warum dann nicht ein interdisziplinäres Team gründen, in dem zusätzlich zu den oben genannten Rollen und Skills, Teammitglieder vorhanden sind, die Fähigkeiten für Deployment und Betrieb mitbringen? „Interdisziplinäre Teams verfügen über alle Kompetenzen, die erforderlich sind, um die Arbeit zu erledigen, ohne dabei von Personen außerhalb des Entwicklungsteams abhängig zu sein“, heißt es dazu im Scrum Guide

Zusätzlich bestehen stärkere Anreize, qualitativ hochwertige und ausreichend getestete Software zu liefern, wenn das Team dasselbe Team ist, das nicht nur neue Software und Features entwickelt, sondern diese auch betreibt. Desweiteren hilft es dem Team, die sogenannte T-Shaped Kompetenz auf- und weiter auszubauen.

Der Entwickler ist Spezialist in seinem Gebiet, durch die Integration in das Team kann er Breitenwissen im Bereich Betrieb, sowie die Betriebler in der Entwicklung aufbauen. Die Kommunikation und das Verständnis zueinander verbessern sich. So einleuchtend dieser Ansatz sein mag, er birgt in der Praxis mindestens folgende Herausforderung:

• Wie ist im Scrum Prozess mit typischerweise unvorhergesehenen und absolut dringlichen Aufgaben (z.B. Behebung technischer und funktioneller Störungen) aus dem Betrieb umzugehen?

• Werden diese Aufgaben ins Backlog aufgenommen?

• Stören diese nicht gravierend die Sprint Planung und den Sprint Ablauf?

Umgang mit Betriebsaufgaben im Scrum-Prozess

Sobald ein Scrum Team – zusätzlich zur Weiterentwicklung – den Betrieb von Produktivsystemen gewährleisten muss, wird die Planung des Sprints erschwert und der Ablauf häufig von technischen und funktionellen Störungen des Produktivsystems gestört. Die ungeplanten Tätigkeiten zum Beheben der Störungen und zum Gewährleisten eines stabilen Betriebs müssen in der Mehrzahl der Fälle sofort erledigt werden und sind ungeplant.

Geplante Sprintziele lassen sich somit nicht oder nur schwer erreichen. Die Akzeptanz der Sprintplanung sinkt, bis Stakeholder den Scrum-Prozess als solchen in Frage stellen. Die naheliegendste Lösungsmöglichkeit wäre, eine Umstellung auf Kanban zu prüfen.

Kanban hat keinen Sprintzyklus und somit keine Sprintplanung. Diese agile Methode kommt somit besser mit Betriebsaufgaben zurecht. Scheidet diese Möglichkeit aber aus und soll der Scrum Prozess aufrechterhalten werden, gibt es ein Tool, das in diesem Fall die Schmerzen lindern kann:

Das Kekssystem

Liegen einem Scrum Team immer wieder Aufgaben vor, die nicht planbar und dringlich sind, ist die Aufnahme dieser Tätigkeiten in ein Backlog mit anschließender Sprintplanung keine Option. Das Kekssystem kann dabei helfen, trotz dringlicher und unplanbarer Aufgaben eine erfüllbare Sprintplanung zu gewährleisten.

Grundfunktion:

• Damit eine Sprintplanung erfüllbar bleibt und nicht gestört wird, ist pro Sprint ein Zeitpuffer für Unerwartetes einzuplanen.

• Dieser Puffer wird in jedem Sprint Planning neu geschätzt. Oft hat das Team bereits Erfahrungswerte in welchen Zeiträumen im Jahr besonders viele Störungen zu erwarten sind.

• Wurde der Puffer ausreichend groß bemessen, lassen sich unerwartete Aufgaben erledigen, ohne dass dies die Sprintplanung beeinträchtigt.

• Optional lässt sich dokumentieren, wie viele der unerwarteten Aufgaben aufgetreten sind und in welchen Kategorien. Diese Statistik hilft, in einer Retrospektive Anhaltspunkte für mögliche Maßnahmen zur Gegensteuerung von unerwünschten Entwicklungen finden.

Wie wird der Puffer berechnet?

Am Anfang eines Sprints wird ermittelt, wie viele Personentage dem Team in dem Sprint zur Verfügung steht. Geplante Abwesenheiten werden abgezogen. Manche Teams ziehen zusätzlich noch eine Pauschale für die Scrum Events ab. Übrig bleibt die verfügbare Kapazität in Personentagen nach Abzug von Urlaub und der Pauschale für die Scrum Events.

Nun schätzt das Team im Sprint Planning die Prozentzahl an Arbeit, die es als Puffer für Unerwartetes reservieren will. Hieraus lässt sich der Puffer berechnen. Im vorangestellten Beispiel stehen dem Team für den nächsten Sprint 56 Kekse zur Verfügung.

Das System erhält seinen Namen dadurch, dass dem Team in diesem Sprint, in einer Schale abgezählt, die ausgerechnete Anzahl an Keksen bereitgestellt wird. Jedes Teammitglied, das länger als 15 min an etwas arbeitet, das nicht im Sprint eingeplant war, darf sich für die aufgewandte Zeit entsprechend viele Kekse nehmen.

Mit der Festlegung, wie viel Zeit einem Keks entspricht und ab wie viel Zeit man einen Keks nehmen darf, kann das Team gerne experimentieren. Die im Beispiel aufgestellte 15-Minuten-Regel soll verhindern, dass für Kleinstaktivitäten (z. B. Toilettengang, kurze Pause, kurze Frage eines Kollegen) ein Keks genommen werden muss. Dies macht das System leichter ausführbar.

Dafür wiederum darf sich das Teammitglied immer einen ganzen Keks nehmen, auch wenn die zwei Stunden nicht vollständig erreicht wurden. Beispiel: Entwickler behebt einen Incident und benötigt dafür Dauer 1,5 Stunden, darf sich aber einen Keks à 2 Stunden nehmen.

Am Füllstand der Schale kann das Team und jeder andere nachvollziehen, wie viel Puffer für Ungeplantes im laufenden Sprint noch bleibt. Erst wenn die Schale leer ist, ist die Sprintplanung durch die Betriebsaufgaben beeinträchtigt worden. Der Product Owner kann reagieren und entweder eine nicht begonnene Story aus dem Sprint nehmen und/oder die Stakeholder vorab vorwarnen, dass unerwartet hohe Aufwände für die Betriebstätigkeit entstanden sind und somit das Sprintziel gefährdet ist.

Dokumentation Kategorien

Wollen Teams etwas genauer wissen, wofür ungeplante Aufwände angefallen sind, besteht eine bewährte Lösung darin, „Keks-Kategorien“ zu bilden. Jeder entnommene Keks ist einer dieser Kategorien zugeordnet.Dies kann beispielsweise durch eine Strichliste erfolgen, in der jeder gegessene Keks festgehalten wird.

Falls sich die Teammitglieder nach einigen Sprints beschweren, dass sie durch die vielen Kekse zugenommen haben, kann auch nur noch die Strichliste verwendet werden. Eine weitere Variante besteht darin die Kekse auf Etiketten zu drucken und die Keks-Aufkleber auf einem Flipchart zuzuordnen. Der Vorteil dabei ist, dass die Haptik bestehen bleibt.

Fazit

Das Kekssystem ist eine bereits in vielen Teams erprobte, spielerische Antwort auf die Frage, wie ein Team mit nicht geplanten, aber dringlichen Aufgaben in einem Sprint umgehen kann. Allerdings sollte das Kekssystem kein Freibrief sein, Störungen und Ungeplantes achselzuckend zu akzeptieren.

Gerade mit diesem System sollte ein wichtiges Ziel des Teams sein, durch kontinuierliche Verbesserung Störungen und ungeplanten Aufgaben vorzubeugen oder die Reaktionszeit darauf zu reduzieren. Wenn das Team sich entschließt Ungeplantes und Störungen mit diesem System zu dokumentieren, liefert das System wichtige Anhaltspunkte in welchen Bereichen optimiert werden kann.

Grenzen des Keks-Systems

Daniel Ruckriegel

Nach meiner persönlichen Erfahrung funktioniert das System gut bei einem Puffer für Ungeplantes im Bereich zwischen fünf Prozent bis maximal 35 Prozent. Lag der Puffer für eine längere Zeit über diesem Wert, haben sich die Teams oft für einen Wechsel auf Kanban entschieden.

* Daniel Ruckriegel ist als Agile Coach und Requirements Engineer bei der Pentasys AG tätig. Als Enthusiast und mit seinen Erfahrungen in agilen Projekten in den Bereichen Financial Services, Automotive und E-Commerce unterstützt er Kunden und Kollegen dabei, agile Methoden für den Projekterfolg einzusetzen.

(ID:45841338)