Agile-Leitfaden · Agile jenseits von Software
Agile im IT-Betrieb: wie Ops-Teams Agile und DevOps anwenden
Agile im IT-Betrieb bedeutet, agile Werte und Praktiken wie sichtbare Arbeit, kurze Feedbackschleifen und kontinuierliche Verbesserung auf die Teams anzuwenden, die Infrastruktur, Netzwerke, Servicedesks und Produktionssysteme betreiben. Da Betriebsarbeit geplante Projekte mit ungeplanten Störungen mischt, bevorzugen Betriebsteams oft Kanban und eine enge Zusammenarbeit mit der Entwicklung über DevOps.
Das Wichtigste in Kürze
- Betriebsteams wenden Agile an, indem sie alle Arbeit sichtbar machen und Unterbrechungen einplanen.
- Kanban mit Serviceklassen und WIP-Limits passt meist besser zum Betrieb als strikte Sprints.
- Reservieren Sie Kapazität für ungeplante Arbeit und investieren Sie stetig in Automatisierung.
- Enge Zusammenarbeit mit der Entwicklung durch DevOps vervielfacht den Nutzen.
Warum der Betrieb anders ist
Entwicklungsteams können einen Sprint meist planen und schützen. Betriebsteams sind einem stetigen Strom von Unterbrechungen ausgesetzt: Störungen, Serviceanfragen, Sicherheitspatches und dringende Änderungen. Eine strikte Sprint-Zusage scheitert oft innerhalb weniger Tage. Agile hilft trotzdem, doch die Praktiken müssen angepasst werden.
| Arbeitsart | Beispiel | Typischer Ansatz |
|---|---|---|
| Ungeplant | Ausfall, Sicherheitswarnung, dringender Fix | Sofortige Bearbeitung über eine Expedite-Spur |
| Routineanfragen | Neue Benutzerkonten, Zugriffsänderungen | Wo möglich standardisiert und automatisiert; Fluss über ein Board |
| Geplante Verbesserung | Datenbankcluster aktualisieren, Backups automatisieren | In kleine Einträge zerlegt und in einem Backlog priorisiert |
| Wartung | Patches, Zertifikatserneuerungen | Als wiederkehrende Arbeit mit reservierter Kapazität eingeplant |
Agile Praktiken, die für Betriebsteams funktionieren
- Kanban-Boards mit WIP-Limits: Visualisieren Sie alle Arbeitsarten und begrenzen Sie, wie viel gleichzeitig in Arbeit ist; siehe WIP-Limits.
- Serviceklassen: eine Expedite-Spur für Störungen, eine Spur für feste Termine und eine Standardspur für alles andere; siehe Kanban-Swimlanes.
- Reservierte Kapazität: Halten Sie einen Teil der Kapazität, zum Beispiel 30–40 %, für ungeplante Arbeit frei, basierend auf Ihren eigenen Erfahrungswerten.
- Kurze tägliche Stand-ups am Board: Konzentrieren Sie sich auf blockierte und alternde Einträge.
- Regelmäßige Retrospektiven und Post-Incident-Reviews: schuldfreie Reviews, die zu konkreten Verbesserungen führen.
- Automatisierung als Backlog-Arbeit: Behandeln Sie die Automatisierung wiederkehrender Aufgaben als geplante Verbesserungseinträge.
- Gemeinsame Verantwortung mit der Entwicklung: gemeinsame Rufbereitschaft, gemeinsame Kennzahlen und Infrastructure as Code; siehe DevOps.
So führen Sie Agile in einem Betriebsteam ein
- Alle Arbeit sichtbar machen: Bringen Sie Störungen, Anfragen und Projekte zwei bis vier Wochen lang auf ein Board, ohne etwas anderes zu ändern.
- Die Mischung messen: Zählen Sie, wie viel Arbeit ungeplant und wie viel geplant ist.
- Serviceklassen und WIP-Limits festlegen: Vereinbaren Sie Regeln dafür, was geplante Arbeit unterbrechen darf.
- Kapazität reservieren: Halten Sie genug für die gemessene ungeplante Arbeit frei.
- Verbesserungsarbeit priorisieren: Erstellen Sie einen Backlog mit Automatisierungs- und Zuverlässigkeitseinträgen mit klarer Verantwortung.
- Eine Kadenz einführen: Ein wöchentliches Replenishment-Meeting und eine zweiwöchentliche Retrospektive sind ein guter Anfang; siehe Kanban-Meetings.
- Kennzahlen monatlich prüfen: Betrachten Sie Durchlaufzeit, Durchsatz und Störungstrends und passen Sie dann an.
Rechenbeispiel
Ein sechsköpfiges Infrastrukturteam erfasst vier Wochen lang seine Arbeit und stellt fest, dass 45 % der erledigten Einträge ungeplant waren. Es reserviert etwa die Hälfte seiner Kapazität für ungeplante Arbeit, führt eine Expedite-Spur mit einem Limit von einem Eintrag gleichzeitig ein und setzt ein WIP-Limit von acht für das gesamte Board. Jede Woche zieht es die wichtigsten Verbesserungseinträge aus dem Backlog. Nach zwei Monaten automatisiert das Team seine drei häufigsten Anfragen (Passwortrücksetzungen für ein Altsystem, Aufbau von Testumgebungen und Anfragen für Log-Zugriff), und der Anteil ungeplanter Arbeit sinkt auf etwa ein Drittel. Die durchschnittliche Cycle Time für Standardanfragen sinkt von acht auf vier Tage.
Kennzahlen für Agile Operations
| Kennzahl | Warum es wichtig ist |
|---|---|
| Cycle Time pro Serviceklasse | Zeigt, wie schnell jede Arbeitsart abgeschlossen wird |
| Durchsatz | Zeigt, wie viele Einträge das Team pro Woche abschließt |
| Verhältnis geplant zu ungeplant | Zeigt, ob Verbesserungsarbeit Unterbrechungen reduziert |
| Mittlere Zeit bis zur Wiederherstellung des Dienstes | Zeigt, wie schnell sich das Team von Störungen erholt |
| Change Failure Rate | Zeigt, wie oft Änderungen Probleme verursachen |
| Einhaltung der Service Levels | Zeigt, ob vereinbarte Ziele erreicht werden; siehe Service Level Agreement |
Häufige Fehler
- Einem überwiegend unterbrechungsgetriebenen Team zweiwöchige Sprint-Zusagen aufzwingen.
- Ungeplante Arbeit nicht auf dem Board erfassen, sodass das Team untätig wirkt, obwohl es ausgelastet ist.
- Nie Zeit für Verbesserungen schützen, sodass immer wieder dieselben Störungen auftreten.
- Agile und IT-Service-Management-Frameworks als Gegner betrachten; ihre Prozesse können neben agilen Arbeitsweisen bestehen.
- Entwicklung und Betrieb so strikt trennen, dass Probleme über den Zaun geworfen werden.
Kostenlose Vorlagen zu diesem Thema
Häufig gestellte Fragen
Können IT-Betriebsteams Praktiken von Agile Operations nutzen?
Ja. Sie passen sie an den Umgang mit ungeplanter Arbeit an, meist mit Kanban, reservierter Kapazität und enger Zusammenarbeit mit der Entwicklung.
Ist Scrum oder Kanban besser für agilen IT-Betrieb?
Kanban passt meist besser, weil es einen kontinuierlichen Strom von Unterbrechungen bewältigt. Teams mit überwiegend geplanter Projektarbeit können Scrum nutzen. Siehe Kanban vs. Scrum.
Wie gehen agile Betriebsteams mit Störungen um?
Über eine Expedite-Spur oder Serviceklasse, mit der dringende Arbeit die normale Warteschlange umgehen kann, mit einem strikten Limit dafür, wie viele beschleunigte Einträge gleichzeitig laufen.
Was ist der Unterschied zwischen Agile Operations und DevOps?
Agile Operations wendet agile Praktiken innerhalb von Betriebsteams an; DevOps verbindet Entwicklung und Betrieb zu einer gemeinsamen Art, Software zu entwickeln, zu releasen und zu betreiben.
Wie viel Kapazität sollten agile Betriebsteams für ungeplante Arbeit reservieren?
Orientieren Sie sich an Ihren eigenen Erfahrungswerten. Erfassen Sie mehrere Wochen Arbeit, messen Sie den ungeplanten Anteil und reservieren Sie ungefähr diese Menge.
Funktioniert agiler IT-Betrieb mit ITIL?
Ja. ITIL beschreibt Service-Management-Praktiken; Agile beschreibt, wie Teams arbeiten. Viele Organisationen nutzen beides.
Welche Kennzahlen sollte ein agiles Betriebsteam erfassen?
Cycle Time, Durchsatz, geplante gegenüber ungeplanter Arbeit, Zeit bis zur Wiederherstellung des Dienstes, Change Failure Rate und Einhaltung der Service Levels.
Brauchen agile Betriebsteams einen Product Owner?
Viele profitieren von einer Person, die Verbesserungsarbeit priorisiert und Anfragen ausbalanciert; manche nennen diese Rolle Service Owner.
Wie führen agile Betriebsteams Stand-ups durch?
Kurz, am Board, mit Fokus auf blockierte, alternde und beschleunigte Einträge statt auf individuelle Statusmeldungen.
Was ist ein schuldfreies Post-Incident-Review in Agile Operations?
Ein Review, das untersucht, wie System und Prozess eine Störung ermöglicht haben, statt wer sie verursacht hat, und Verbesserungen vereinbart.
Welche Tools eignen sich für agilen IT-Betrieb?
Tools, die Kanban-Boards, Anfrageeingang und Automatisierung unterstützen; vergleichen Sie die Optionen in unseren Projektmanagement-Tools .