Das SWAT-Team in Scrum

Wenn ein komplettes Software-Entwicklungsteam gemeinsam an einem Neuprojekt arbeitet, wie zum Beispiel der Erstellung eines neuen Online-Shops, wird die Projektarbeit heute in vielen Fällen agil nach Scrum organisiert. Das ganze Team arbeitet gemeinsam auf ein Ziel hin, nämlich die neue Software so fertigzustellen, dass Nutzer und Kunde den maximalen Business Value daraus ziehen können. Wenn alles gut klappt, kann der neue Shop bald den Produktivbetrieb starten. Und da während des agilen Entwicklungsprozesses ein besonderes Augenmerk auf die Softwarequalität gelegt wurde, läuft die Software natürlich absolut fehlerfrei. Das Team kann sich in Ruhe dem nächsten Projekt widmen …

Ein schöner Traum soweit. Die Realität sieht leider häufig anders aus. Und so muss sich das Entwicklungsteam von nun an auch um Anwenderanfragen und Bugfixing kümmern. Parallel sind in der Regel schon wieder viele neue Anforderungen in der Pipeline, die direkt nach dem Go-Live umgesetzt werden sollen. Die Frage, wie sich diese beiden Aspekte in Einklang bringen lassen, bereitet vielen Entwicklungsteams Kopfzerbrechen.

Supportanfragen einfach ins Backlog?

In der Realisierungsphase weist das Product Backlog, welches die Epics und User Stories für die zu entwickelnde Anwendung enthält, dem Team den Weg. Für jeden Sprint wird ein Sprint Backlog erstellt, aus dem sich die Teammitglieder selbstorganisiert User Stories und technische Aufgaben zur Bearbeitung ziehen. Ein Kanban-Board, welches idealerweise als physikalisches Board (z. B. ein Magnetboard oder eine Pinnwand) oder auf einem großen Bildschirm im Teamraum von allen einsehbar ist, dient zur Steuerung des Arbeitsflusses und zeigt den Arbeitsfortschritt.

Nur wie passen Fehlermeldungen und Kundenanfragen in die heile Welt von Product und Sprint Backlog? Leider haben es diese Anfragen häufig an sich, dass sie zeitkritisch und vor allem unberechenbar sind, was den Bearbeitungsaufwand angeht. Was vordergründig so aussieht wie eine kleine Störung im Produktivbetrieb oder ein kleiner Makel an der Benutzeroberfläche, kann im Quellcode große Wellen schlagen. Ein gutes Beispiel für diese Art von Störungen sind Performancedefizite oder Nebenläufigkeitsprobleme. Da sich der Analyse- und Behebungsaufwand hier schwer bis gar nicht im Vorhinein abschätzen lässt, kann das Team diese Arbeiten nicht im Rahmen des regulären Sprint Plannings einplanen.

Kontextwechsel bremsen den Entwicklungsfortschritt

Darüber hinaus halten sich Supportanfragen in der Regel nicht an den Sprintrhythmus, sondern tauchen urplötzlich und mitten im Sprint auf. Durch die Fehleranalyse und –behebung werden die Entwickler aus der Implementierung neuer Features immer wieder herausgerissen. Die häufigen Kontextwechsel kosten Zeit und machen das Team ineffizient. Ich habe es schon in vielen Softwareprojekten erlebt, dass das Team nur noch auf die Belange des Tagesbetriebs reagiert. Die Umsetzung neuer Stories bleibt dabei auf der Strecke. Sprintziele werden nicht mehr erreicht und der Burndown im Sprint ist durch lauter Scope Changes quasi nicht-existent.

Von Zeitpuffern und dedizierten Betriebsteams

Häufig wird empfohlen, im Sprint einen Zeitpuffer für Supportanfragen und andere „Kannst-du-mal“-Aufgaben vorzusehen. Ein gängiger Richtwert sind hier 20% der gesamten produktiven Entwicklungszeit. Zu beachten ist hierbei, dass die produktive Entwicklungszeit auch bei einer 40-Stunden-Woche eigentlich nie bei 8 Stunden am Tag liegt, sondern niedriger. Meiner Erfahrung nach ist es hilfreich, eher von 6 Stunden produktiver Entwicklungszeit auszugehen.

Zumindest bezüglich des Sprintziels und des Burndown Charts kann ein solcher Zeitpuffer eine gute Möglichkeit sein, die Lage etwas zu entspannen. Trotzdem werden die Entwickler nach wie vor durch mit Supportanfragen zusammenhängenden Anrufen, Mails oder neue Tickets aus ihrer aktuellen Tätigkeit rausgerissen.

Alternativ habe ich es auch erlebt, dass die Unterstützung des Produktivbetriebs in ein dediziertes Entwicklungsteam abgegeben wurde. Dieses Team hatte die Aufgabe, sich nur um den Tagesbetrieb zu kümmern. Meiner Erfahrung nach ist dies jedoch eine eher ungünstige Lösung. Für den Know-how-Transfer zwischen dem Realisierungsteam und dem Tagesbetriebsteam steht aufgrund des fortlaufenden Projektgeschäfts meist wenig Zeit zur Verfügung. Die Entwickler im Betriebsteam fühlen sich oft allein gelassen, wenn die Kollegen im Realisierungsteam aufgrund der nächsten Projektphase zu wenig Zeit haben, um sie zu unterstützen. Manch einer im Betriebsteam sieht sich sogar zum Entwickler zweiter Klasse degradiert, nach dem Motto: „Wir durften zwar bei der Realisierung nicht mitreden, aber müssen jetzt deren Designentscheidungen ausbaden“. Mitarbeitermotivation geht anders.

Sondereinsatzkommando für Softwarefehler

Um diese Schwierigkeiten anzugehen, habe ich als Scrum Master in einem Projekt ein etwas anderes Vorgehen angewandt, das sich dort gut bewährt hat. Das Team wurde hier in zwei Mini-Teams geteilt: Ein Teil der Entwickler kümmert sich um den laufenden Support. Dieser Teil des Teams wurde von uns spaßeshalber SWAT Team (Special Weapons and Tactics) getauft, inspiriert von den Sondereinsatzkommandos bei der Polizei. Die Entwickler im SWAT-Team sind dafür zuständig, schnell zuzuschlagen, falls eine Störung im Produktivbetrieb auftaucht. Die anderen Entwickler kümmern sich um die Implementierung neuer Features.

Waffen kommen trotz des militärisch klingenden Namens im SWAT-Team nicht zum Einsatz – mit Ausnahme natürlich des Debuggers, Logviewers und anderer Hilfsmittel bei der Fehlersuche. Das SWAT-Team besteht je nach Projektgröße aus mindestens zwei Entwicklern. Ein Entwickler ist primärer Ansprechpartner für die Anwender bzw. den First-Level-Support, der zweite Kollege steht als Backup und Reviewer bereit. Die Kollegen, die nicht zum SWAT-Team gehören, stehen für ungeplante Anfragen und Routinetätigkeiten nur in Ausnahmefällen zur Verfügung. Zum Beispiel wenn ein Entwickler krank wird oder es zu kritischen Fehlern im Live-System kommt, bei denen die Hilfe der Kollegen gebraucht wird.

Falls es in einem Sprint nicht so viele Anfragen für das SWAT-Team gibt, sollte es auf einen Reservepool von Aufgaben zugreifen können. Deshalb sollte der Product Owner dafür sorgen, dass das Product Backlog immer etwas mehr Items enthält, als in einen Sprint passen.

Mehr Motivation durch Rotation

Und damit keine Zwei-Klassen-Gesellschaft im Team entsteht, wechseln nach jedem zweiwöchigen Sprint die Mitglieder des SWAT-Teams. Der erste SWAT-Ansprechpartner widmet sich wieder der Featureentwicklung und der zweite Kollege wird zum ersten Ansprechpartner. Ein Kollege aus der Featureentwicklung rückt als Backup nach.

Das hat zum einen den Vorteil, dass das Wissen über neue Features und Probleme im Tagesbetrieb gleichmäßiger über das Team verteilt wird. Wissensinseln, die es in den meisten Softwareentwicklungsteams gibt, werden so langsam aufgelöst. Somit dient das SWAT-Team-System auch dem Risikomanagement, da mit der Zeit der Ausfall von Kollegen leichter kompensiert werden kann.

Zum anderen fördert es die Motivation im Team. Ich habe die Erfahrung gemacht, dass die meisten Entwickler lieber in Ruhe neue Features entwickeln und den Tagesbetrieb oft als notwendiges Übel sehen. Da erscheint es den Teammitgliedern gerechter, wenn die als eher unangenehm wahrgenommene Aufgabe in regelmäßigen Abständen rotiert.

Und auch die Einarbeitung neuer Kollegen kann durch die Aufgabenrotation leichter gelingen. Idealerweise setzt man dazu das SWAT-Team so zusammen, dass erfahrene Entwickler zusammen mit weniger erfahrenen Entwicklern arbeiten.

Fazit

Die Frage, wie sich Softwarebetrieb und die Weiterentwicklung der Software harmonisieren lassen, müssen irgendwann alle Entwicklungsteams für sich beantworten. Sogenannte SWAT-Teams, bei denen ein Teil des Teams jeweils im Sprintrhythmus rotierend für den Support zuständig ist, können ein Ansatz sein, um beides besser in Einklang zu bringen. Hiervon profitieren auch Nutzer und Kunden. Für ihre Belange gibt es einen jederzeit verfügbaren und für die Sprintdauer festen Ansprechpartner, der sich in Ruhe um ihre Anliegen kümmern kann. Und auch die Qualität der parallel fertiggestellten Features wird durch die konzentrierte und unterbrechungsarme Arbeit daran in den meisten Fällen höher sein.

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Informationen zu Kathrin Herrmann finden Sie unter http://www.kathrin-herrmann.net.

Dies ist ein Best of Blog 2018 Beitrag. Hier können Sie sich die besten Beiträge aus 2018 herunterladen.

Kathrin Herrmann hat im t2informatik Blog weitere Beiträge veröffentlicht, u.a.

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.