Funktioniert Agile auch im IT-Helpdesk? Teil 1: Die 6 Fokuspunkte fürs Team

Vor einem Jahr startete ich mit meinem neuen Team durch. Der Hauptaufgabenbereich: „IT-Anwender-Support“ – die direkten IT-Probleme der internen Anwender:innen aufnehmen, lösen und im Hintergrund Verbesserungen umsetzen. Eines ist klar: User-zentrierter als in diesem Team wird es nicht mehr. Der Kontakt zu den Usern steuert dieses Team zu 80 %. Bei über 60.000 „Kund:innen“, die jeden Tag auf das Funktionieren der technischen Systeme angewiesen sind, ist das ein Knochenjob – wenn etwas nicht reibungslos funktioniert. Das Team ist crossfunktional aufgestellt: IT-Expert:innen, technische Umsetzer:innen, Servicedesk-Koordinator:innen, Prozess-Expert:innen und Wissensmanager:innen. Mit der folgenden Mission sind wir in das Experiment „Geht IT-Helpdesk auch agil?“ gestartet:

“Wir, der IT-Helpdesk, und unsere Kund:innen sind ein Dream-Team: Die gemeinsame Zeit mit dir als Kund:in ist möglichst ‚Quality Time‘. Mit deinen Anforderungen verbessern wir proaktiv unseren Service, unsere Prozesse und dein Nutzungserlebnis!“

Wenn auch ihr überlegt, ob Agilität in euer IT-Helpdesk-Team passt, dann lege ich euch diese Punkte ans Herz.

1. Lernt zu unterscheiden zwischen Service Design, Service Fulfillment und Service Support

In welchem dieser Wirkungskreise seid ihr (gerade) unterwegs? Unter Service Design fallen die konzeptionellen Verbesserungen der Services. Umstände können sich verändern, Formulare werden angepasst, Systeme umgestellt. Macht diese Anpassungen und Verbesserungen als Lieferungen transparent! Nur so profitiert die ganze Organisation davon und kann das ggf. in den eigenen Systemen wieder weiter anpassen.

Unter Service Fulfillment fallen Tätigkeiten, die notwendig sind, um den Service aufrecht zu erhalten. Diese kehren in bestimmten zeitlichen Abständen wieder und sind wichtig und meist dringlich. Mit Service Support werden die Anfragen zur Lösung dringlicher Einzelfragen von Usern bezeichnet. Lest zu den drei Wirkungskreisen gerne auch in Robert Siebers Whitepaper.

2. Schafft mit einem klaren Arbeitsmodell Transparenz – überall

Die gängigen Ticketsysteme decken vor allem eins ab: die Probleme der User. Für andere, generelle Arbeitspakete, wie die Verbesserung eines Formulars, gibt es kaum Platz. Integriert eure Systeme in einem abgestimmten Arbeitsmodell und versucht dabei die unterschiedlichen Ebenen eurer Arbeit – Probleme der User, Operatives, Strategisches – in einen Dreiklang zu bekommen.

Ich habe gute Erfahrungen damit gemacht, die Ebenen zu trennen: Service Design in Epics und User Storys zu planen (z. B. das Epic „Knowledge Management Tool Migration“), Service Fulfillment in einem Kanban-Modus kurz und knapp transparent zu machen und umzusetzen (z. B. eine Kundenreklamation zur Arbeitsweise des IT-Helpdesks) und die tatsächlichen Tickets der Agent:innen und Kund:innen in einem Ticketsystem abzubilden. Egal, wie ihr es macht, wichtig ist das Ziel: Macht eure Arbeit sichtbar.

3. Sorgt für Rollenklarheit und damit für beständige Verbesserung

In einer Service-Einheit geht es fast immer ums Feuerlöschen. Die Leidenschaft im Team gilt den Problemen der und Lösungen für die Nutzer:innen. In meinem Team lag der Fokus oft auf den kurzfristigen Lösungen. Für langfristige oder mittelfristige Verbesserungen blieben häufig keine Zeit und Kraft mehr.

Nutzt die Rollen, Artefakte und Meetings eines agilen Teams: die Visionskraft und den Weitblick eines Product Owners, der das ganze Produkt im Blick hat und für Transparenz und Aufmerksamkeit in der Organisation sorgt; das Prozessauge des ScrumMasters, der Hindernisse sichtbar macht und für die Zusammenarbeit sorgt, die euch produktiver macht. Erlebt, wie ihr euren Zusammenarbeitsmodus Stück für Stück verbessert. Last, but not least: das crossfunktionale Team mit den notwendigen Skills, Entscheidungsbefugnissen und Wissen, das die Services liefert.

4. Findet eure ideale Iterationslänge

Nach der Stacey-Matrix ist es gute Praxis, die Iterationen (Sprint-Längen) je nach Grad des Chaos zu verlängern oder zu verkürzen. In Service-Einheiten gibt es eine große Schwankung zwischen Chaos und Routine. Daher empfehle ich, nicht zu lange Iterationen zu planen. Denn je länger die Iteration, desto ungenauer wird die Planung. Wir haben mit zwei Wochen gute Erfahrungen gemacht, eine Woche war zu kurz, mit drei Wochen wurde die Planung zu ungenau.

5. Spielt euer Team frei

Es ist ein intensiver Job. Denn die Pipeline läuft selten leer. Daher ist es wichtig, gerade hier immer Wert auf das eigene Wohl und auf das Miteinander zu legen. Überprüft immer wieder, was ihr tut und was ihr euch vorgenommen habt. Wo habt ihr gegebenenfalls einen Rucksack aufgebaut? Wo seid ihr mit hineingerissen worden, wo ist ein Meeting in eine Gewohnheit übergegangen? Wo ist es an der Zeit, Nein zu sagen?

6. Feiert Erfolge und reflektiert

Schnell habe ich festgestellt, dass das Motto im IT-Helpdesk ist: „Wer nicht geschimpft wird, ist gelobt genug.“ (Den Spruch kenne ich als Bayerin und Wahlwienerin gut, finde ihn aber trotzdem nicht ideal.) Lasst uns da nicht so bescheiden sein. Ich ermutige euch, das Scheinwerferlicht auf eure zahlreichen Erfolge zu werfen. Zeigt den Mehrwert, den ihr bringt. Macht euch zum wertvollen Partner der IT und eures Kunden. Und wenn etwas nicht gut läuft, schaut hin! Nutzt die Retrospektive!

Was kommt als Nächstes?

Diese sechs Punkte haben mir dabei geholfen, mit meinem Team gemeinsam einen Weg zu finden, um agile Elemente in den Arbeitsalltag aufzunehmen. Dadurch haben wir eine gemeinsame Sprache entwickelt und Transparenz für das gesamte Team hergestellt. Wir haben Rollen und ein Zusammenarbeitsmodell etabliert, die dem Team halfen, effektiv zusammenzuarbeiten. Durch die neue Fokussierung konnten wir bald Erfolge feiern!

Das war der erste von zwei Teilen zum agilen Arbeiten im IT-Helpdesk-Team. Im zweiten Teil zeige ich euch, wie das Zusammenspiel mit der Organisation über die Teamgrenzen hinaus funktionieren kann.

Teil 2: Zusammenspiel mit der IT-Organisation