Wie ITIL die Leistungen von Scrum-Teams verbessert

Passen ITIL und Scrum zusammen? In vielen Unternehmen steigt der Druck, schneller mit neuen IT-Produkten an den Markt zu gehen. Scrum ist dabei das populärste Framework, mit dem Teams neue Produkte entwickeln. Geld wird aber erst verdient, wenn neue Produkte in Betrieb gehen. Und da kommt ITIL ins Spiel.

Viele Teams, die mit Scrum neue Produkte entwickeln, müssen diese Dienste anschließend in Betrieb nehmen und betreuen. Selten gibt es ganz klar abgetrennte Bereiche für Entwicklung und IT Operations. Das bedeutet, dass, wenn ein Fehler auftritt, ein Entwickler seine eigentliche Arbeit ruhen lässt und sich zunächst der Störung widmet. Schwierig wird es, wenn der Entwickler nur noch mit Störungsbearbeitung beschäftigt ist und nicht mehr an seinem neuen Produkt arbeitet. Bei Scrum sagen wir, dass in solch einem Fall das sog. Sprintziel in Gefahr ist.

 

Bei unseren Beratungen ist das eine häufige Frage von den Scrum-Teams: Wie gehen wir mit Störungen um?

 

Es gibt im Wesentlichen zwei Gründe für Störungen:

  • Technische Schulden (engl. technical debt) und
  • Technische Änderungen (engl. changes)

 

Gegen technische Schulden muss das Team eine eigene Strategie entwickeln, damit die Qualität der Software und Architektur besser wird.

 

Erfahrungsgemäß sind meist technische Änderungen die Ursache für Ausfälle. Dies bekommt man durch ITIL Change Management in den Griff. (Für mich ist Change Management die wichtigste Disziplin in ITIL. Alle anderen Prozesse gruppieren sich darum herum.)

 

So wie Scrum Rollen und Abläufe für die Entwicklung definiert, tut ITIL dies für Betriebsprozesse. Bei Scrum-Trainings glauben Teams nicht an Leistungsverbesserungen durch das Einhalten der Scrum-Regeln. Erst wenn ich ihnen in den Übungen zeige, wie sie sich verbessert haben, verstehen sie es.

 

Ähnlich ist es auch mit ITIL. Teams glauben nicht, dass sie sich verbessern. Der Nachweis ist aber ganz einfach. Ein Team muss nur festhalten, wie oft etwas pro Woche ausfällt (MTBF) und wie lange die Reparatur dauert (MTTR). Change Management erhöht die MTBF; Change Management verkürzt die MTTR von einigen Tagen auf wenige Minuten.

 

Wenn ein Scrum-Team vor allem von seiner Entwicklungsarbeit abgehalten wird, weil es viele technische Änderungen gibt, sollte es den Umgang mit Changes regeln. Dieser umfasst folgende Punkte:

  • Grundsätzlich haben sich alle an den vereinbarten Change-Prozess zu halten. Alle wichtigen Komponenten und Konfigurationen werden zusätzlich automatisch auf Änderungen geprüft.
  • Es wird ein Change Advisory Board eingerichtet, dass über bisher nicht durchgeführte Changes berät und für häufige Änderungen Standards definiert. Standard-Changes werden verskriptet und können so automatisch verteilt UND zurückgerollt werden.
  • Die freiwerdende Zeit wird dazu genutzt, Fehlerquellen in der Infrastruktur aktiv abzuschalten. Dies dient auch dem Abbau technischer Schulden.
  • Das Team führt Buch über die Changes, MTBF und MTTR, damit es sieht, ob und wie es sich verbessert. Es reserviert sich wie bei Scrum regelmäßig Zeitfenster, um über Verbesserungen zu sprechen.

Diese Massnahmen führen schon in vier Wochen zu deutlich spürbaren Verbesserungen.

 

Scrum-Teams können das Change Management verbessern, indem sie für ihre eigenen Produkte das Ausrollen und Zurückrollen automatisieren. Sie können auch anderen Teams, die ebenfalls Komponenten für die gemeinsame Infrastruktur liefern, dabei helfen.

 

Die Prinzipien von ITIL und Scrum helfen auch bei der Entscheidung, wie viel Zeit ein Entwickler in das Fixen von Bugs stecken darf. Es gilt nämlich auch hier das Prinzip der Wirtschaftlichkeit. Nicht jeder Bug muss gefixt werden. So wie ein Product Owner bei Scrum entscheidet, welche Anforderungen umgesetzt werden, so entscheidet auch der Change Manager in Abstimmung mit dem Business, welche Changes angegangen werden.

 

ITIL verbessert die Leistungen von agilen Teams, die auch Verantwortung für den Betrieb ihrer Produkte tragen. Durch einen geregelten Umgang mit Änderungen treten weniger Fehler auf. Auch durch das Festlegen von Zeitfenstern für Bugfixing wird sichergestellt, dass genügend Zeit für das Erreichen der Sprintziele bleibt.

 

—Jan Fischbach

 

Jan Fischbach ist Organisationsberater für IT- und Dienstleistungsorganisationen. Seine Schwerpunkte sind Verträge im IT-Bereich (keine Rechtsberatung), Pricing für IT-Leistungen, Projektvorbereitung (PRINCE2, Scrum, Scaled Agile Framework) und Dokumentation. Er ist Mitgründer und Geschäftsführer der Common Sense Team GmbH und arbeitet seit 2009 mit der expertplace advisory GmbH zusammen. Er ist ebenfalls Chefredakteur des Teamwork-Blogs, ein führendes Blog zum Thema Zusammenarbeit und Produktivität im Team.

 

Kommentar schreiben

Kommentare: 1
  • #1

    Tim440 (Dienstag, 15 Juli 2014 15:53)

    Danke, Jan. ITIL braucht muttersprachliche Griffigkeiten, um seinen eigenen ersten Leitsätzen treu zu bleiben. my 2c -tim

Abonnieren Sie

http://www.itil.de/rss/blog

unseren Blog itil.de

Unsere Mission

Wir leisten einen Beitrag zu besserem IT Service Management durch die pragmatische Auseinander-setzung mit ITIL und verwandten Themen.

Werbung

Wollen Sie ITIL-Experte werden? Dann lassen Sie sich zertifizieren bei

expertplace academy
expertplace academy
ITSM Consulting
ITSM Consulting