What IT Service Management can learn from the Agile Manifesto (and vice versa)

Agile has become incredibly relevant, also for the IT Service Management industry. This is nothing new. But do we really understand what this means? ITSM and Agile do not contradict each other. From my point of view two things are relevant: First, using agile project delivery methods and agile principles to drive ITSM initiatives forward (in contrast of using traditional waterfall methods). I call this CSI 2.0, because it finally brought the ITIL CSI approach down to earth. There are already many impressive success stories around. On the other hand, agile ITSM is about having a concept of integrating your ITSM processes and practices with agile service design & transition (e.g. scrum, crystal, dsdm etc.). As a side-note, the second one is also something DevOps tries to address. Weiterlesen

Die Geschichte von Don Quijote und IT Service Management

Ich würde ja jeden verstehen, der sich bei diesem Titel fragt, was denn die wunderbare, aber auch etwas schräge Geschichte aus dem 17. Jahrhundert mit dem modernen IT Service Management zu tun haben könnte. Ich denke … mehr als auf den ersten Blick meinen…

Für all die Leser, die die Geschichte nicht mehr präsent haben, finden unter den Links (siehe Schluss) eine einfache Zusammenfassung. Ich beziehe mich ausschliesslich auf das bekanntere erste Buch von Miguel de Cervantes Saavedra.

Der gute Don Quijote hatte offenbar Zugang zu einem riesigen Fundus an skurrilen und nicht immer realen Rittergeschichten und hat diese Bücher geradezu verschlungen. Immer mehr wurde dadurch diese Ritter-Welt zur seiner eigenen vermeintlichen Wirklichkeit und somit zu seiner Realität. Er zog mehrfach aus und erlebte dabei viele Abenteuer. Für Aussenstehende war das Ganze allerdings ziemlich schräg, befremdlich und so wurde er aktiv und nachdrücklich bekämpft, was der arme Don schmerzlich erfahren musste (sein Kampf gegen Windmühlen).

Ich denke, diese ausserordentliche Geschichte kann als Metapher für unsere heutige Situation im IT Service Management Umfeld gesehen werden. Sollte das eine oder andere meiner Ausführungen zum Schmunzeln anregen, so ist dies durchaus gewollt. (Auch als Service-Arbeiter* kann eine Prise Humor Berge versetzen….). Ich fokussiere mich in meinen Interpretationen der Metaphern auf zwei Richtungen, die ich im kommenden Teil gerne erläutern möchte.

These 1: „Der von einer guten Idee getriebene und gegen alle Widrigkeiten kämpfende Ritter“
Hand auf’s Herz, ist das nicht für uns als „Service Arbeiter“ die ganz normale tägliche Herausforderung, die Idee des sinnvoll gemanagten Services mit den entsprechenden Prozessen den betroffenen Stakeholdern zu erklären? Dass das zum Kampf von unterschiedlichen Wahrnehmungen führen kann, dürfte für viele von uns nichts Neues sein. Ja ich würde sogar wagen zu behaupten, das ist schlicht Alltag.

Auf der einen Seite steht das Senior Management, welches insbesondere im KMU Bereich nach wie vor leidgeprüft aus vielen gescheiterten Prozessversuchen den Schluss zieht, dass die Service-/Prozess-Orientierung nicht wirklich nötig und viel zu aufwendig sei (unter dem Motto: „Niemand kann uns erläutern, was unter dem Strich raus schaut, also lassen wir es besser…. es ging ja bisher auch ohne“)

Auf der anderen Seite stehen die gegen Windmühlen kämpfenden „Service-Don Quijotes“, die ehrlich, differenziert und besonnen den Wert eines solchen Service- bzw. Prozess-Ansatzes versuchen zu adressieren. Solche besonnen Ritter des Service Managements verfolgen (im Gegensatz zur späteren These 2) einen strategisch und taktisch klugen und weit vorausblickenden Ansatz immer in der Absicht, das Management vom Benefit zu überzeugen („quick-wins“, „low-hanging-fruits“, „start-small-think-big“, etc.).

Ich bin heute mehr denn je überzeugt, dass mit verdaubaren, nachvollziehbaren und vor allem mit schrittweisem Vorgehen, dieser Konflikt signifikant entschärft werden kann. Denn es ist durchaus so, dass spürbarer UND messbarer Erfolg gesehen und honoriert wird, was zu Appetit auf mehr führt. Es soll nicht zum Kampf werden (wie bei Don Quijote), sondern ein Miteinander, wo schrittweise und nachhaltig vorgegangen wird.

These 2: „Der völlig verblendete, von zu viel Phantasie fehlgeleitete Ritter“
Ich habe das selber erfahren vor Jahren, als ich das erste Mal in Kontakt mit ITIL kam. Ich war fasziniert von den Ideen, von den guten Ansätzen und Werkzeugen, welche die akuten und latenten Probleme der damaligen IT-Organisation adressierten und dadurch viele Lösungsmöglichkeiten offerierten. Obwohl überall als „best practice“ (es war eben noch die V2) angepriesen, nahm ich das ganze als „die neue Realität“ an und war geradezu euphorisch. Ich zog aus und konnte nicht verstehen, dass meine Gegenübers sich oft kopfschüttelnd abwendeten, bzw. sogar aktiv das Vorgeschlagene oder von mir selbstständig Eingeleitete, bekämpften.

Hier sehe ich den Vergleich zu unserem naiven Don Quijote, er war so weltfremd, dass er keine Wahrnehmung hatte für die Realität. Er kämpfte gegen die vermeintlich Bösen, die im Ursprung gar nicht so waren (ich spreche mal nicht von den Windmühlen…;-)

Über die vielen Jahre im Service Management habe ich gelernt, dass wenn man als realitätsfremder, immer an der Grenze von Ignoranz funktionierender Service Management Verfechter (z.B. ITIL, ISO20000, etc.) auf die Leute zu geht, das Gegenüber zur negativen Reaktion zwingt. Service Management ist kein Selbstzweck (und war auch nie als das gedacht), sondern viel mehr als Hilfsmittel in unser IT-getriebenen Service-Gesellschaft deren Wertschöpfung zu steigern.

Wenn ich Bücher, Berichte, Beiträge oder Blogs lese von Fundamentalisten und Evangelisten so wird mir sehr schnell klar, zu welchem nachhaltigen Schaden das führen kann. Ich stelle mir vor, wenn ich Mitglied des Senior Management wäre und mir erklärt würde, dass es jetzt unumgänglich sei, ein Projekt mit zig Mann-Tagen zu lancieren um die 4Ps („People“, „Process“, „Products (technology)“ und „Partner“) neu auszurichten und man dabei sicherlich einen Haufen Geld sparen kann, dann verstehe ich die äusserst kritische Haltung. Am Ende solcher skurrilen Kompagnien wird dann leidlich versucht den Mehrwert für den Aufwand zu rechtfertigen. Ich erinnere daran, dass im KMU-Bereich eine interne Service Management Kampagne ein signifikantes Investment darstellen kann.

Besonnenheit, Miteinander und ein neuer Ansatz
Ich wünsche mir für unser Service Management Business mehr Besonnenheit (mit kluger Voraussicht und dem Auge für das Wesentliche). Ehrlich in einem Miteinander herausfinden, wo der Schuh drückt und dann mit Weitblick und verdaubaren Schritten für Organisation und Business an die Umsetzung gehen wird erfolgreicher sein, als Grabenkämpfe und Selbstverwirklichung.

Ein für das Service Management eher neuerer Ansatz (der als Erweiterung gesehen werden soll) bekommt immer mehr Anhänger. Getrieben von der Idee, dass es für Organisationen oft schwierig ist (insbesondere bei kleineren), eine Prozesslandschaft zu etablieren, die alle Eventualitäten abdeckt, soll das Case Management eine neue Herangehensweise bieten, um strukturiert bei fehlendem Prozess oder Prozessfragmenten die Service-Organisation und somit den Service-Konsument zu unterstützen.

Im Wesentlichen gibt es zwei Ansätze:

  1. Die Organisation hat noch keinen Prozess für das Issue, welches jetzt ansteht („buttom-up“)
  2. Die Organisation hat wohl einen eingeführten Prozess, der hilft hier aber nicht
    weiter, da dieser nicht zum Issue passt.

Im Gesundheits- oder Sozialwesen kennt man diesen Ansatz schon seit mehreren Jahren und hat hier sehr gute Erfahrungen gemacht.

Eine gute Möglichkeit, diesen Ansatz kennen zu lernen und zu diskutieren ist der IT Manager Kongress (siehe link). Hier wird die SwissICT-Themengruppe „Service Management in der Praxis“, welche sich seit ca. einem Jahr mit diesem Thema beschäftigt, einen Workshop durchführen.

Linkliste:

Die Geschichte von Don Quijote

Workshop am IT Manager Kongress „Case Management in der Informatik“:


 

ISO20000 ausserhalb IT – a new challenge

Bis in 2011 war eine Zertifizierung nach ISO20000 (IT Service Management) nur Firmen bzw. Service Providern vorbehalten, welche ihre IT Service Management Prozesse nach ITIL Framework ausgerichtet hatten. Mit der Novellierung im Jahr 2011 wurde die Einschränkung der Zertifizierung auf IT Service Management Prozesse aufgehoben und die Zertifizierbarkeit auf alle Arten von Business ausgeweitet – vorausgesetzt, die Firma weist glaubhaft nach, dass die Steuerung und Governance für die Service Management Prozesse im eigenen Haus betrieben wird.

In einem aktuellen Kundenprojekt geht es genau darum. Die Firma betreibt ein grosses zentrales Druckzentrum, aufgeteilt in  8 verschiedene und kombinierbare Business-Services. Die Endkunden beziehen einen oder mehrere dieser Business-Services in jeweils individuellen Ausprägungen (z.B. Papierbereitstellung,) Die Business Services werden durch IT Services enabled, die durch eine konzernweit agierende IT-Organisation erbracht werden. Zwischen Business und IT existieren entsprechende Operational Level Agreements (OLAs). Die Auftragssteuerung erfolgt on demand durch einen Produktionsleitstand.  Die Endkundenservices gelten als erbracht, wenn innerhalb der vereinbarten Zeit die geforderten Printprodukte geliefert werden.Folgendes Bild zeigt den Scope der angestrebten ISO20000 Zertifizierung (oberhalb der blauen gestrichelten Line…..zum Vergrössern bitte anklicken):

ISO20000_Business

Die Herausforderung besteht nun in erster Linie darin, die Prozesse zur Steuerung der Business-Services mit den extern verlagerten IT Service Management Prozessen zu verlinken – und die Kontrolle über beide Welten zu behalten. Doch welcher IT Service-Provider lässt sich vertraglich dazu verdonnern, seine Prozess-Governance durch den Kunden wahrnehmen zu lassen?

Beispiel Change Management:

Das Business kennt das Change Management in Form von Kundenanfragen (Requests), die an die Key Account Manager heran getragen werden und bei entsprechender Bewertung und Freigabe in Form von Projekten umgesetzt werden. Die einzelnen Schritte im Projekt-Lifecycle (Analyse, Risikobewertung, Kosten, ROI, Ressourcen, Freigabe, Design, Deployment und Rollout) folgen in der Regel bereits den best practice Ansätzen des ITIL Change Managements. Schon heute lösen die Projektmanager im Rahmen der Projekte auch einen formellen technischen Request for Change beim IT Provider aus, damit die Implementierung auf technischer Ebene formell beauftragt und durchgeführt wird. Dieser technische Change beim Provider ist nun aber im Gesamtkontext untergeordnet -  führender Prozess ist der Projektmanagement-Prozess des Business. Die Ergebnisverantwortung bleibt beim Projektmanager des Business, denn er behält die Kontrolle auch während der technischen Change-Umsetzung in der IT. Wichtig ist jedoch, dass der Projektmanager zum Nachweis der Governance aktiv (als User im Tool zum Beispiel) in den technischen Change eingebunden ist. Darüber hinaus müssen regelmässige Prozess-Reviews zwischen IT und dem Business durchgeführt werden. Dazu wurde beim Kunden ein Pendent zum IT Servicemanager eingesetzt: Der Business Servicemanager. Er sammelt die Daten von den Projektleitern (welche ja mit Business Change Managern gleichzusetzen sind) und kommuniziert die Ergebnisse, Wünsche und Verbesserungsvorschläge als Single Point of Contact seinen Kollegen bei der IT. Dadurch ist gewährleistet, dass das Business die Fäden auch beim IT Changemangement in der Hand behält und die erforderliche Governance konform zur ISO20000 Vorgabe im Geltungsbereich wirkt. Der IT Provider verpflichtet sich seinerseits, alle Änderungen am eigenen Change-Prozess durch das Business freigeben zu lassen – gewährleistet durch Wahrnehmung einer Pflichtrolle im Change Advisory Board und bilaterale KVP-Massnahmen. Selbstverständlich entsprechen auch die IT Servicemanagement-Prozesse des IT-Providers den Anforderungen des ITIL best practice Frameworks und sind jederzeit transparent, nachvollziehbar, gemanagt und qualitativ abgesichert.

Wesentlich spannender wird dann die Betrachtung bei ISO20000 Prozessen, welche bei IT Providern und dem Business als Zertifizierungsanwärter weit auseinander driften. Die folgende Tabelle gibt darüber einen kleinen Überblick aus dem aktuellen Kundenprojekt (NICHT allgemeingültig!):

wer meint was? Zum Vergrössern bitte klicken

wer meint was? Zum Vergrössern bitte klicken

Es ist beim Wording dringend anzuraten, die Prozessbezeichnungen und was damit gemeint ist, über IT und Business zu vereinheitlichen. Einen Change-Prozess gibt es in unserem Beispiel beim Kunden nur in der IT-Organisation!

In der Regel werden durch eine Umstellung des Business Service-Managements ähnlich hohe Wellen geworfen wie bei einer Einführung in der IIL-konform agiert. Im Business ist dies noch ganz anders. Nicht selten findet man hier sogar innerhalb eines Projektteams verschiedene Ansätze zur “richtigen” Methode, ein Projekt zu führen. Das Verständnis für die gebotenen Dienstleitung in Form von definierten und katalogisierten Services und einen damit verbundenen Service Lifecycle ist oft nur lückenhaft erkennbar, Rollenmodelle sind im Business eher selten konsequent umgesetzt. Nur wenn die Business-Prozesse und die damit einhergehenden Verknüpfungen in die IT Service Management-Prozesse vereinheitlicht und implementiert werden, kann eine ISO20000 Konformität über längere Zeit auch für das Business gelingen.

Eine weitere Herausforderung wird sich zunehmend den Zertifizierungs-Auditoren stellen, wenn sie die bekannten Pfade des Prozessmatchings in das ITIL-Framework verlassen müssen, um pragmatisch und aus Sicht des Business eine ISO20000 konforme Bewertung vornehmen zu können. Wichtig ist hier in jedem Fall für den Kandidaten,

  • einen klaren Scope und Geltungsbereich für die Zertifizierung zu definieren
  • sicher zu stellen, dass die Governance über ALLE relevanten Prozesse nachweislich in eigenen Händen liegt
  • durch eine Policy über die Prozessleistung durch Dritte und entsprechende SLAs/OLAs sicher zu stellen, dass sich der third party Provider an die Spielregeln hält
  • ein klares Wording zu verwenden, das Missverständnisse im Audit klar vermeidet
  • ständige Kommunikation mit Auftraggeber und umsetzender IT zu pflegen und als Rolleninhaber in den Prozessen entsprechend zu agieren
  • Nachweise zu führen, dass die Prozesse gemanagt und kontinuierlich verbessert werden
  • Awareness-Kampagnen auf allen Seiten zu initiieren, damit der Beitrag einer Zertifizierung zur Optimierung der Service-Erbringung verstanden wird.

Es wird in den Business-Bereichen im Falle einer ISO20000-Zertifizierung organisatorische Anpassungen erfordern und bei oldstyle-Puristen im Getriebe knirschen – aber Kunden und IT werden  langfristig dankbare Nutzniesser sein. Mein Kunde geht nun entsprechend vorbereitet in eine Erstbewertung durch den TÜV Süd – und ich werde an gleicher Stelle gerne über den weiteren Weg eines Nicht-IT-Providers zur ISO20000 berichten.


 

Integration von Cloud Service-Elementen in meinen Service Katalog: einfach ‘find’ and ‘replace’?

Es gibt kaum eine Unternehmens-Informatik, in welcher IT Service Management nicht in irgendeiner Weise vorhanden ist.

Basis bilden meist die Service Operation – Prozesse (Incident Management, Problem Management, Service Request Management, Event Management), welche mehr oder weniger ausgeprägt etabliert sind und gelebt werden.

Jedoch wird bei der vorgängigen Phase wie Service Design und Service Strategie das Kundefeld lichter, die implementierten Prozesse weniger.

Warum überhaupt ein Service Katalog?

Gerade letzte Woche war ich bei einem grösseren Kunden, bei welcher einen Kostentransparenz sprich ein Service Katalog mit Preisen auch heute (noch) kein Thema ist. Ebenso kompliziert und intransparent hat er mir seine jährlichen Budgetrunden mit dem Business beschrieben. Ein einfacher Service Katalog mit den entsprechenden Service Level Agreements könnte hier Abhilfe schaffen.

Diese Erfahrung konnte ich auch bei einem innerschweizerischen Unternehmen machen. Innert 4 Monaten hatten wir die 40-50 Hauptservices definiert. Der Finanzchef der IT Abteilung kam mir freudestrahlend entgegen – endlich konnte er mit seinen Geschäftskunden diskutieren über Absatz und Umsatz – Ziele pro Service, ein Novum für diese. Auch im Hinblick auf die anstehende Budgetrunde und Kostenübernahme – Diskussion fürs neue Jahr kam diese neue Basis wie gerufen.

Zugegeben, der in der schnelle geformte Servicekatalog war bei weitem nicht perfekt, jedoch genug detailliert, damit in die nächste Jahres-Budget-Runde einzusteigen. Die Toleranz war mit rund +/- 15% Unschärfe völlig akzeptable für den Kunden.

Einerseits existierten ja bereits Fragmente von technischen Services – was ergänzt werde musste ist meisten die Business Sicht. In mehreren Workshops wurden die Businessziele / Business Services identifiziert und eine Grundlage für eine Service Architektur gelegt.

Neue Service Elemente wie beispielsweise „Office 365“ oder „Cloud Storages“?

Was passiert jedoch, wenn sich nun aus der Sourcing Strategie plötzlich neue Technologien (beispielsweise „Office 365“ oder „Cloud Storage“) einbringen?

Farbspitzen

Die Auswirkung auf die Betriebsorganisation kann mittel bis gross sein, falls sollte Komponenten extern beschafft werden. Plötzlich wird aus einem Change auf Service Komponenten ein mittleres Organisationsprojekt. In diesem Fall sollte mit allen Involvierten vorgängig das Gespräch gesucht werden. Nicht, dass sich nun Kernaufgaben wie z.B. Operation wegfallen, nein, der gesamte Wechsel von einem Service Provider zu einem Service Integrator wird in den Fokus der Aufgaben rücken. Wie gehen wir dabei vor?

    • Review der Vision, Strategie und der Ziele
    • Review der «As-Is» Situation
    • Definition der «To Be» Modellkomponenten
    • Definition des «To Be» Betriebs – Modell
    • Transformation «As-Is» nach «To Be»

Solche Strategie Entscheide sollten begleitet werden im Sinne, dass die Auswirkungen auf die Organisation frühzeitig untersucht werden. Unserer Erfahrung nach empfehlen wir hier Betriebsmodell Varianten auszuarbeiten, welche sodann gewichtet werden…und schlussendlich sollte hinter solch einem Vorhaben ein Business Case stehen.

Betriebskonzept, Varianten – Business Case

Wenn alle Beteiligten involviert werden, können diese neuen Perspektiven für die Mitarbeiter durchaus sinnvoll, nachvollziehbar und gleichzeitig herausfordernd sein. Somit kann nicht zuletzt den Einzelnen ein interessanter, im ursprünglichen Aufgabengebiet erweiterter Job angeboten werden.

Differences in Service Management System between internally managed private Cloud and externally managed private Cloud

In one of my last blogs, I was reflecting on “Private Cloud and the impact to the existing IT Service Management System”. This view took in consideration design, transition and operation of an internally managed private Cloud.

There might be reasons to review the internally managed private Cloud model:

  • Building a private Cloud environment with out-of-the box Cloud products might by cumbersome, especially all the necessary integration, automation and orchestration effort is far too high, complex and costly,
  • Shortcomings in expertise, experiences, skillsets for Cloud architecture, engineering and integration design and build,
  • Shortcomings in expertise, experiences, skillsets for efficient and effective Cloud operation management,
  • Building an running a complete new set of technology is just not in line with strategy on core competencies,
  • Sourcing opportunities/alternatives are in line with company compliance and risk profile.

So what is the impact to the Service Management Model by moving to an externally managed private Cloud?

First and foremost, the management would need to understand the value of a defined sourcing strategy supporting the definition and the sustainability of the business case for an outsourced private Cloud from strategy over design, transition to Cloud Service operation. Besides the decision on the horizontal life cycle span of sourcing, the other sourcing dimension to be considered is vertical range of ownership for the Cloud Service’s value chain.

Sourcing ranges

Furthermore, the Cloud Service portfolio would need to be modified catering for the impact of the outsourced service elements. Same for the Financial Management: the definition and implementation of a pay-per use cost model between two separated legal entities would need to be supported.

Secondly, all the processes and functions supporting Service Design would need to be adapted for the support of an outsourced model. Sometimes hard to swallow for the teams in Service Design is the fact, that they have to revisit their traditional “selecting products (Cloud tech stack) approach” scope and responsibility. Now they are being asked to define service specifications based on business requirements and to process those specifications as part of a proper Service provider selection exercise. In order to do so, processes like service level, capacity, availability and continuity and security and, last but not least, supplier management processes and the respective process outcomes are becoming paramount.

On a capability level in Service Design, the shift to be supported is from technical skillsets to service and supplier management covering business consultancy, architecture and security as well as compliance and integration capabilities.

Thirdly, Service Transition and its processes are becoming a new  challange since the Cloud Service is being setup under the responsibility of an external partner. All the integration layers between in-house and provider (data bus, identity & access, processes, roles, boards) would need to be established as designed and contracted during that phase. This requires tight and stringent governance over the transition project.

Finally, the internal IT organization is not struggling anymore with definition and implementation effort for automated processes in service operation. The Cloud service provider will have all the operation processes being automated and integrated with customer’s portal, sign-on, dashboard and reporting functions. Capabilities and skillsets remaining in-house in service operations are to manage the provider regarding service performance, demand and change management, service reporting and accounting as well as continual service improvement.

For the moment there’s only one thing left to say. Even when a company sticks to an internally managed Cloud Service model, by integrating public cloud offerings with private Cloud Services (hybrid model), all the listed aspects above will have to be taken into account as well.

Integrating Agile and ITSM

Every week a new production release and often changing requirements and priorities – this is daily life in agile environments. How does this project delivery approach (usually: SCRUM) fit into existing IT Service Management processes (usually: ITIL)? How do we manage for example the increasing trade-off between flexibility and stability? How do we make sure operational service-requirements are reflected in an early phase of an agile project? How do ITSM-roles and SCRUM-roles chime together? Can ITIL and SCRUM coexist? YES, definitely!

Before we proceed on that, just to make sure that things don’t get mixed up:

  • This blog is not about using agile project delivery methods to drive ITSM initiatives forward (I call this CSI 2.0: An very promising, but completely different topic)
  • I hope it’s also not one of these wishy-washy “let’s go agile ITSM” blogs, which promote that we now should forget all the processes and become ‘cool agile’. In my opintion, there is on the ITSM-side a lack of understanding, that SCRUM is an extremely structured approach, but within these boundaries promotes the principle of self-organization. Often, only the second part is perceived and ‘becoming agile’ acts as a bad excuse for the chaos. A very good observation on this you can read in this blog.
  • So this is rather about how to integrate a specific Project Management approach with ITIL. Especially if agile project methodology is used for existing products or services (being already in operation), a tight integration into your Service Management processes is key.

Developing the Model

Step 1: Understanding the two Domains and their Goals

ITIL and SCRUM do not contradict each other. There is no incompatibility. SCRUM is a specific way to deliver projects, it’s an iterative, adaptive and incremental approach to project management. You can use it for any kind of project, even outside IT, and has become by far the most popular agile methods. ITIL is about best practice IT Service Management. It’s a holistic collection of ideas and processes on how to define, design, transition, run and finally continuously improve services (-> that’s the service lifecylce). ITIL takes the operational point of view into consideration, acknowledging that value to the customer is delivered during service operation and therefore operational requirements must be reflected in an early phase of Service Design. ITIL is agnostic on what PM methodology is used. So ITIL and SCRUM are rather complementary. Similar if you would look at ITIL and Prince. The challenge is how the two interact.

Step 2: Understand how the two Domains fit together on high Level

ITIL and SCRUM fit perfectly on high level. From ITIL perspective, SCRUM starts with Service Design and ends with the delivery of a product or service (well, actually it starts over and over again). I made below graph to illustrate this:

Scrum & ITIL: A perfect fit on high level

Scrum & ITIL: A perfect fit on high level

So, let’s quickly walk through the SCRUM process and you will immediately understand what this buzz is all about:

  1. Service Design: Starting from the approved business case, requirements are gathered in form of user stories & prioritized. The result is the prioritized product backlog.
  2. Service Transition: This is handled through timeboxed sprints (typically between 1-6 weeks each sprint). Each sprint starts with a sprint planning meeting, in which user stories are included for the next sprint (-> sprint backlog, a subset of the product backlog). Daily standup meetings help to track progress and to eliminate impedimends. The sprint ends on the one hand with the sprint review meeting, in which the new/changed service or product is formally accepted. On the other hand, there is the Sprint Retrospect Meeting, which results in the lessons learned for the next sprint.

Step 3: Tackling the Challenges

Don’t forget Operations

One issue with purely SCRUM-driven projects is that they don’t care about Service Operation and focus very much on the utility (functional requirements) of a new product or service. Solutions are thrown over the fence and especially warranty-aspects of a new service (capacity, availability, security and continuity) are not taken into consideration and at the end of the chain the service doesn’t deliver it’s value. DevOps provides some ideas on how to solve this, but I still don’t get the point how DevOps works in practice (…). One of the big contributions of ITIL is that these operational aspects are already reflected in an early stage of the Service Design phase. Applied to SCRUM, this would mean that already during creation of User Stories and the Product Backlog these requirements are gathered. During the sprint, teams taking care of these aspects (e.g. infrastructure) need to be part of the Scrum Team.

Including warranty requirements in the product and sprint backlog planning

Including warranty requirements in the product and sprint backlog planning

Change Management & Release Planning

From an operational perspective, Change Management acts as a protector of the productive environment, identifying risks of each change and preventing negative impact. More broadly , you can put every change on a Configuration Item under Change Control (e.g. product backlog, which is created in Service Design). The tricky question is to which extend. On the one hand it will give you more stability; on the other hand you add more administration and loose flexibility. So it’s a trade-off. Change Control is also a big topic in SCRUM, for example each sprint end with a sprint review meeting, in which the product owner reviews and approves the sprint. Or in Service Design, the product owner acts as a gatekeeper for each user story (change control over requirements). So putting this picture together, there are many instances of change control:

How much change control do you need? Balancing flexibility & stability through delegation models and achieving a controlled service environment

How much change control do you need? Balancing flexibility & stability through delegation models and achieving a controlled service environment

To achieve the right balance between flexibility and stability it is key a) to decide, what you want to put under change control and b) moreover to apply the right delegation models. For example:

  • Change control over the Product Backlog is delegated to the Product Owner. However, Service Operation teams should be involved as well to ensure operational warranty requirements are included as well in the user stories;
  • Change Control over the sprint results is delegated to the Product Owner and in case the sprint shall be included in a future release, the regular operational CAB acts as an approver too;
  • Change Control over the Sprint Backlog is delegated to the Product Owner, Scrum Team and Scrum Master and the regular Release Planning Team.

Test Automation

Using agile project methodologies means frequent releases. Testing can become a real pain. This concerns less the testing of new functionality, but rather the regression testing (checking if existing functionality has been affected by new release, repetitive). Automating regression tests is key. Test factory teams need to be involved early and based on the product backlog develop test cases need to be developed and automated.

Step 4: Integrating SCRUM- and ITIL-Roles

Scrum knows only three key roles: The Product Owner (‘voice of the customer’), Scrum Master (the facilitator) and the Scrum Team (the developers). ITIL knows many roles, but Service Owner, Change Manager, CAB and CSI Manager seem to be very relevant to me in this context.

  • ITIL Service Owner and SCRUM Product Owner: If we talk about existing services, it makes sense that the two roles are incorporated in the same person. Both roles act as a voice of the customer and know the requirements side. On the software side, this is often represented by the Application Owner.
  • Change Management: Scrum Master and Product Owner need to be part of the CAB if it comes to the release of a sprint. The Product Owner acts as CAB approver from a sprint backlog point of view.
  • CSI Manager and Scrum Master: Continuos learning is an integral concept in Scrum: In sprint retrospective meetings, process improvements are identified. In the daily scrum meetings, impediments which hinder success are eliminated. This is all happening under Scrum Master responsibility. Structural improvements out of the Scrum process should be considered from overall organizational developement perspective and become part of the CSI register, therefore the Scrum Masters and the CSI Manager should liase on a regular base.

So I hope this gave you some ideas on how to bring the two worlds together. Scrum is not just for developing new products in an isolated world. It has become mainstream for tackling Service Design & Transition for existing Services. Finally, we talk here also about two worlds, which historically do not talk to each other. One the one hand the developer guys, on the other hand the operation guys. This is why we needs an integrated & practical approach on how to bring them together and finally a mutual understanding how both worlds work.

Don’t see it as a threat, see it as an opportunity.

Agile ITSM ist keine Rechtfertigung für das Chaos

Flexibilität, Geschwindigkeit und Resultatorientierung – das sind die Verlockungen, mit denen agile Methoden für sich werben. In vielen IT Organisationen wird damit eine erholsame Lanze gebrochen, um gegen der formalisierten, mitunter durch langwierig andauernden Abstimmungsprozess blockierten Entscheidungsfindung entgegen zu treten. Zu lange haben die Standardisierungsbemühungen in der Technologie aber auch in den Prozessen die Kreativität der IT Spezialisten in arge Schranken versetzt.

IT Service Management auf Basis von ITIL hat vielerorts dazu beigetragen, dass der Pragmatismus durch eine eher durch Bürokratie geprägte IT abgelöst wurde. Nun schlägt das Pendel der Entwicklung zurück. Cloud Computing, Multi Vendor Service Modelle, BYOD bei Anwendern und innerhalb der IT sowie die grassierenden Sozialen Medien sind Trends, denen sich keine IT Organisation ernsthaft erwehren kann. Das Business will von den Entwicklungen profitieren.

ITIL als Leitfaden für Best Practices in IT Service Management hat auf diese aktuellen Entwicklungen keine passende Antwort. Es wird noch Jahre dauern, bis ein entsprechendes neues Release der ITIL-Bücher erwartet werden darf, welcher sich dieser Thematik angemessen annimmt.

Agil und Lean sind daher heute im Management gern gehörte Begriffe und werden wohlwollend unterstützt, weil damit Flexibilität und rasche Umsetzung erhofft wird. Bestehende Abläufe und Prozesse werden in Frage gestellt – was zählt ist letztlich nur das Resultat, dass rechtzeitig vorliegt.

Agiles Vorgehen setzt hohe Maturität voraus
Dabei setzen agiles Vorgehen selbst strikt einzuhaltende Prozesse voraus. Das zu lösende Problem muss klar definiert sein, die Zeiten gilt es strikte einzuhalten und Entscheide sind im Team zu fällen. Prozesse sind also nicht ausser Kraft zu setzen, sondern viel mehr auf Dynamik und mit kürzeren Durchlaufzeiten auszurichten. Dies setzt eine entsprechend hohe Maturität der IT Organisation voraus. Hohe Maturität heisst hier: ziel- und resultatorientiert sowie selbstregulierend durch klare Zuständigkeiten und Kompetenzen.

Bei niedriger Maturität droht institutionalisiertes Chaos
IT Organisationen mit niedriger Maturität haben oft starre, bürokratische Abläufe, welche oft schlecht bis gar nicht gesteuert werden. Fehlende Dokumentationen, unklare Zuständigkeiten und nicht abgestimmte Ziele zwischen den Teams prägen solche IT-Abteilungen. Das Umschwenken auf agile Methoden wird hier von der Führung gerne als Vorwand genommen, da die Umsetzung auf ITSM-Praktiken gescheitert ist. Agile Methodik ohne Prozesse und Führung zementiert das bestehende Chaos und fördert das einzelkämpferische Vorgehen und das vorherrschende Heldentum.

Prinzipien agiler Vorgehensmethodik

Prinzipien agiler Vorgehensmethodik

Agiles ITSM heisst Fokussierung
Agiles ITSM hat aber durchaus seine Berechtigung und bringt grosse Vorteile, wenn man diese zu nutzen weiss. Wesentlich beim agilen Vorgehen ist, dass man sich auf das Wesentliche Fokussieren kann. Das heisst, dass man Aufgaben priorisieren muss und dass die Teams lernen müssen, die Arbeiten innerhalb vorgegebener Zeit auch tatsächlich abzuschliessen.

Arbeiten abzuschliessen anstelle immer neuere zu starten ist der kritische Erfolgsfaktor in der agilen Vorgehensmethodik. Wenn ich oft in IT Organisationen Einblick erhalte, sehe ich viele Teams, welche mehr Arbeit haben, als dass diese je erledigen können. Dort fehlt eine klare Fokussierung auf das, was wirklich wichtig ist.

Teams welche keine klare Fokussierung haben, liefern in aller Regel auch eine schlechtere Qualität. Durch den Versuch, alles auf einmal zu tun, entwickeln sie ein eigenständiges Verständnis und Definition dafür, ob eine Arbeit abgeschlossen ist. Man erklärt etwas als erledigt um sich dem nächsten Thema widmen zu können. Das Risiko ist relativ gross, dass die Arbeit zum ungünstigsten Zeitpunkt wiederholt werden muss.

Wie können nun IT Service Management Teams agile Methoden anwenden und den Fokus auf das Wesentliche erhalten? Wichtig ist, dass man die Arbeiten und der Sinn der Aufgabenstellung richtig versteht. Was ist der Ursprung der Aufträge und wie sind diese in die IT Organisationen übertragen worden? Verstehen wir die Zusammenhänge und Abhängigkeiten? In dem den Teams der Umfang der Arbeiten reduziert wird, auf das sie sich fokussieren sollen, verändert sich in der Regel auch ihre Einstellung, die Bereitschaft zur Termineinhaltung und das Verständnis der Qualität.

Sicherstellung der Dynamik durch Business-Alignment
Pläne und Prioritäten ändern. Das ist eine Tatsache, die es in Projekten wie auch innerhalb ITSM zu akzeptieren gilt. Business Anforderungen können mitunter schnell ändern und müssen berücksichtigt werden. Agile ITSM Teams müssen lernen, in Iterationen zusammen mit dem Business zu arbeiten.

Anstelle einmal jährlich vom Business Projektaufträge zu erhalten und diesen koste es was es wolle umzusetzen, brauchen agile ITSM Teams viel häufigere Begegnungen mit dem Business. Allenfalls monatlich trifft man sich mit dem Business, schaut sich den Gesamtplan immer wieder an und richtet durch Re-Priorisierung die Aktivitäten der IT auf das aktuelle Geschäftsgeschehen aus. Man kann nun im Detail auf die nächste Iteration hin planen, da die Informationen auf den aktuellsten Geschäftsentwicklungen beruhen.

Nur schon die regelmässigen Meetings mit dem Business und die laufende Überprüfung der Prioritäten ist ein erster wichtiger Schritt in Richtung agiles ITSM.

SCRUM Overview

SCRUM Overview

ITSM Teams befähigen statt kontrollieren
Die besten Lösungen kommen oft von selbstorganisierten Teams. ITSM Organisationen mit hoher Maturität befähigen ihre Teams zur Erarbeitung von Lösungsansätzen anstelle der detaillierten Beauftragung, wo nur noch umgesetzt werden darf. Wenn die Teams keinen Raum für Flexibilität und Kreativität haben, werden auch keine guten Lösungen entstehen. Es braucht klare Grenzen der Organisation, welche eingehalten werden müssen. Innerhalb dieser Grenzen sollen agile Teams aber frei arbeiten können. Es braucht ein hohes Vertrauen des Managements dazu – das Ergebnis lässt in der Regel nicht auf sich warten.


 

Emerging new Roles, Job Titles, Trainings and Certifications in the Cloud Services Area

As outlined in my last blog (“Private Cloud and the impact to the existing IT Service Management System”), the impact of the cloud services to an existing IT Service Management System is quite significant. Besides of the completeness, maturity, level of detail and automation challenges for the IT processes, internal IT organizations need to look to the impact to their organizational capabilities in terms of skills, expertise and experiences needed to run the show successfully.

imagesCAXB8HT1

The new skills, expertise and experiences needed are based on:

  1. new technology, tech stack integration and process automation,
  2. new or increased risk profiles for security and compliance,
  3. increased service governance and customer relationship requirements.

Starting with customer relationship management: Internal IT organizations are moving their business facing roles like “Business Analysts” more and more towards “Business Consultancy”.

“Business Consultancy” is way above defining requirements based on business needs. It is to look to the potential added value of an IT service for the business. The role of a “Cloud Consultant” as a customer facing role is to:

  • coach business functions on the impact of cloud services to the value chain of business services and products
  • help the business to create and to understand business case scenarios for moving into the cloud
  • review the business processes and portfolios to come up with cloud service proposals based on market trends
  • outline cloud migration and transition concept
  • coach the business functions on security, compliance and risk matters from an IT point of view.

Positioning an internal IT organization as a (private) cloud provider or cloud broker function (hybrid cloud deployments) requires a much stronger focus on service Ownership and service portfolio management. The role of a “Cloud Service Owner” ensures governance over all cloud service lifecycle phases, proper cloud service portfolio management and IT efficiency.

Capture

Looking to the service design phase of a cloud service, cloud specifics like resource pooling, rapid elasticity, orchestration and end-to-end automation will shape the traditional IT Architect role towards “Cloud Solution Architect“. A traditional “Developer” role will become a “Cloud Developer“. Due to the increased risks profiles in the area of security and compliance, dedicated cloud security management skills are needed. Therefore, the role of a “Cloud Security Manager” is to be considered. For service transition and service operations, two emerging roles with dedicated cloud knowledge are underway: The “Cloud Administrator” role is focused on running the cloud tech- stack based on automated run-books. The skillsets will be spread across all technology components used in the cloud. On contrary to traditional IT, cloud tech skills are not dedicated to technology towers. They are more towards understanding and managing technology integration, automation and orchestration. Last but not least, the overall responsibility for running a cloud service in operations will be with the “Cloud Service Manager“. The main responsibility of that role is to ensure, that a cloud service is being delivered by meeting the agreements and quality parameters routinely.

The mentioned emerging roles are becoming industry standards. Already today, role descriptions and even training and certification schemes are available. Please have a look at http://www.cloudcredential.org/certifications/ for more information.

Service Management ist mehr als die Summe aller Prozesse

Immer wieder treffe ich bei Kunden ein ähnliches Phänomen an: man hat wohl seit Jahren bereits eine stattliche Anzahl von ITSM Prozessen implementiert, aber keine gemeinsamen Ziele entwickelt, was damit erreicht werden soll. Anstelle funktionaler Silos abzubauen, hat man zusätzliche Prozess-Silos eingerichtet ohne jegliche Orientierung und selten mit der notwendigen Abstimmung. Die Prozessownership wird über die verschiedenen Organisationsbereiche verteilt – aber eine gemeinsame Vision, was mit den Prozessen zu erreichen ist, fehlt.

Vor lauter Bäumen den Wald nicht sehen

Vor lauter Bäumen den Wald nicht sehen

Vor lauter Bäumen den Wald nicht sehen wollen
An den Führungsstrukturen und an den Prinzipien in solchen Organisationen hat sich trotz dieser Prozesse überhaupt nichts geändert. Die von den Prozess-Ownern ermittelten und selbst definierten KPIs interessieren das IT Management genau so wenig wie die Daten, welche durch die verschiedentlich involvierten Systeme produziert werden. Hauptsache der Auditor hat nichts zu meckern…

Irgendwie verbindet man mit Prozessen noch eine gewisse Ordnungsmässigkeit – aber als Steuerinstrument für die IT werden sie in den seltensten Fällen verstanden.

Service Management ist ein völlig neu ausgerichtetes IT-Geschäftsmodells
Wenn man seine Organisation nach Service Management ausrichten will, dann muss man bereit sein, sein bisheriges Geschäftsmodell zu hinterfragen. Ein paar Prozesse einrichten die sich mehr oder weniger nach ITIL ausrichten hat damit nichts, aber auch gar nichts zu tun.

Service Management sind nicht nur Prozesse. Es sind die Führungsstrukturen, Prinzipien, Ziele, Mitarbeiter, Technologien und Tools, Daten, Kommunikation und und und … Und diese müssen in der Summe komplett neu ausgerichtet werden. Es wird nicht behauptet, dass es einfach ist. Es ist schwierig und benötigt Manager mit entsprechenden Visionen. CIOs, welche diese Visionen nicht haben, werden die Ziele nicht erreichen. Was ich heute in den meisten Fällen der Service Management Implementationen sehe, ist leider halbe Lippenbekenntnis ohne jegliche Orientierung und demzufolge auch ohne jeglichen nachvollziehbaren und wirtschaftlichen Erfolg.

Die immer wieder aufkeimenden Polemiken zwischen, was ist nun ein Service oder IT-Service und was ist ein System oder IT-System helfen nicht wirklich weiter. Zumindest nicht diejenigen, welche vor dem Problem stehen, eine Lösung bereitzustellen. Grundsätzlich bin ich auch klar der Auffassung, dass die Tools den Prozessen zu folgen haben und nicht umgekehrt. Aber ich kann nicht nur esoterisch in der Wolke diskutieren ohne irgendeinmal die Füsse auf den Boden stellen zu können. Wer Taten statt Folien will, muss die Theorie in der Praxis beweisen können und wollen.

Ganzheitliches Denken heisst, nichts auszulassen

Service Management ERP System

Service Management ERP System

Wenn Service Management als Geschäftsmodell in der IT gewollt ist, braucht es auch ein Service Management System. Am einfachsten stellt man sich vor, dass es ein ERP System, ein Enterprise Resource Planning System braucht für die IT. Enterprise-Resource-Planning (ERP) bezeichnet die unternehmerische Aufgabe, die in einem Unternehmen vorhandenen Ressourcen (Kapital, Betriebsmittel oder Personal) möglichst effizient für den betrieblichen Ablauf einzusetzen und somit die Steuerung von Geschäftsprozessen zu optimieren (Gemäss Wikipedia).

Architekturkonzept TOGAF

Architekturkonzept TOGAF

Und so ein System zu bauen und zudem noch Kundenorientierung und Serviceorientierung zu integrieren, setzt das Vorhandensein einer serviceorientierten Architektur voraus. Das Haus, das gebaut werden soll, muss einen Architekten haben, der die verschiedenen Anforderungen mit den vorhandenen Ressourcen und Technologien abstimmt, damit die Funktion des Service Management Systems vollständig wahrgenommen werden kann.

Um Service Management wirkungsvoll umzusetzen, braucht es also einen Architekten, welcher das Geschäftsmodell der IT mit den Prozessen, Anwendungen, Datensystemen und Technologien aufeinander abstimmt und orchestriert, dass die Summe als Ganzes die Ziele der IT optimal erreicht. In einer solchen Umgebung gibt es kein Jekami-Konzept. Gerade wenn Organisationen etwas grösser sind und beispielsweise über hundert oder gar tausend IT Mitarbeiter in sich vereint, dann ist eine solche Rolle unverzichtbar.

Die Business-Architektur gemäss TOGAF beinhaltet in der IT das grundsätzliche Betriebsmodell mit allen Governance- und Management Prozessen. Hier spielen die ITIL Prozesse eine massgebliche Rolle. Die Service Management Prozesse sind die “Business Prozesse” der IT. Hier werden die Bedürfnisse der Kunden abgeholt, die Service Leistungen vereinbart und letztlich auch erbracht und garantiert. Hier findet die Orchestrierung der Services statt und stellt die Dynamik des Business sicher.

Aber dazu braucht es eben auch Hilfsmittel und Daten. Diese sind entsprechend den Bedürfnissen der Business-Architektur auszurichten.

Die Informations-System-Architektur beinhaltet alle Hilfsmittel, Applikationen und vor allem Daten, welche im Rahmen eines Konzepts aufeinander abgestimmt werden müssen. Hier spielen Die ITSM-Tools und System-Management Werkzeuge wie Reporting, Deployment, Monitoring oder auch Event-Konsolen eine zentrale Rolle. Insbesondere ein Daten- und Informations-Management Konzept sind hier unabdingbar und konsequent durchzusetzen. Das Reporting setzt letztlich hier auf den Daten auf, welche verlässlich sein müssen. Es ist wichtig zu wissen, wo die Daten sind, woher sie kommen und wer die verarbeiteten Daten benötigt. Wenn schon Redundanzen, dann bitte kontrolliert.

Aber irgendwo müssen die Tools und Daten auch technisch in Betrieb genommen werden. Dazu braucht es die Technologie-Architektur.

Die Technologie-Architektur beinhaltet alle Systemtechnischen Komponenten und Bewirtschaftungssysteme. Hier werden die Puzzles zusammengestellt und die Schnittstellen bedient. Hier geht es letztlich auch ab, was oben mal angedacht wurde. Dabei können Systeme und Platformen aus der Wolke, zugemietet oder in den eigenen Räumlichkeiten bereitgestellt werden. Was wie in welcher Ausprägung genutzt wird, hat letztlich Auswirkungen auf die Dimensionierung. Hier müssen die Zusammenhänge der Service Architektur und System Architektur gut verstanden werden, damit das Ganze mehr als die Summe der Einzelkomponenten wird.

Jede IT hat das Service Management System, das er verdient…

Jeder hat die IT, die er verdient

Jeder hat die IT, die er verdient

Wenn man nicht weiss, was man will, dann darf man sich nicht wundern, dass man erhält, was man nicht braucht. In Zeiten des knappen Geldes, wird der Druck nicht nachlassen, sich als CIO erklären zu müssen.

Die IT kann nicht glaubhaft als verlässlicher Provider gegenüber dem Business auftreten, wenn sie im eigenen Haus keine Ordnung hat. Hier kann der Tatbeweis erbracht werden, das Geschäftsmodell nicht nur zu verstehen, sondern selber zu beherrschen.

Prozesse sind gut und wichtig – aber bei weitem nicht der einzige Faktor, der Service Management zum Betriebsmodell einer IT macht. Ein Service Management Architekt kann hier die wichtigste Ansprechstelle sein, um agil reagieren zu können, wenn neue Anforderungen anstehen.