Ist der Begriff „Lean und Agile ITIL“ ein Widerspruch? Nach manchen Vorstellungen ist ITIL ein Synonym für Bürokratie, also alles andere als schlank und definitiv nicht agil. Aber lasst uns diese Idee jetzt ein wenig unter die Lupe nehmen.

Zunächst eine Klarstellung der Begriffe.

Lean stammt ursprünglich aus der japanischen Fertigungsindustrie und zielt auf die Effizienz im Betrieb: Pull, Kanban, kaizen, Just-in-Time sind nur ein paar Schlüsselbegriffe.

Agile deutet eher auf sich verändernde Situationen hin, wie Projekte oder stetig wechselnde Umgebungen. Hierfür gibt es Methoden wie Agile Project Management, Xtreme Programming, Scrum usw., die auf eine hohe Team-Produktivität durch Ansätze wie Timeboxing, Team-Entscheidungen oder Daily-Standups zielt./1/

Lean Prozesse schaffen wir durch stetige Verbesserungen, am liebsten proaktiv.

Agile Ansätze dagegen bereiten bestens darauf vor, auf neue Anforderungen zu reagieren. Beide Aspekte sind heute für den Erfolg  notwendig. Was auch gilt: Die Agilität, meine Fähigkeiten, meine Prozesse anzupassen, ist genauso wichtig wie Lean Prozesse, die durch ihre Schlankheit leichter anzupassen sind.

Welche ITIL-Prozesse können von lean Ansätzen profitieren? Alles aus Service Operations, wie Incident Management, Problem Management und insb. Request Fulfillment. Die höchste Effizienzsteigerung (im Sinne von Kosten-/Aufwandsersparnissen) erfolgt jedoch im Request Fulfillment, da durch die „standard operating procedures“ (SOP) für wiederkehrende Anfragen die Anzahl von Entscheidungen und die Wartezeit reduziert werden kann.

Es geht allerdings nicht nur darum, die SOPs gut zu beschreiben, sondern auch darum, wie die Arbeit erledigt wird. Pull-Prozesse (anstelle von Push) und Kanban sorgen für Arbeitseffizienz; just-in-time für die Reduktion von Überfluss. Insbesondere sorgt das Kanban-Prinzip mit der Eingrenzung der „Work in Progress“ für eine kapazitätsgerechte Arbeitsweise, d.h. die Anzahl laufender Tasks wird reduziert, damit der Gesamtdurchsatz steigt. /2/ Denn „Durchpeitschen“ verursacht langfristig nur Stress.

Das Change Management braucht m.E. eine Mischung aus Lean und  Agile Vorgehen. Der Durchlauf des Change Requests erfolgt nach lean Prinzipien. Allerdings deutet das Umsetzen des spezifischen Change selbst auf eine projektartige Situation. Hier liegt der Fokus auf dem Team und dessen Fähigkeit, gemeinsam und schnell hochwertige Anpassungen bzw. Neuentwicklungen zu erstellen.

Spielen wir den Prozessablauf doch mal durch:

1. RFC wird eingereicht.Change Manager priorisiert und klassifiziert.
2. Change Authority genehmigt. Damit landet der Change (je nach Priorisierung etc.) im Backlog.
3. Das Entwicklungsteam (SW oder HW) kümmert sich um den Change erst dann, wenn es Luft in seinem Kanban-System hat.
4. Bei der Entwicklung wenden die Teams agile Elemente wie Timeboxing, Team-Entscheidungen, Daily-Standups an und ein Product Owner ist für die zeitgerechte aber auch anforderungsgerechte Entwicklung verantwortlich.
5. Der Release-Termin wird eingehalten. Punkt. (Wobei nach Agile Prinzipien der Scope möglicherweise kleiner ist.)

Hier haben wir eine Mischung aus Lean und Agile, welche die Effektivität jeder IT Service Management Organisation steigert. Drei Anmerkungen dazu:

• In den Schritten 1-3 empfindet man die Bürokratie hauptsächlich in schlecht aufgebauten RFC-Formularen und im Warten auf eine Entscheidung.
• Die Schwierigkeit einer Entscheidung liegt vor allem in der Ungewissheit (oder Unwissenheit). Fehlt  die notwendige Vorbereitung (Analyse, Business Case etc.), tut sich die Change Authority schwer.
• Eine Person muss den Hut für die Gesamtpriorisierung auf haben, und diese Prioritäten müssen kommuniziert werden. Sonst entwickelt sich Frustration bei denen, deren Change Request ganz unten im Stapel liegt.

Ein „Lean und Agile ITIL“ ist doch machbar. Haben Sie es schon versucht? Dann bitte Ihre Erfahrungen melden. Das Redaktionsteam von ITIL.de und sicherlich andere Leser sind an den Erfahrungsaustausch interessiert.

-- James Lee

/1/ Es gibt sicherlich tausende Bücher zu diesen Themen. Im IT-Kontext habe ich von folgenden profitiert: Henrik Kniberg and Mattias Skarin, “Kanban and Scrum - Making the Most of Both,” 2010, http://www.infoq.com/minibooks/kanban-scrum-minibook; Andrew Craddock, Agile Project Management (DSDM Consortium, 2010);  David J Anderson and Arne Roock, Kanban: evolutionäres Change Management für IT-Organisationen (Heidelberg: dpunkt-Verl., 2011); Mary Poppendieck, Lean Software Development an Agile Toolkit, 12. print. (Boston [u.a.]: Addison Wesley, 2007); Ken Schwaber and Jeff Sutherland, The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game, Version 2013, http://www.scrum.org/storage/scrumguides/Scrum_Guide.pdf.

/2/ Kanban bedeutet auf Japanisch „Karte“. Die Kanban wir verwendet, um zu zeigen, dass Teile neu aufgestockt werden müssen. Sie ist dadurch Synonym für Pull-orientierte Arbeit geworden. Siehe https://de.wikipedia.org/wiki/Kanban.

Kanban Boards werden häufig in Agile-Entwicklungsumgebungen angewendet.   Die simpelste Variante sieht drei Spalten vor: Backlog, in Arbeit, fertig. Nach Kanban-Prinzipen  dürfen nur eine begrenzte Anzahl von Aufgaben  „in Arbeit“ an einem gewissen Zeitpunkt stehen. Die Begrenzung zeigt die optimale Kapazität des Teams.  Kanban Boards können auch von Einzelpersonen für Arbeitsstrukturierung angewendet werden.  Hierzu siehe Jim Benson and Tonianne De Maria Barry, Personal Kanban: Visualisierung und Planung von Aufgaben, Projekten und Terminen mit dem Kanban-Board (Heidelberg: dPunkt, 2013).

Die Eingrenzung des Work in Progress ist häufig schwer zu realisieren, da stets etwas Neues auf unserem Schreibtisch landet. Allerdings, genau wie eine Maschine unter zu hoher Last kaputt geht, gehen Menschen unter zu hohem Druck langfristig auch kaputt. Obwohl jeder Mensch eine andere Arbeitsgeschwindigkeit hat, pendelt sich auch  der Schnellste langfristig auf den persönlichen Durchschnitt ein.