Agile Arbeitsweisen bringen Dynamik in den IT-Alltag – aber was passiert, wenn sie auf den Anspruch eines stabilen Betriebs treffen? Ich zeige, wo agile Entwicklung und stabiler ICT-Betrieb aufeinandertreffen, wie sich Spannungen im Alltag zeigen und welche Rolle Führung und Kultur dabei spielen.
Wenn agile Entwicklung auf stabilen Betrieb trifft
In einem agil organisierten Softwareunternehmen kommt es beim Einsatz von Frameworks wie Scrum immer wieder zu Herausforderungen bei der Sicherstellung eines stabilen und sicheren ICT-Betriebs – besonders zwischen den Teams, die an der Wertschöpfung beteiligt sind, und jenen, die den operativen Betrieb gewährleisten.
Unterschiedliche Schwerpunkte, parallele Projekte und Ressourcenplanung führen zu Spannungen. Subjektiv als dringend markierte Anfragen – intern wie extern – unterbrechen laufende Arbeiten. Besonders in Hochphasen, wenn mehrere Bereiche gleichzeitig betroffen sind, geraten Service-Teams schnell unter Druck.
Ständige Prioritätsänderungen erzeugen Multitasking und Neuplanungen, manchmal bis hin zur Streichung geplanter Aufgaben. Hinzu kommt die Vielzahl technischer Kommunikationskanäle, die oft unkoordiniert genutzt werden und Dringlichkeiten verzerren.
Die Einführung agiler Arbeitsweisen verändert auch im ICT-Service die Sicht auf Aufgaben. Die Einplanung von Projekten, Lifecycle-Management, Sicherheitsvorfällen und Serviceanfragen in zeitlich definierte Sprints schafft Struktur – stösst bei unvorhergesehenen Ereignissen jedoch schnell an Grenzen.
Herausforderung: Zwei Prinzipien, zwei Geschwindigkeiten
Wenn agile Prinzipien auf klassische Serviceprozesse wie Incident-, Change- oder Request-Management treffen, prallen zwei Logiken aufeinander. Neue Vorfälle können einen geplanten Sprint rasch sprengen.
Mitarbeitende stehen dann zwischen einem fixen Sprintplan und plötzlich auftauchenden dringenden Aufträgen. Wird der Plan durch Neupriorisierung unterbrochen, entsteht Frustration – auch wenn die Arbeit objektiv gut war.
Zusätzlich führen unterschiedliche Erwartungshaltungen zwischen Entwicklung, Service und Management dazu, dass vermeintlich kleine Aufgaben unterschätzt werden, obwohl sie entscheidend für den stabilen Betrieb sind.
Praxisbeispiel: Wenn ein Release den Betrieb ausbremst
Im Unternehmen, indem ich Tätig bin, bieten wir im Bereich Hosting einen Full-Managed-Service an, der regelmässige Software-Deployments umfasst. Diese werden ausserhalb der Geschäftszeiten durchgeführt und in der Sprintplanung berücksichtigt.
Ein Release enthielt Fehler, die wichtige Betriebsabläufe der Kunden beeinträchtigten. Nach der Fehlerbehebung musste das korrigierte Release schnellstmöglich eingespielt werden. Während das Entwicklerteam unter Hochdruck arbeitete, drohte im Hosting ein SLA-Bruch. Nur durch ein ausserplanmässiges, flexibles Deployment konnte die Situation entschärft werden.
Das zeigt, wie unberechenbar Störungen im stabilen Betrieb auftreten und wie schwer sie sich mit fixen Sprints vereinbaren lassen.
Um flexibel zu bleiben, plane ich in Sprints mit Deploymentanforderungen bewusst Zeitpuffer ein. Regelmässige Abstimmungen mit dem Entwicklungsteam helfen, mögliche Probleme früh zu erkennen. Entscheidend ist das konsequente Priorisieren, wenn kritische Vorfälle auftreten.
Führung & Kultur: Balance durch Vertrauen
Im agilen Umfeld wirken viele Faktoren gleichzeitig auf den ICT-Service. Ein regelmässiger Austausch über aktuelle Vorfälle und Abhängigkeiten hilft, Struktur zu schaffen und Aufgaben sinnvoll zu priorisieren.
Mir ist wichtig, dass Mitarbeitende den Überblick über ihre Aufträge behalten und eigenständig vorgehen. In regelmässigen Gesprächen klären wir Status und Hindernisse, um Aufgaben abgestimmt zu lösen.
Vertrauen und Entscheidungsspielräume fördern Eigenständigkeit. Mein Ziel ist, das Team in einen Performance-Modus zu bringen – mit effizienten Planungen und mehr Selbstorganisation.
Zusammenarbeit & Kommunikation: Schnittstellen schärfen
In der bereichsübergreifenden Zusammenarbeit sehe ich weiterhin Verbesserungspotenzial. Auch wenn der Austausch grundsätzlich funktioniert, fehlen bei kritischen Vorfällen oft klar definierte Prozesse, Verantwortlichkeiten und Kommunikationswege. Das führt zu reaktivem statt proaktivem Handeln. Rollen, Abläufe und Übergabepunkte sollten klar geregelt und transparent sein. Gemeinsame Zeitpläne und ein abgestimmtes Verständnis fördern Effizienz und Vertrauen. Eine klare Sicht auf Dienstleistungen und Prozesse stärkt die Zusammenarbeit und trägt zu einer kundenorientierten Wertschöpfung bei.
Erkenntnis: Agilität braucht Struktur
Einen stabilen IT-Betrieb unter Nutzung agiler Frameworks aufrechtzuerhalten ist anspruchsvoll, aber machbar. Es ist ein Balanceakt zwischen geplanter Arbeit und reaktiver Bewältigung von Vorfällen. Gerade im ICT-Service – aber auch in Bereichen wie HR oder Finanzen – ist die reine Agilität nicht immer die beste Lösung. Eine Kombination aus Agilität, Service-Frameworks (z. B. ITIL) und klassischem Projektmanagement kann sinnvoller sein. Ein Serviceprozess sollte Aktivitäten, Verantwortlichkeiten und Kennzahlen klar definieren und technisch unterstützt verarbeitet werden – so bleibt der Betrieb agil, ohne an Stabilität zu verlieren.
Ausblick: Agile Stabilität als Ziel
Ich möchte den ICT-Service stärker an ITIL-Prinzipien anlehnen und innerhalb meiner Organisation einen geschäftsprozessorientierten Servicekatalog aufbauen. Durch die Klassifizierung von Services und die Festlegung von Kennzahlen soll der Wertbeitrag sichtbarer werden. Ich bin überzeugt, dass der ICT-Service von einer gewissen Unabhängigkeit gegenüber Sprints profitiert. Eine „agile Stabilität“ – also die Verbindung von Struktur und Anpassungsfähigkeit – kann zu mehr Effizienz, klareren Verantwortlichkeiten und zufriedeneren Kunden führen.
Take away
Agilität und Stabilität müssen sich nicht widersprechen.
Mit klaren Prozessen, offener Kommunikation und Vertrauen im Team kann ein ICT-Service flexibel bleiben – und trotzdem verlässlich performen.
