Frameworks & Standards Reality Check: Let’s ask Google Trends

In my last blog I wrote about ITSM & the Agile Manifesto, which was shortly after followed by a hype around creating an ITIL Manifesto. Coincidence? It doesn’t matter. Anyway, it’s now time to do something different, to do some solid statistical work.

So my simple question was: BPMN, ITIL, Prince2, CMMI, Six Sigma, Kanban, ISO20k (…) – What are people looking for? After having played around with Google Trends, I think this tool gives us a pretty good answer. Google Trends shows us the Google search volume for specific keywords (or topics) over the last 7 years. Don’t forget, first of all, this is ‘just’ data (and it’s BIG data), which reflects real crowd behavior.

Warning: Don't do any wrong correlations & conclusion out of the data in this blog

Warning: Don’t do any crazy correlations & conclusion out of the data in this blog

You therefore have to be careful when drawing any conclusions or doing casual analysis out of Google Trend data. Otherwise you might end up in the same situation as recently the Princeton University researchers, which made some predictions about Facebook (very funny, don’t miss this article). So basically you can read the following out of Google Trends:

  • Volume per keyword (relative to each other): This is a good indicator for overall search popularity, but not necessarily for the specific importance.
  • Trend over time: This is a very good and valid indicator. It shows the change in popularity over the last 7 years or any other shorter timespan.
  • Geography: By splitting results by country, this gives you an idea about regional differences in keyword popularity or trend
  • Keyword drilldown: Very interesting. It shows you what the people are really looking for (per keyword). E.g. ‘ITIL’ very much relates to ‘ITIL certification” or “ITIL v3”, but DevOps rather to ‘What is Devops?’

Setting the Scene: Keyword List Definition

I collected a list of known standards and frameworks, some you might also call methods or approaches. The thing they have in common is that they are all relevant for IT, but many of them not exclusively. They cover Project Management, ITSM, Governance and Process Management and other areas, some of them are industry specific. I decided also to include Standard like ISO 9000 as this is relevant in comparison to other QM-focused IT frameworks. Below chart shows the terms I was using (btw created with wordle.net):

Setting the Scene: An unrefined  List of Frameworks, Standards and Methods

Setting the Scene: An unrefined List of Frameworks, Standards and Methods

Let me know, if I missed any important standard, framework or method and I will add it.

Search Popularity Analysis: The ‘Big Five’

I compared all the keywords, some refined by topics or negative keywords. For example, the term Scrum also refers to sport (rugby). Additionally I discovered that something is wrong with ITIL: It’s an extremely popular search term in Indonesia, which made me curious. After consulting Google Translator I found out that ITIL means Clitoris in Indonesian Language (funny, isn’t it?), which explains the regional spike. Again, I was able to filter all that irrelevant data out. Looking at the ‘Top five’ (Snapshot as per now), we have the following picture:

Google Trends: The 'Big Five'

Google Trends: The ‘Big Five’

As you can see, ITIL is by far the top one, followed by Scrum, ISO 9000/9001, Six Sigma (all at the same level) and finally Kanban on Rank 5.

If we go further down the list, the ranking continues like this (exact order):

ASL, TIPA and GAPPS I had to remove completely, because they returned invalid results (multiple meanings with no possibility to refine).

Analyzing the Trends over Time

Looking at the big five, one surprise for me was ITIL: Many people say that there is a decrease in popularity. It’s not true. Over the last 3 years the trend is flat, preceeded by a peak at 2007 (obviously related to the publication of ITIL V3) and a decrease which stopped 3 years ago.

Another observation is the continuous and impressive increase of popularity of Scrum over the last 7 years. In the agile area, Scrum seems to continuously rule out other agile frameworks/methods like DSDM/Atern and XP. No surprise. However, if we look at ISO 9000/9001 and Six Sigma, there was a huge decrease of popularity since 2007. Going through the whole list, we see the following:

  • Winners: Scrum, DevOps (First appearance 2011, now Rank 9) and TOGAF (slightly)
  • Evergreens (flat curve): ITIL, Kanban, Prince2, PMBOK, BPMN, ISO20’000, ISO 27’000 and Cobit
  • Losers: Six Sigma, CMMI and ISO 9000 /9001, XP, DSDM/Atern
  • Newcomers (first appearance in the last few years and not yet dead): DevOps, IT4IT, Standard and Case. They might reach the plateau of producitivity one day or become obsolete

This is just observation. It’s up to you to make any conclusions.
As a side-note: Statistically, evergreens are actually still winners. An already infected community cannot be re-infected. This has an impact on search behaviour.

Geographical Differences

Doing a geographical analysis, I don’t see very much regional difference in popularity, with the following exceptions:

  • ISO 9000/9001: Although worldwide loss of popularity, it’s still unbroken popular in whole Latin America
  • SixSigma is rather popular in India, the US and some Asian Countries, but not in Europe
  • The UK (including the Scottish) & the Netherlands love Prince2
  • PMBOK is rather popular on the American Continent than in Europe or Asia

Again, I present here just the data. I leave it up to you to interpret it.

Keyword Drilldown

I picked a couple of frameworks & standards and looked into the related searches:

  • ITIL: It’s all about doing a certification or training. Top searches include ‘ITIL certification’, ‘ITIL foundation’, ‘ITIL training’, Prince2 goes into a similar direction
  • In contradiction to that, DevOps is rather about searches like ‘What is DevOps’ and ‘Reaction to DevOps’. DevOps is new and popular and people want to know more about it
  • Similar to that, searches on Cobit, Scrum, PMBOK, CMMI and other are very much related on the content of the respective framework

So this was just scratching on the surface. But I think there were some interesting observations. Try it yourself and do some research on Google Trends.

Gute Gründe für einen sicheren Weg in die Cloud

Computerleistung bei Bedarf zu erhalten, ohne dabei viel Verwaltungsaufwand zu betreiben, sind hervorragende Argumente für kostenbewusste Unternehmen. Mit dieser Virtualisierungstechnik bietet sich für Unternehmen nun eine Vielzahl von Implementierungsmöglichkeiten.

Mit Cloud Computing hat sich die Art und Weise wie Geschäftsprozesse umgesetzt, angewendet und gemanagt werden, wesentlich verändert. Die Veränderung kann mit dem Aufkommen des Personal-Computers verglichen werden, welcher die IT-Nutzung ebenfalls revolutioniert hat. Mit Cloud sind nun die wesentlichen Komponenten schneller und flexibler einsetzbar geworden. Einige der Treiber, welche die Aufmerksamkeit der Entscheidungsträger innerhalb der Unternehmen auf sich gezogen haben, sind:

  • Optimierte Ressourcennutzung: Die typischen Auslastungen von Serverrechnerleistungen liegt in Unternehmen durchschnittlich bei 15 bis 20 Prozent. Der Rest der vorhandenen und bezahlten Kapazität bleibt ungenutzt. Wenn nun ein Model zur Verfügung steht, bei dem Ressourcen nur bezahlt werden, wenn diese tatsächlich benötigt werden, dann ist damit ein fast perfektes Model zur Ressourcenoptimierung gefunden worden.
  • Kosteneinsparungen: Der Wechsel von eingekauften und gewarteten Rechnerleistungen hin zu gemieteten Cloud-Services hat einen Paradigma Wechsel von Investitionsausgaben (CAPEX) hin zu reinen Betriebsausgaben (OPEX) zur Folge. Es besteht ein Potential zur Einsparung von Gesamtkosten. Man denke nur an die Möglichkeiten von flexiblen Rechnerleistungen für Testzwecke ohne dabei erhebliche Investitionen tätigen zu müssen. Zudem wird durch die Verrechnung der effektiven Nutzungsleistungen der Kapazitätsbedarf transparent gemacht.
  • Erhöhte Reaktionsfähigkeit: Durch On-Demand (Bedarfsgestützt), agile, skalierbare und flexible Services, welche zudem noch in kürzester Zeit der Organisation bereitgestellt werden können, bieten Unternehmen Fähigkeiten, schnell auf veränderte Situationen und Spitzenzeiten reagieren zu können.
  • Schnellere Innovationszyklen: Durch die Verwendung von Cloud-Lösungen können Innovationen schneller abgewickelt werden, als wenn dies rein intern im Unternehmen durchgeführt würde. Oftmals ist ein Wechsel hin zu einer neuen Software-Version eine einfache Anpassung der URL-Adresse im Browser.
  • Reduzierte Implementationszeiten: Mit Cloud Computing können Rechnerleistungen und Datenspeicher nach effektivem Bedarf und quasi in Echtzeit zur Verfügung gestellt werden. Die Umsetzung intern dauert in der Regel Wochen und Monate und bindet sehr viel Investitionsbudget (CAPEX).
  • Zuverlässigkeit: Der Ausfall einer einzelnen Komponente in einem Cloud-basierten System hat eine kleinere Auswirkung auf die allgemeine Service Verfügbarkeit und reduziert damit das Risiko eines Totalausfalls. Gosse und kritische Systeme müssen intern oft mit sehr komplexen ausfallsicheren Mechanismen (High Availability Options) ausgestattet werden.

Je nach Anforderungen der Unternehmen genügen eines oder mehrere dieser Argumente, um Cloud-Computing als Alternative Lösung zu betrachten. Insbesondere wenn es um Kosteneinsparungen geht, ist das Modell des Pay-per-use, der nutzungsabhängigen Verrechnung bestechend. Aber jede Cloud Lösung hat nicht nur Vorteile, sondern auch Risiken zu betrachten. Die Unternehmen müssen die Chancen und Risiken abwägen, um entscheiden zu können, ob die Cloud eine valable Lösung ist.

Cloud-Service-Modelle

Cloud-Service-Modelle

Die Vorteile und Risiken im Zusammenhang mit Cloud Lösungen variieren auf Basis folgender Faktoren:

  • Art des Cloud Service Models: Software as a Service (SaaS), Platform as a Service (PaaS) oder Infrastructure as a Service (IaaS) und damit verbundene Service-Modelle wie Security as a Service (SecaaS), Storage as a Service (StaaS) usw.. Jedes Cloud Service-Modell adressiert unterschiedliche Geschäftszwecke und entsprechend unterschiedliche Risiken
  • Robustheit des bestehenden IT-Betriebs innerhalb des Unternehmens: Die Unternehmen müssen sicherstellen, dass ihre aktuelle Governance, Risiko Management und Informations-Security Enabler gut definiert und durch den bestehenden IT-Betrieb gesteuert werden. Mit der Cloud können neue Bedrohungen und Schwachstellen identifiziert werden. Aber wenn das Unternehmen vorbereitet ist und der IT-Betrieb in der Lage ist, diese Probleme entsprechend zu bearbeiten, dann ist das Gesamtrisiko für das Unternehmen niedriger zu erwarten.
  • Aktuelle Höhe der Geschäftsrisikoakzeptanz: Die Höhe des Risikos, welche ein Unternehmen bereit ist zu akzeptieren variiert zwischen Unternehmen und Branchen.
  • Aggregierter Wert der Daten, welcher in die Cloud verschoben werden sollen: Unternehmen müssen den Wert der Daten ermitteln, welcher diese für Menschen mit krimineller Absicht haben könnten.
  • Interne Sicherheits-Klassifizierung der Daten, welche in die Cloud gestellt werden sollen: Auch der interne Wert und Schutzbedarf der Daten soll ermittelt werden, um die Daten im Eigentum des Unternehmens zu belassen und nicht der Öffentlichkeit preisgeben zu wollen.
  • Die Compliance Verpflichtungen von geteilten Daten innerhalb der Cloud identifizieren: Daten, welche den persönlichen Datenschutz betreffen, oder Informationen des Finanzberichtes sind Beispiele, welche durch Compliance-Anforderungen speziell geschützt sind.
  • Cloud Service Provider (CSP) Risiken: Unternehmen sind gut beraten, eine Due Diligence bei potentiellen Cloud Service Providern durchzuführen. Da heute noch keine allgemeine und konsistente Sicherheitsstandards im Cloud-Umfeld gibt (es ist zurzeit ein Standard „ISO 37500 Guidance on Outsourcing“ in der Entwicklung), hat jeder CSP seine eigenen Ansätze und trüben so die Sicht auf die Sicherheit. CSPs sollen Best Practice Ansätze wie COBIT oder ITIL anwenden und international anerkannten Standards folgen.

 

Cloud-Risiken

Cloud-Risiken

Das Schlüsselelement in der Cloud heisst Vertrauen

Die kritischen Barrieren für Cloud Services sind Sicherheits- und Datenschutzbedenken. Cloud-Anwender und –Kunden können in Service Level Agreements (SLAs) festhalten, dass der Cloud Service Provider gewisse Kontrollziele einhalten muss. Letztlich kommt es aber immer auf das Schlüsselelement des Vertrauens an, was ein Kernelement im Cloud Computing Geschäftsmodell ist. Wenn das Vertrauen fehlt, dann können noch so viele Kontrollen definiert werden – die Bedenken würden nicht gemildert.

Bei der Berücksichtigung von Cloud Lösungen ist es daher eminent wichtig, alle Beteiligten und die Standorte zu kennen. Die Beteiligten beschränken sich nicht bloss auf den CSP und seine Mitarbeiter. Auch jene, welche mit dem Cloud Service Provider in Kontakt stehen und Service-Leistungen (zum Beispiel Support) bereitstellen. Es ist wichtig sicherzustellen, dass alle vertrauenswürdig sind. So zum Beispiel dass niemand in betrügerischen Tätigkeiten involviert ist und dass die Beteiligten finanziell abgesichert und solvent sind. Eine gute Regel ist, CSPs auszuwählen, welche bereits grosse Erfahrungen und eine entsprechende Cloud-Historie aufweisen können und zudem noch über solide Geschäftsreferenzen verfügen und zur Verfügung stellen.

Es braucht neue Skills: beim Provider wie auch beim Kunden

Nicht nur beim Cloud Service Provider CSP sondern auch beim Unternehmen, welcher diese Cloud Services bezieht, sind spezifische Fähigkeiten und Kompetenzen notwendig. Um ein Unternehmen professionell und sicher mit Cloud Diensten zu versorgen, sind Kenntnisse in folgenden Bereichen notwendig:

  • Prinzipien des Cloud Computing
  • Implementierung und steuern der Cloud
  • Nutzung der Cloud
  • Security und Compliance
  • Der Business Case bei der Evaluation von Cloud Computing
  • Lieferanten und Vertrags-Management

Bei Unternehmen, welche vermehrt Cloud Services im Einsatz haben, werden in Zukunft folgende Rollen immer zentraler:

a)     Cloud Service Owner

Er ist verantwortlich für den gesamten Lebenszyklus des Cloud Services, von der Service Strategie, Design, Transition (in und out) sowie dem Betrieb und der kontinuierlichen Verbesserung:

  • Managing des Cloud Service Portfolios
  • Repräsentation des Cloud Services im gesamten Unternehmen (Single Point of Contact)
  • Definition der Cloud Service Levels, Metriken und Messverfahren
  • Unterstützung der Prozessverantwortlichen im Umgang mit der Cloud (Managen der Unternehmensarchitektur, Service Level Management, Lieferanten Management, Risiko Management, Information Security Management)
  • Ausrichten des Cloud Service Management Modells auf die Governance der Unternehmens IT

b)     Cloud Service Manager

Der Cloud Service Manager ist für die Bereitstellung der Cloud Services zum Business gemäss SLA verantwortlich:

  • Reporting der Cloud Service Qualitätsparameter gegenüber Cloud Service Owner
  • Verantwortlich für die Abnahme der Service Akzeptanzkriterien zwischen Service Transition und Service Operation
  • Unterstützung bei der Definition der Service Level Agreements
  • Management der Cloud Administrations Rollen
  • Überwachung der Betriebs- und Support-Prozessleistungen (insbesondere Incident Management und Request Fulfilment, Problem Management, IT Service Continuity Management, Information Security Management, Availability und Capacity Management)

Service Management ist imme rnoch die Paradedisziplin. Die Management Anforderungen verschieben sich jedoch vom reinen Betrieb hin zu mehr Strategie und Governance. Lesen Sie dazu auch unsere früheren Beitrage:


 

 

Where to start with a Sourcing Governance Frame Work ?

Simple answer: Get yourself familiar with knowledge that is available. Basically, to build the knowledge for sourcing, outsourcing and related governance models, you would have to focus on the available knowledge sources.

Laws

First and foremost, you need to get to know local/national, laws under which any sourcing strategy is being defined and executed. For instance, if your company is headquartered in Switzerland, the “Bundesgesetz über den Datenschutz” would be a good starting point along with the “Verordnung zum Bundesgesetz über den Datenschutz”.  This law and its amendments are talking about the data protection rights of individual and juristic persons. If you consider to move part of your business abroad from your headquarter country, you need to consider the different intellectual property protection and data privacy rights at the locations you want to outsource to. If staff is affected by transitioning to an outsourcing service provider, you need to get yourself familiar with labor-law issues. In Switzerland, Art. 333 of the Swiss Code of Obligations (SCO – liability in the event of transfer of employment relationships) kicks in.

Industry Regulations

Based on national laws, certain industries are bind to some more granular regulations. In Switzerland, Financial Institutes have to act according to the bank secrecy law “Bankgeheimnis”. This law is triggering additional regulations for banks in the case of outsourcing. The Swiss Financial Market Supervisory Authority (FINMA) has released the circular “Outsourcing Banken” which describes the conditions under which outsourcing has to be performed.

finma

Any sourcing strategy definition and execution of a bank in Switzerland need to have controls in place to adhere to this paper.

International Standards

Over the centuries, industries and branches have developed standards and norms of operation. ISO/IEC 38500 is an international standard for corporate governance of information technology. It provides a framework for effective governance of IT to assist those at the highest level of organizations to understand and fulfill their legal, regulatory, and ethical obligations in respect of their organizations’ use of IT. Any sourcing governance should be based on this standard.  To execute a sourcing strategy, a new norm will support standards for the outsourcing process in information technology: ISO/DIS 37500 (Guidance on outsourcing) is being drafted and under review – to be officially released 2015.  This norm is referencing a number of other ISO Standards very well known in information technology:

  • ISO 31000, Risk management
  • ISO 21500, Guidance on project management
  • ISO 9001, Quality management system
  • ISO/IEC 20000 Information technology – Service management
  • ISO/IEC 27001 Information technology – Security techniques
  • ISO 19011, Guidelines for auditing management systems.

iso

International Frame Works

Especially for information technology, a number of established “best practice” frame works support the definition and execution of sourcing strategies. COBIT 5.0 is certainly the most comprehensive and complete frame work covering governance and management of information technology – supporting any form of sourcing.  Besides of the generic COBIT 5.0 frame work, there is a number of dedicated sourcing documents being released by the organization (ISACA) responsible for COBIT, i.e:

Very well known in IT is ITIL v3©. This frame works helps service providers and customers to define process responsibilities, activities and interfaces in service operations. In addition, the service transition from customer to the external service provider is being supported by processes and process outcomes (i.e. service acceptance criteria, knowledge management). The frame work’s service design processes are the base for the definition and execution of service requirements and service quality parameters throughout the souring life-cycle.

Maturity Assessments

Part of the execution of a sourcing strategy should always be an assessment about the sourcing capabilities of an organization. There exists more generic assessment frame works in IT not necessarily dedicated to sourcing (i.e COBIT Process Assessment Model (PAM), TIPA or CMMI). A specialized sourcing assessment would be the eSourcing Capability Model. This a framework has been developed by ITSqc at Carnegie Mellon University in order to improve the relationship between IT Services providers and their customers. The eSCM is twofold: eSCM-CL for Clients and eSCM-SP for Service Providers. These two models are consistent, symmetrical and complementary for each side of the client-provider relationship and this is the strength and the uniqueness of this model.

Trainings and Certifications

International de facto standard for training and certifications related to outsourcing is the Sourcing Governance Foundation course. It provides basic knowledge of what the main concepts of Outsourcing and Sourcing Governance are and how they can be applied. Best practice shows that implementing and operating a Sourcing Governance Function will require staff awareness and understanding of the key principles and concepts of outsourcing and sourcing governance. In this course an interactive approach is used combining lecture, discussion and exercises.

APMG-International has created the Sourcing Governance Foundation certification in conjunction with International Association of Outsourcing Professionals® (IAOP®).

Undertaking the course and successfully passing the examination qualifies an individual for COS-FP (Certified Outsourcing Specialist™ – Foundation Principles) certification from the International Association of Outsourcing Professionals® (IAOP®).

In Switzerland, the University of St. Gallen has been released a program “Certificate of Advanced Studies (CAS) in Sourcing and Cloud Management” this year. Focus is the definition and execution of sourcing strategies.

KBS

In essence

There is a lot of knowledge available as a good starting point for any company considering souring as an option for its future business. This knowledge needs will be a fundamental part of the organizational capabilities for any successful sourcing.

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“:


 

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.