Mit diesem Beitrag zeigen wir auf, wie Sie Prozesse des IT Service Managements (ITSM) im Umfeld der IT Infrastructure Library (ITIL) agil mit Hilfe des Scrum-Prozesses umsetzen können. ITIL ist eine Sammlung von Best Practices, die den Service-Lebenszyklus (Strategy, Design, Transition, Operation und Continual Service Improvement) in der IT abbildet und dabei den Mehrwert für den Kunden optimiert. Scrum ist ein anpassungsfähiger, iterativer Prozess, mit der Sie Projekte innerhalb und ausserhalb Ihrer IT-Landschaft managen.
Das Vorgehen bei klassischen ITSM-Projekten, etwa nach der Wasserfall-Methode, präsentiert sich zumeist streng sequenziell: a) Aufnahme der Anforderungen, b) Design, c) Umsetzung, d) Verifizierung und e) Wartung. Dabei fallen die Anforderungsanalyse und das Design der Lösung sehr detailliert und zeitaufwendig aus.
Da die Wasserfall-Methode eben nicht iterativ ist, soll bereits die Erstumsetzung den Kundenwunsch möglichst genau widerspiegeln. Das Design muss für den Kunden klar und für das Umsetzungsteam präzise formuliert sein, um Missverständnisse möglichst auszuschliessen. Darin liegt denn auch einer der grössten Vorteile des agilen Projektmanagements: Sofern sich die Gesamtlösung in kleinere, unabhängig einführbare Pakete zerlegen lässt oder bereits aus solchen besteht, können Sie diese in kurzer Zeit nah an den Bedürfnissen Ihrer Stakeholder entwerfen, entwickeln, liefern und – falls nötig – ebenso schnell korrigieren, ohne dass Sie den nächsten Releasezyklus in ferner Zukunft abwarten müssen.
Ziele und Anwendung von Scrum
Ziel des Scrum-Prozesses ist es, mit einem möglichst übersichtlichen Regelwerk komplexe Anforderungen flexibel und ohne grossen organisatorischen Überbau zu realisieren. Sie organisieren Scrum am besten wie folgt:
- Eigenständiges Team mit den erforderlichen Kompetenzen:
- Product Owner als «Stimme des Kunden»
- Scrum Master als Koordinator, Unterstützer und Berater
- Entwicklungsteam mit interdisziplinärenFähigkeiten
- Selbstorganisation des Scrum-Teams in eigenständigen, kurzen Umsetzungszyklen («Sprints»), um regelmässig fertige Funktionalitäten zu liefern
- Erzeugung von Transparenz nach innen und aussen (gegenüber dem Kunden), um sowohl das Resultat als auch den Entwicklungsprozess anzupassen
Der Scrum-Prozess wird gerne bei der Entwicklung komplexer Systeme angewendet. Dabei kennen alle Beteiligten das übergeordnete Ziel. Allerdings ist die Umsetzung häufig zu komplex, um bei Projektstart in einer einzigen Spezifikations- und Designphase für eine möglichste eigenständige Entwicklung die Anforderungen zu klären oder für die Entwickler ausreichend detailliert zu beschreiben.
Daher wird bei solchen Projekten die Umsetzung in voneinander unabhängige Themenblöcke aufgeteilt (beispielsweise GUI, Businessprozesse, Schnittstellen usw.) und die Anforderungen für die Umsetzung werden in kleine Pakete zerlegt. In einem zweiten Schritt nehmen Sie einige der Anforderungen auf, halten sie in Form von User Stories fest und setzen sie in einer ersten Iteration um. Es folgen so viele Iterationen wie nötig, um die Kundenwünsche zu erfüllen.
Neben derart umfangreichen Grossprojekten können Sie mit dem Scrum-Ansatz viele kleine Änderungswünsche oder Verbesserungsvorschläge verwirklichen. Solche treten gerade im ITSM-Bereich sehr häufig auf. Hier eignet sich die Scrum-Methode besonders, um die Optimierungsvorschläge Ihrer Benutzer schnell und effizient umzusetzen und so Ihre Services laufend zu verbessern.
Scrum im ITIL-Umfeld
Der Scrum-Ansatz lässt sich hervorragend in den Service-Lebenszyklus integrieren, da Sie ihn beispielsweise während dem Service Design und der Service Transition einsetzen können. Zudem betrifft er das Continual Process/Service Improvement durch die erwähnten Iterationen der Implementierungen. Im Folgenden konzentrieren wir uns auf das Service Design und die Service Transition.
1. Service Design
Beim Betrieb von ITIL-basierten ITSM-Lösungen äussern Businessvertreter, Prozessverantwortliche oder Benutzer neue Anforderungen oder Verbesserungsvorschläge. Diese werden in Form von User Stories aufgenommen und in einem sogenannten Projekt-Backlog gesammelt. Solche User Stories sind häufig in der Sprache der (End-)Benutzer oder der Anspruchsgruppen formuliert. Dazu drei Beispiele:
- «Als Hotline-Mitarbeiter möchte ich den Anrufer durch Eingabe dessen Telefonnummer gerne identifizieren können.»
- «Als Prozessverantwortlicher für das Change Management möchte ich einen Prozess abbilden, über den jede kritische Änderung eine ausserordentliche Approval-Prozedur durchlaufen muss.»
- «Als Verantwortlicher für das Service Request Management möchte ich, dass der Endbenutzer alle Service Requests auch per Mobiltelefon beauftragen kann.»
Der Product Owner hat die Aufgabe, die Wirtschaftlichkeit der User Stories festzustellen und diese im Backlog zu priorisieren. Er dient zudem als Vermittler gegenüber den übrigen Stakeholdern im Unternehmen und stellt sicher, dass deren Wünsche und Interessen abgewogen werden. Erfahrungsgemäss kann es durchaus Sinn machen, die Rollen des Service Owners und des Product Owners in einer Person zu vereinen, da Sie so die Erfahrungen und Anforderungswünsche innerhalb des Unternehmens hocheffizient abbilden.
Jeder Sprint startet mit einem Sprint-Planungsmeeting. Dabei arbeitet sich das gesamte Team durch die vom Product Owner festgelegte Reihenfolge des Backlogs und verschafft sich ein gemeinsames Verständnis der User Stories. Zudem legt es die Akzeptanzkriterien fest, mit denen am Ende des Sprints der Erfolg der Umsetzung gemessen wird («Definition of Done»). Im Rahmen dieses Planungsmeetings findet ebenfalls eine grobe Abschätzung der Komplexität jeder Anforderung oder User Story in Form von Story Points statt. Diese geben Aufschluss darüber, wie viele User Stories im Umfang des nächsten Sprints bearbeitet werden können. Nachdem das Scrum-Team den Umfang des Sprints festgelegt hat, erarbeitet es im zweiten Teil der Planung die eigentliche Entwicklung – also wie und in welchen Arbeitsschritten eine User Story abgearbeitet wird. Daraus entstehen die Entwicklungsaufgaben («Tasks»), die im Sprint Backlog aufgeführt sind und durch die übergreifenden User Stories ergänzt werden. Der tägliche Fortschritt wird in Daily-Scrum-Treffen jeweils am Morgen dokumentiert. So erkennt das Entwicklerteam frühzeitig Probleme, die es anschliessend mit dem Scrum Master oder dem Product Owner diskutieren kann.
Während der Design-Phase ist die operative Sicht absolut zentral. Es besteht die Gefahr, bei agilen ITSM-Projekten Gewährleistungskriterien wie Kapazität, Sicherheit oder Verfügbarkeit eines Services nicht oder zu wenig zu berücksichtigen. Der Scrum-Ansatz bietet Ihnen dafür attraktive Lösungen, die Sie teilweise in die Planungsphase des Sprints übernehmen können oder zumindest bei der Ausformulierung der User Stories berücksichtigen sollten.
2. Service Transition
Die technische Umsetzung der Arbeitsschritte einer User Story erfolgt in den Sprints, die meist auf etwa drei bis vier Wochen begrenzt sind. Für das Gelingen eines Sprints ist es unerheblich, ob das Entwicklungsteam nach Beendigung des Sprints ein einziges gemeinsames Ziel oder mehrere individuelle Ziele erreichen will.
Der Scrum Master überwacht die Umsetzung der Anforderungen und ist für den Erfolg der Sprints verantwortlich. Er überwacht zudem die Einhaltung des Regelwerks, das sich das Scrum-Team auferlegt hat. Bei Konflikten innerhalb des Entwicklungsteams oder in der Zusammenarbeit mit dem Product Owner agiert der Scrum Master als Vermittler und begleitet das Team über sämtliche Arbeitsabschnitte hinweg.
Der Scrum-Prozess im IT-Servicemanagement steht und fällt mit der interdisziplinären Besetzung des Entwicklerteams. Bestenfalls kann jedes Teammitglied unterschiedliche Aufgaben wie beispielsweise Architekt, Entwickler oder Tester wahrnehmen. Damit stellen Sie den gegenseitigen Austausch und die Unterstützung innerhalb des Teams sicher und gewähren höchste Flexibilität in der Umsetzung.
Äusserst wertvoll ist die lückenlose Transparenz innerhalb der gesamten Umsetzung. Mit geeigneten Tools wie JIRA erhalten Sie eine Live-Übersicht über die pendenten, aktiven und erledigten Tasks innerhalb des Sprint Backlogs. So sind Beteiligte und Anspruchsgruppen stets über den aktuellen Status des Sprints im Bild.
Gegen Ende eines Sprints nimmt das Scrum-Team am Sprint Review teil. Hier werden die Ergebnisse des Entwicklungszyklus vorgestellt und beurteilt. Dazu sollten Sie unbedingt auch die Benutzer hinzuziehen. Diese liefern Ihnen wertvolle Inputs zur Implementierung und darüber, ob diese – trotz möglicherweise erfüllter Abnahmekriterien – entweder nicht sinnvoll eingeführt werden können oder für den nächsten Sprint weiter iteriert werden müssten. Der Product Owner entscheidet schliesslich, welche User Story eingeführt oder zurück in den Backlog gestellt wird.
Am Ende des Sprints nimmt das Scrum-Team in der Retrospektive die Arbeit(sweise) während des Sprints kritisch unter die Lupe. Es spricht offen über alle positiven und negativen Punkte und dokumentiert diese, damit sich die Folgeiterationen verbessern lassen. Zur gleichen Zeit findet das Planungsmeeting des nächsten Sprints statt. Dazu legt der Product Owner vorher wiederum die Prioritäten für den nächsten Sprint fest und präsentiert sie dem Scrum-Team zur Besprechung.
Dank schnellerer Implementierungsgeschwindigkeiten und kürzerer Entwicklungszyklen eignet sich die Scrum-Methode im Weiteren, aus Erkenntnissen während der Sprints gewisse Abläufe im Unternehmen zu hinterfragen und ins Register des Continual Service Improvements (CSI) aufzunehmen. Dazu empfehlen wir einen regelmässigen Austausch zwischen Scrum Master und CSI-Manager. Davon würde auch das Change Advisory Board (CAB) profitieren. Denn diesem können Sie Inhalte und Verbesserungen so stets transparent darlegen.
Scrum und ITIL gehen Hand in Hand
Dieser Beitrag erläutert, wie Sie ITIL und Scrum in Einklang bringen. Sowohl gross angelegte Projekte als auch kleine Änderungswünsche können Sie mit der agilen Projektmethode gezielt abbilden und rasch zum Vorteil Ihrer Kunden umsetzen.
