Service Management – ein Grundpfeiler von DevOps und Agile

Service Management – ein Grundpfeiler von DevOps und Agile – aber wie geht das denn nun?

 

Wie in meinen letzten Beitrag angekündigt, möchte ich heute kritisch hinterfragen, inwieweit bewährte Standards und Methoden zur gewünschten Zusammenarbeit zwischen Entwicklung und Betrieb (DevOps) geführt haben. Konnten die Silos aufgebrochen werden und arbeiten die Teams an gemeinsamen Zielen? Falls noch Handlungsbedarf besteht, was wären mögliche Lösungsansätze?

 

Bevor wir die Frage beantworten, ob und wie unterschiedliche Frameworks eingesetzt werden können und sollen, müssen wir uns noch einmal die ursprüngliche Zielsetzung von DevOps vor Augen führen.

 

«Stellen Sie sich eine Welt vor, in der Product Owner, Entwicklung, Qualitätssicherung, IT-Betrieb und InfoSec zusammenarbeiten, nicht nur, um sich gegenseitig zu helfen, sondern auch, um sicherzustellen, dass die gesamte Organisation erfolgreich ist. Indem man auf ein gemeinsames Ziel hinarbeiten, ermöglicht das den schnellen Fluss der geplanten Arbeit in die Produktion und erreicht gleichzeitig Stabilität, Zuverlässigkeit, Verfügbarkeit und Sicherheit von Weltklasse.» – Das DevOps Handbuch

 

Nach wie vor stellt diese Vision viele IT-Organisationen vor Herausforderungen. Der Abbau der über Jahre aufgebauten Silos und hierarchisch gewachsenen Funktionseinheiten gestaltet sich trotz allgemeinem Verständnis und Überzeugung, als schwierig.

Und Hand aufs Herz, hat sich die Zusammenarbeit zwischen IT-Betrieb und Entwicklung so weit verbessert, dass die im Phoenix Projekt beschriebene Abwärtsspirale bei Ihnen kein Thema mehr ist?

 

DevOps ist bekanntlich die Kombination aus den zwei Wörtern, Development (Entwicklung) und Operations (Betrieb). Ohne den DevOps-Ansatz erleben wir Spannungen zwischen denen, die neue Funktionen entwickeln, und denen, die die Stabilität der Lösung in der Produktion aufrechterhalten (siehe Wall of Confusion).

 

Die Entwicklungsteams werden an dem Business Value gemessen, den sie den Endbenutzern liefern, während das IT-Servicemanagement an der Qualität und Stabilität der Produktionsumgebung gemessen wird. Weil jede Gruppe scheinbar gegensätzliche Geschäftsziele hat, können Ineffizienz bei der Bereitstellung und organisatorische Reibungsverluste die Regel sein.

 

Zwischenzeitlich ist die Notwendigkeit zur Veränderung in der Zusammenarbeit in allen Organisationseinheiten (Silos) angekommen. Um im digitalen Zeitalter wettbewerbsfähig zu sein und wachsen zu können, müssen Unternehmen schnell auf Marktveränderungen und Chancen reagieren können. Dies erfordert, dass alle, die an der Bereitstellung von Lösungen beteiligt sind schlanke und agile Praktiken nutzen, um kontinuierlich innovative, qualitativ hochwertige Produkte und Dienstleistungen schneller als die Konkurrenz zu liefern.

 

Das haben wir ja zwischenzeitlich Alle begriffen, aber warum hapert es dann noch mit der Umsetzung?

 

IT-Operation (IT OPS) ist von Natur aus Ticket gesteuerte Arbeit. Das ist etwas ganz anderes als Software-Entwicklungsprojekte, bei denen eine Initiative durch ein Portfolio getrieben wird. In der Welt der IT OPS gibt es Arbeit, die schnell erledigt werden muss, und Arbeit, die jetzt erledigt werden muss. Dies führt dazu, dass IT OPS oft noch wenig in agile Initiativen eingebunden ist.

 

 

Bei den agilen Entwicklungsteams vermittelt IT OPS oft den Eindruck sich hinter unsäglichen Prozessen und Kontrollen zu verstecken. Wohingegen bei IT OPS sich die Meinung verfestigt, dass die agilen Teams sich nicht um Vorgaben und Regulatorien zu scheren. Dabei liegt der Erfolg von DevOps gerade in der Integration unterschiedlicher Rahmenwerke und Methoden wie beispielsweise IT-Service Management (ITSM). ITSM-Prozesse sind für Unternehmen, die diesen Erfolg erreichen wollen, von entscheidender Bedeutung. DevOps eliminiert nicht den Bedarf an Kontrollen und Daten. Regulatorische Kontrollen und Audits gibt es immer noch, und Risiken und Auswirkungen müssen auch zukünftig bewältigt werden.

 

Damit IT OPS den erforderlichen Beitrag in agilen Projekten leisten kann muss es die Maturität der Service Management Prozesse erhöhen und die Abläufe automatisieren.

 

Ein Ansatz für die Umsetzung liefert das Agile Service Management (Agile SM). Agile SM stellt sicher, dass ITSM-Prozesse die agilen Werte widerspiegeln und mit «gerade genug» Kontrolle und Struktur gestaltet werden, um effektiv und effizient Dienstleistungen zu erbringen, die den Kunden die Ergebnisse erleichtern, wann und wie sie benötigt werden. Agile SM erfindet ITSM nicht neu – es modernisiert den Ansatz indem es:

• Agile Praktiken an das ITSM-Prozessdesign adaptiert
• Service Management in kleinen, iterativen Schritten implementiert
• Sicherstellt, dass ITSM-Prozesse Agile Werte vom ersten Entwurf bis zur CSI widerspiegeln
• Zu «minimal durchführbaren» und «gerade genug» Prozessen, um Geschwindigkeit und Konformität zu erhöhen, ermuntert

 

Nun müssen wir aber schon noch die skalierte Agilität anschauen. In meinem letzten Blog habe ich das Thema Business Agilität und SAFe vorgestellt. Das Scaled Agile Framework ist (SAFe) ist neben LeSS eines der verbreitetsten Frameworks, um Scrum bzw. Agil zu skalieren. SAFe baut auf Lean auf und bietet ein agiles Framework für die Ebene der Teams, der Programme und der gesamten Organisation (Portfolio-Ebene).

 

Bedauerlicherweise gibt es nicht das eine Framework mit dem wir alle unsere Herausforderungen lösen können.

 

Damit die Organisationseinheiten Entwicklung (Dev) und IT-Betrieb (Ops) ohne Reibungsverluste zusammenarbeiten können müssen wir auch die unterschiedlichen und im Einsatz befindlichen Frameworks berücksichtigen.

 

Sind denn nun SAFe und ITIL Freunde oder Feinde?

 

Auch hier erleben wir oft genug wie die Organisationseinheiten, Entwicklung und Betrieb das kämpften, was man auch als “Religionskrieg” bezeichnen könnte. Entwicklung in der Welt von Scaled Agile (SAFe) und Betrieb mit ITIL. Verschiedene Planeten. Oder doch nicht? Wenn wir uns zusammensetzten und uns die Leitprinzipien sowohl von SAFe als auch von ITIL genau anschauen kommen wir zum Schluss, dass sie tatsächlich viel enger aufeinander abgestimmt sind, als man das erwartet hätte.

Gehen wir nun einmal davon aus, dass sowohl DevOps, SAFe und ITIL weiterhin sinnvoll miteinander eingesetzt und betrieben werden sollen. Um die Brücke zwischen Entwicklung und Betrieb zu schlagen fordern wir mehr Zusammenarbeit zwischen den beiden Welten.

 

Mit ein wenig «Good will» und Kreativität lassen sich die Frameworks gut kombinieren. Dies veranschauliche ich gerne mit einem Beispiel.

 

 

Der kontinuierliche Ausbau und die Weiterentwicklung der Service Management Kompetenz sowie der notwendigen Automatisierung muss heute in enger Zusammenarbeit durch agile (abteilungsübergreifende) Teams erfolgen.

Dabei ist auch zu beachten, dass solche, für das Unternehmen wichtige Themen, auf Führungsstufe entschieden und beauftragt werden müssen. Gemäss SAFe würden solch strategische Themen auf der Portfolio Ebene priorisiert.

Die Umsetzung, beispielsweise einzelner ITIL Praktiken, würden auf der Programmebene anschliessend priorisiert und dann in Form von User Stories in den Programm Inkrementen, auf der Teamebene umgesetzt.

Tatsächlich erleben wir, dass durch den konsequenten Ausbau und die Automatisierung von Service Management die Silos Entwicklung (Dev) und Betrieb (OPS) aufgebrochen werden können

 

Liegt es nun an den fehlenden oder unzulänglichen Standards und Methoden, warum einige Organisationen noch nicht wie gewünscht harmonieren? Ganz ehrlich, gute und bewährte Methoden wie man etwas macht gibt es mehr als genug. Ich bin der Meinung, dass jede Organisation aus der Vielfalt von Frameworks die für sie richtigen Werkzeuge herausnehmen, sich zu Nutze machen und anschliessend konsequent anwenden sollte.

Google hat sich dem Thema vor Jahren bereits angenommen und betrachtet auch den Betrieb als Software Engineering Herausforderung.

Auf der Basis-Ebene bringen SREs Software-Engineering-Prinzipien in Infrastruktur- und Betriebsstörungen ein, mit dem ehrgeizigen Ziel, hochskalierbare und zuverlässige Systeme zu schaffen.

Doch das ist auch nur ein Teilaspekt des komplexen Konstrukts und ist auch kein Allheilmittel, das für alle «Horses» und «Unicorns» passt.

Es bleibt spannend, doch von einer Sache bin ich absolut überzeugt:

 

Agilität ist die dabei richtige Vorgehensweise!

 

Euer Ralf Winter