DevOps, Agilität und SAFe®- wie alles zusammenhängt und nicht zusammen passt.

Generelles zu DevOps

DevOps ist kein Selbstzweck, sondern es soll ein Problem lösen: Die Minimierung von Reibungsverlusten zwischen Entwicklung und Betrieb bei der Produktivsetzung von Software-Releases. Und da wir schon dabei sind, würden wir auch gleich agil produzierte Produktinkremente in rascher Folge produktiv setzen wollen – zumindest dort, wo es denn Sinn macht. Das Mittel der Wahl ist Automatisierung. D.h. des Continuous Integration und Continuous Deployment bis hin zum „Deployment-on-Click) – neben den generellen CALMS-Prinzipien, die auch „weiche“ Faktoren wie „Culture“ und „Sharing“ beinhalten.

Um DevOps effizient durchführen zu können, sollte man sich an das Deployment kleiner Produktinkremente gewöhnen. Diese lassen sich im Rahmen einer automatisierten Integration und eines automatisierten Deployment leichter handhaben als Riesen-Releases.

In meinem Buch DevOps-Strategies habe ich meine Erfahrung bei der DevOps-Einführung in eine Organisation zusammengefasst. In einer kommenden Ausgabe des Buches werde ich den Fokus wohl schärfen und hervorheben (müssen), dass DevOps ohne wirkliche Agilität ein hohes Risiko des Scheiterns beinhaltet und somit letztendlich unwirtschaftlich ist.

Man könnte es überspitzt so formulieren, dass nur „agile“ Organisationen sinnvoll DevOps betreiben können.

Das fängt bereits damit an, dass der Aufbau von CD- und CI-Pipelines parallel und iterativ zur Erstellung der funktionalen Software erfolgen sollte – auch die CALMS-Prinzipien lassen sich am besten mit dem agilen Manifest in Einklang bringen.

DevOps im SAFe® – Kontext

Nun dreht das Scaled Agile Framework (SAFe®) den Spieß allerdings um: SAFe® postuliert den Einsatz von DevOps bereits bei der Einführung des kleinsten gemeinsamen Nenners von SAFe® in einer Organisation, dem „Essential SAFe®“. Dieser Kern von SAFe® umfasst neben der Team-Ebene, in der sich herkömmliche SCRUM-Teams tummeln, eine übergeordnete Programm-Ebene, in der die Aktivitäten mehrerer SCRUM-Teams in sogenannten „Agile Release Trains“ koordiniert werden. Dazu gehören „Super Sprints“, die aus mehreren herkömmlichen agilen „SCRUM-Sprints“ bestehen.

SAFe® fordert nun nicht nur, dass am Ende eines Super Sprints eine Programm Inkrement erzeugt wird, sondern dass der Fortschritt eines Super-Sprints permanent einer Validierung unterzogen werden können muss. Dies soll auf der Basis automatisierter Tests und Deployments geschehen. Die SAFe®-Dokumente sprechen deshalb auch von DevOps. So nachvollziehbar dies auch ist, wird es fü viele Unternehmen auf eine hohe Hürde bei der SAFe®-Einführung hinauslaufen.

DevOps überall

Der allgegenwärtige Anspruch, DevOps einführen und anwenden zu wollen, ohne sich auf agile, und damit letztendliche nicht vorkommende Planbarkeit einzulassen, ist symptomatisch. Agilität besteht aus mehr als Sprints und Daily Scrums.

Es werden in letzter Zeit alle erdenklichen Rollen mit dem Begriff Dev-Ops „geschmückt“, z.B. „DevOps-Administrator“, „DevOps-Entwickler“.

Offensichtlich fordert das Senior Management die Einführung von DevOps ein, um „endlich“ das Problem mit dem Produktionsübergang in den Griff zu bekommen.

Folglich klebt das folgsame mittlere Management das Label „DevOps“ auf alles und jeden, um zu dokumentieren, dass man die DevOps-Vorgabe des Senior Managements ernst nimmt,  – und überhaupt – es möchte ja  jeder ein Teil der Lösung sein, und die heißt „DevOps“. Denn ansonsten wäre man ja Teil des Problems, oder?

Die Folge: Dadurch, dass das Label DevOps mit und ohne Überzeugung auf alles geklebt wird, was nicht bei „drei auf den Bäumen“ ist, glauben alle Beteiligten irgendwann selbst daran, dass sie tatsächlich „DevOps machen“, und  vergessen darüber den agilen Unterbau und den eigentlichen Anspruch, den man an DevOps haben sollte.

Als Ergebnis dieser Entwicklung steht DevOps am Ende im besten Fall für gepflegtes Scripting und Automatisierung von Deployment-Vorgängen. Im schlechtesten Fall wird DevOps diskreditiert – als Worthülse mit einer übertriebenen Erwartungshaltung.

Ein Dialog:

  • Vorgesetzter: Bis wann werden wir das Deployment-on-Click auf allen Umgebungen up-and-running haben?
  • Mitarbeiter: Sobald wir DevOps eingeführt und unsere Continuous Delivery Pipeline fertiggestellt haben.
  • Vorgesetzter: Aber wir haben doch DevOps aufgebaut (Siehe Vorstands-Memo vom ….)
  • Mitarbeiter: Wo?
  • Vorgesetzter: Na Dich – wir haben Dich Doch als „DevOps-Engineer“ vor zwei Monaten eingestellt, wird schon automatisch ausgerollt?

Author: dibcon

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.