Run und Change in einem Team: Betrieb und Weiterentwicklung agil organisieren

Run und Change gehören in ein Team, wenn der Betrieb weniger als die Hälfte der Teamkapazität bindet und das Team ein Produkt von der Weiterentwicklung bis zum Betrieb verantwortet. Die Kapazität wird in einen festen Anteil für Betrieb und einen Anteil für Weiterentwicklung geteilt, und die Arbeit läuft in Klassen mit eigenen Regeln. Bindet der Betrieb mehr als die Hälfte, ist zuerst der Betriebsaufwand zu senken, bevor die Teams neu geschnitten werden.

Dieser Beitrag richtet sich an Bereichsleiter und Delivery-Verantwortliche, deren Teams zwischen Störungen und geplanter Weiterentwicklung aufgerieben werden. Er vergleicht drei Organisationsformen nach Kriterien, zeigt einen Rechenweg für die Kapazitätsaufteilung und beschreibt, wie sich Betriebsarbeit in einem agilen Team steuern lässt.

Warum scheitern Teams, die Run und Change gleichzeitig verantworten?

Sie scheitern, weil Betriebsarbeit unregelmäßig eintrifft und die Planung der Weiterentwicklung stört. Eine Störung am Montagmorgen wirft den Sprint um, den das Team am Freitag davor geplant hat. Nach einigen Wochen liefert das Team weder zuverlässig im Betrieb noch bei der Weiterentwicklung, und die Beteiligten erleben beides als Überlastung. Der Scrum Guide von 2020 sieht für solche Arbeit keinen eigenen Platz vor: Alles, was das Team tut, gehört in das Product Backlog, und das Sprint-Ziel gilt als Zusage. Unplanbare Betriebsarbeit passt in dieses Bild nur, wenn das Team für sie Kapazität reserviert.

Dazu kommt eine Eigenheit der Arbeit selbst. Betriebsarbeit ist meist dringend und klein, Weiterentwicklung groß und langfristig wirksam. Teams, die beides in einer Liste mischen, bearbeiten zuerst das Kleine und Dringende, und die Weiterentwicklung rutscht nach hinten. Das Ergebnis ist Wartung eines Produkts, das sich nicht mehr verbessert.

Wann gehören Run und Change in ein Team?

Sie gehören in ein Team, wenn der Betriebsanteil unter der Hälfte liegt, und die Gründe dafür sind Lernen und Verantwortung. Werner Vogels, Technikchef von Amazon, prägte 2006 in einem Interview der Zeitschrift ACM Queue den Grundsatz „You build it, you run it“: Das Team, das etwas baut, betreibt es auch. Der Grund ist ein Rückkopplungsprozess. Wer nachts oder am Montagmorgen für eine Störung geradesteht, baut das Produkt so, dass es seltener ausfällt. Trennt eine Organisation Betrieb und Entwicklung, entsteht an der Übergabe ein Verlust an Wissen, den der Beitrag zu den Übergaben zwischen Abteilungen beschreibt.

Skelton und Pais ordnen diese Verantwortung in „Team Topologies“ aus dem Jahr 2019 den Stream-aligned Teams zu, die einen Strom von Arbeit von der Idee bis zum Betrieb verantworten. Die Grenze liegt dort, wo der Betrieb so viel Aufmerksamkeit bindet, dass für Weiterentwicklung keine Kapazität bleibt. Das Google-Team, das den Betrieb der eigenen Dienste verantwortet, hat dafür 2016 im Buch „Site Reliability Engineering“ eine Regel veröffentlicht: Betriebsarbeit wie Tickets, Rufbereitschaft und manuelle Routine darf höchstens die Hälfte der Zeit eines Teams beanspruchen. Die übrige Zeit gehört der Verbesserung des Systems. Die Regel gilt dort für Betriebsteams. Ihre Übertragung auf Teams, die ein Produkt entwickeln und betreiben, ist eine Deutung dieses Beitrags, die sich als Maßstab für die Entscheidung eignet, ob ein Team beides verantworten kann. Mehr zum Schnitt der Teams steht im Beitrag zu Team Topologies.

Welche drei Organisationsformen gibt es?

Es gibt drei Formen: die Rotation, die Kapazitätsreserve und das getrennte Betriebsteam. Welche passt, bestimmt der Anteil des Betriebs an der Teamkapazität, den Sie aus den letzten zwölf Wochen messen. Die Schwellen von 20 und 50 Prozent sind eine Faustregel dieses Beitrags, und nur die 50 Prozent haben in Googles Regel ein Vorbild. Die 20 Prozent folgen aus der Rechnung, dass eine Person in einem Team aus sechs Personen rund ein Sechstel der Kapazität bindet.

Bei der Rotation übernimmt eine Person je Sprint alle eingehenden Betriebsanfragen und ist für die Weiterentwicklung freigestellt. Die übrigen arbeiten ungestört an der Planung des Sprints. Nach dem Sprint wechselt die Aufgabe. Dieses Muster eignet sich für Teams mit wenigen und kurzen Störungen.

Bei der Kapazitätsreserve plant das Team nur den Teil seiner Kapazität, der nach Abzug des gemessenen Betriebsanteils übrig bleibt. Betrieb und Weiterentwicklung stehen auf einer gemeinsamen Liste, und die Arbeit ist in Klassen eingeteilt.

Das getrennte Betriebsteam lohnt sich bei einem Betriebsanteil über der Hälfte oder wenn der Betrieb eine Rufbereitschaft verlangt, die sich mit der Weiterentwicklung nicht verträgt. Die Übergabe zwischen den Teams braucht dann klare Kriterien, damit Wissen nicht verloren geht.

Wie rechnet man die Kapazität für Betrieb und Weiterentwicklung?

Die Kapazität ergibt sich aus drei Schritten: dem gemessenen Betriebsanteil, einem Puffer für Schwankung und dem verbleibenden planbaren Rest. Im ersten Schritt erheben Sie aus den letzten zwölf Wochen, wie viel Zeit das Team für Betriebsarbeit aufgewendet hat, aus Tickets, Zeitbuchungen oder einer einfachen Schätzung je Woche. Im zweiten Schritt addieren Sie einen Puffer von etwa einem Fünftel des gemessenen Werts, weil Betriebsarbeit schwankt. Im dritten Schritt planen Sie die Weiterentwicklung nur mit dem Rest.

Ein Beispiel zur Veranschaulichung, mit angenommenen Werten: Ein Team aus sechs Personen verfügt über 30 Personentage je Woche. Die Messung ergibt, dass im Mittel 9 Personentage in den Betrieb fließen, das sind 30 Prozent. Der Puffer von einem Fünftel beträgt rund 2 Personentage. Das Team reserviert also 11 Personentage für den Betrieb und plant 19 Personentage für Weiterentwicklung. Sinkt der Betriebsanteil über mehrere Wochen, wird die Reserve verkleinert, steigt er, wird die Ursache untersucht, bevor die Reserve wächst. Die Methode ergänzt die Überlegungen im Beitrag zur Kapazitätsplanung in agilen Teams.

Wie steuert man Betriebsarbeit neben der Weiterentwicklung?

Man steuert sie über Klassen der Arbeit, die David Anderson in seinem Buch zu Kanban von 2010 als „Classes of Service“ beschreibt. Jede Klasse hat eine eigene Regel für Vorrang und Frist. Für Run und Change genügen vier Klassen: Störungen, die sofort bearbeitet werden und alles andere unterbrechen, Arbeit mit festem Termin, Standardarbeit, die nach Reihenfolge läuft, und Verbesserungen ohne Termin. Die vier Klassen sind eine Anpassung der Klassen, die Anderson beschreibt (dringend, fester Termin, Standard, nicht greifbar), an den Betrieb. Die Klasse der Störungen erhält eine Obergrenze, etwa eine Störung gleichzeitig, damit sie das Board nicht überflutet. Wie solche Grenzen den Fluss verbessern, erklärt der Beitrag zu Kanban.

Wichtig ist, dass Verbesserungsarbeit am Betrieb einen festen Anteil erhält. Automatisierung wiederkehrender Störungen senkt den Betriebsanteil und schafft Kapazität für die Weiterentwicklung. Teams, die diese Arbeit streichen, sobald es eng wird, bleiben dauerhaft im Betrieb gefangen.

Welche Rolle hat die Führung?

Die Führung legt den Betriebsanteil fest, schützt die Reserve und entscheidet über die Obergrenze für Störungen. Sie benennt je Produkt eine Person, die über die Priorität von Betrieb und Weiterentwicklung entscheidet, in der Regel den Product Owner. Fehlt diese Entscheidungsstelle, verhandeln Teammitglieder jede Störung einzeln mit dem Fachbereich, und der laute Anrufer gewinnt. Die Führung beobachtet zwei Kennzahlen: den Betriebsanteil im Verlauf und das Alter der ältesten Weiterentwicklungsarbeit auf dem Board.

Run und Change mit Niehues Consulting

Niehues Consulting ist eine Beratung für KI-Management und Organisationsdesign aus der Lieferperspektive mit Sitz in Düsseldorf. Gründer Marin Niehues baut Organisationen, die liefern, und arbeitet als Delivery Manager, Projektmanager und Product Owner in Projekten von VC-finanzierten Scaleups bis zu DAX-40-Konzernen. Im Leistungsfeld Delivery Management und Organisationsdesign gehört dazu, Teams und Zuständigkeiten für Betrieb und Weiterentwicklung zu schneiden und die Entscheidungswege dafür zu klären.

Das Vorgehen folgt dem Niehues Delivery Model. Für diese Frage zählen drei Prüffragen: Wer entscheidet, wer liefert, wer nutzt? Welche Rollen, Entscheidungswege und Schnittstellen braucht der Betrieb? Wer verantwortet den Betrieb ab dem ersten Tag? Den Einstieg bildet eine kostenfreie Erstberatung von 30 Minuten, die Sie über den Kontakt vereinbaren. Umfang und Konditionen eines Vorhabens werden dort besprochen.