Über unsMediaKontaktImpressum
David Koenig 12. März 2024

DevOps: Ist Euer Qi im Einklang?

Über "Warum?", "Wie?" und "Was?" bei DevOps kann der geneigte IT-Mitarbeiter und Manager nach wie vor trefflich streiten. In meiner Laufbahn hatte ich die Möglichkeit, Hunderte von Personen zum Fortschritt ihrer DevOps-Transition zu interviewen, ein Ergebnis war bei allen Unternehmen das gleiche: Es besteht eigentlich in den wenigsten Unternehmen eine Einigkeit darüber, wo es überhaupt steht. Diese Uneinigkeit besteht nicht nur auf Ebene der Gesamtorganisation, sondern auch innerhalb von Abteilungen und sogar kleinen schlanken Entwicklungsteams. Leider ist das immer schwer zu fassen und zu beschreiben. In meiner Rolle als Berater befinde ich mich öfters in Situationen, in denen mir bewusst wird, dass etwas nicht stimmt. Die bestehenden Probleme allerdings in Worte zu fassen, fällt auch mir als neutralem Beobachter oft schwer.

Irgendwann kam mir der folgende Gedanke: Eigentlich ähnelt ein Unternehmen dem menschlichen Körper. Dieser funktioniert und macht alles, was er soll. Er kann ein Bein vor das andere setzen, atmen, sprechen und Nahrung aufnehmen. Aber beschränkt man die Menschen auf ihre reine Funktionalität, gäbe das doch ein trauriges Bild ab. Richtig gut geht es dem Menschen, wenn er mit sich und seiner Umwelt im Gleichgewicht ist. Wenn er regelmäßig an der frischen Luft ist, ab und an Sonne tankt, Freunde und seine Familie um sich herum hat und Gefühle sowie Emotionen im Einklang sind. Die traditionelle chinesische Medizin beschreibt dies damit, dass unser "Qi" (oder auch "Ch’i") im Einklang ist.

Auch im Unternehmen gibt es das Qi und es sollte spätestens dann Beachtung finden, wenn das Unternehmen beginnt, sich mit DevOps zu beschäftigen. DevOps ist eben nicht nur einfach eine Technologie oder Lösung, wie es uns viele Hersteller versuchen zu vermitteln, sondern eine Mischung aus Kultur, Organisation und Technologie, die mal mehr oder mal weniger gut im Einklang sind. Keine Angst, ich werde jetzt nicht versuchen, eine esoterische Beschreibung für den Zustand Deiner Unternehmenskultur zu verfassen, dazu habe ich auch gar keine Kompetenz. Aber dieser Vergleich hilft uns dabei, zu verstehen und zu beschreiben, was in unserem Unternehmen in einem der drei Bereiche Kultur, Organisation und/oder Technologie schiefläuft.

Was sind die Konsequenzen, wenn ich mein DevOps-Qi ignoriere?

Tatsächlich führt ein unausgeglichenes DevOps-Qi nicht nur zu irgendwelchen suboptimalen Prozessen, die aber doch irgendwie funktionieren. Ganz im Gegenteil: Im schlimmsten Fall kann es zu einer ernsten Erkrankung des gesamten Organismus führen. Am Ende verliert ein Unternehmen nicht nur messbar Geld damit, dass diese Diskrepanzen nicht behoben werden, sondern etabliert auch diverse Risiken und verliert seine wertvollsten Mitarbeiter. Zwei Beispiele gefällig?

  • Entwicklerteams bauen aus diversen Gründen ihre eigene Plattform und das dafür notwendige Know-how auf, anstelle die interne IT mit einzubinden und/oder ein Plattformteam zu schaffen. Ergebnis: 20 Entwicklerteams, die alle auf unterschiedliche Art und Weise Kubernetes aufbauen und betreiben.
    Selbstbild der Teams: Wir machen DevOps in Reinform. Wir betreuen end-to-end von der Plattform bis zur Applikation.
    Risiko: Keine zentrale Wartung der Umgebung, keine Etablierung von Sicherheitsstandards auf der Plattform, hohe Kosten durch Aufbau des gleichen Know-hows und der gleichen Ressourcen in verschiedenen Teams.
  • Operations-Abteilungen bauen VMs auf Basis von incident-basierten Aufträgen in der Cloud auf, die wie klassische virtuelle Maschinen im On-Prem-Rechenzentrum verwendet werden.
    Selbstbild des Teams: Wir machen ja DevOps. Wir erhalten Aufträge und führen das Änderungsmanagement mit Hilfe eines GitOps-basierten Ansatzes durch.
    Risiko: Applikationen werden genauso wie in den letzten 20 Jahren einfach weitergeführt, ohne die Architekturen auf den Prüfstand zu stellen und zu modernen cloud-basierten Ansätzen zu überführen.

Diese beiden Beispiele zeigen deutlich, wie eine Abteilung durchaus völlig zu Recht sagen kann, sie mache DevOps. Sie hat Ansätze aus der DevOps-Welt etabliert und lebt diese. Auf unseren Organismus gemünzt bedeutet dies: Ja, wir können gehen und atmen und machen vielleicht sogar ein bisschen Sport, damit es uns gut geht. Aber trotzdem geht es uns nicht gut. Wir sind nicht fit oder glücklich und können uns nicht erklären, warum das so ist.

Bevor wir anfangen

Wir werden in den folgenden Kapiteln an ziemlich vielen Stellen Deiner IT-Organisation rütteln. Natürlich kannst Du sofort damit loslegen und mit dem Fokus auf einzelne Teams schon viele Dinge finden und beheben, die im Ungleichgewicht sind. Es reicht aber oft nicht, eine Salbe aufzutragen, einen Wadenwickel zu machen oder eine Stunde früher schlafen zu gehen (auch wenn solche einfachen Maßnahmen oft Wunder bewirken). Wir werden hier immer wieder über Themen sprechen, die den gesamten Organismus betreffen, längere Heilungsprozesse nach sich ziehen und Änderungen in Deinem gesamten Umfeld notwendig machen. Wenn ich mein Qi in Einklang bringen möchte, muss der Kopf dabei mitmachen. Suche Dir also von Anfang an die richtigen Sponsoren im Unternehmen. Mache die Heilung deines Qis zur Chefsache. Mache klar, dass dieses Projekt nicht in zwei Monaten abgeschlossen ist, sondern ein kontinuierlicher Prozess ist.

Der Basis-Check

Du kennst wahrscheinlich die klassischen KPIs aus dem DevOps-Umfeld. Die wichtigsten und am häufigsten genutzten sind wohl die folgenden vier:

  • Mit der "Lead Time for Changes" messen wir die Durchlaufzeit von einer Code-Änderung zur Produktivsetzung,
  • mit der "Change Failure Rate" die prozentuale Fehlerrate, mit der durch Code-Änderungen weitere Fehler erzeugt werden.
  • Mit der "Deployment Frequency" wird festgestellt, wie häufig Code in die Produktion eingespielt wird.
  • Mit der "Mean Time to Recover" wird gemessen, wie lange es dauert, einen Fehlerzustand in der Produktion wieder betriebsbereit zu bringen.

Aber helfen diese Messwerte wirklich dabei, die Schwachstellen der oben genannten Beispiele aufzudecken? Wahrscheinlich ist genau das Gegenteil der Fall. Sowohl die Entwicklungs- als auch die Operationsteams werden im besten Fall einen Anstieg dieser vier Werte verzeichnen können. Schließlich deployt ein Entwicklungsteam erst einmal relativ schnell, wenn es die volle Kontrolle über ein Kubernetes-Cluster hat. Die Tatsache, dass bei diesem Cluster aber Sicherheits-Patches fehlen oder Firewall-Regeln gesetzt sind, die nicht an das Unternehmensnetzwerk angepasst sind, fällt dabei erstmal nicht auf. Letztlich wird auch der Fakt verdeckt, dass 20 Entwicklungsteams zwar alle eine höhere "Deployment Frequency" aufweisen, aber jedes Team individuell einen enormen Aufwand betrieben hat, um eine annähernd identische Infrastruktur aufzubauen, die zentral deutlich schneller und kostengünstiger aufgebaut hätte werden können.

Diese grundsätzlichen Messwerte sind natürlich wichtig. So wie wir die Schulmedizin zur Kontrolle unserer Körperfunktionen benötigen. Wir machen EKGs und Bluttests, um festzustellen, ob alles in Ordnung ist, unsere Leistungsfähigkeit erhalten oder sogar gesteigert wurde. Aber dann hört die Schulmedizin irgendwann auf und wir müssen Mittel und Wege finden, einen Blick auf den Rest unseres Wohlbefindens zu werfen.

Als Erstes kommt die Anamnese

Ein gewissenhafter Heilpraktiker oder Arzt wird sich wahrscheinlich länger und ganzheitlich mit Dir beschäftigen, wenn Du ihn aufsuchst. Es werden Probleme besprochen, die nicht so offensichtlich sind wie ein gebrochenes Bein oder Masern, welche aber einen großen Einfluss auf Dein Wohlbefinden haben. Es wird eine Anamnese erstellt, die möglichst viele Details über Dich und Dein Umfeld enthält, wie Vorerkrankungen, Allergien, Arbeitsumfeld, Gewohnheiten etc. Auf gleiche Weise gehst Du vor, wenn Du eine DevOps-Anamnese von Deinem Unternehmen erstellen möchtest. Sie soll greifbar und sichtbar machen, was sich bisher im Verborgenen abgespielt hat. Und genau wie bei einem Arztbesuch macht es Sinn, sich einen externen neutralen Beobachter mit ins Boot zu holen.

Damit aber nicht gleich mit Kanonen auf Spatzen geschossen wird, empfiehlt es sich, mit leichter Kost einzusteigen. Ich führe die Unternehmens-Anamnese in kleinen Schritten durch und steigere bei jedem Schritt den Anspruch. Hier gibt es ein paar Regeln und Tipps, die wichtig für den Erfolg sind:

  • Erarbeite Ergebnisse – wenn möglich – teamübergreifend und transparent. Arbeite mit Plakaten oder geteilten Online-Boards, die jedem zugänglich sind. Wenn Du Probleme mit dem Rücken hast, kann die Ursache eine Fehlbildung im Knie sein. Solche Dinge sind im übertragenen Sinne feststellbar, wenn sich die Teams über den Status Quo unterhalten können.
  • Mache nicht zu viele Vorgaben. Lasse Freiraum für Spekulation. Erkläre nicht alles. Wenn Du bis ins letzte Detail erläuterst, was Du erwartest, wenn Du über Thema XY sprichst, nimmst Du den Leuten die Möglichkeit der Interpretation und des gemeinsamen Gestaltens.
  • Sei fair, erwarte keine Perfektion und kommuniziere diese Haltung. Es ist vollkommen okay, nicht "gut" in einem Thema zu sein. Es ist oft sogar gar nicht möglich. In vielen Projekten ist beispielsweise Continuous Deployment gar nicht machbar.
  • Feedback wird immer bezogen auf den "eigenen" Dunstkreis erhoben. Es ist einfach zu sagen: "Wir haben eine schlechte Kultur im Unternehmen." Ganz anders sieht es aus, wenn ich sagen muss: "Ich nehme eine schlechte Kultur in meinem Team wahr."
  • Dieser Prozess zieht sich über einen längeren Zeitraum, macht mit einem einheitlichen Style, einem Logo und immer wiederkehrenden Grafiken klar, dass es sich immer um dasselbe Projekt handelt.
  • Nutze eine klare Sprache in Wort und Bild. Ich verwende gerne Tiere, um die Geschwindigkeit zu visualisieren. Dies schlägt sich auch im täglichen Sprachgebrauch nieder ("Hey, wir sind Katzen, wo steht Ihr?"). Wenn Du dies erreichst, hast du die DevOps-Reifegradanalyse (aka Anamnese) zu einem Teil Deiner Unternehmenskultur gemacht.

Grundsätzliche Gesundheitsdaten

Fangen wir mit den grundsätzlichen Gesundheitsdaten des Patienten an. Der "Patient" ist hier keine einzelne Person oder ein einzelnes Team, sondern die (IT-)Organisation als Ganzes. Es bietet sich an, in diesem ersten Schritt einmal zu prüfen, wie die Meinung der Mitarbeiter zu den Themen "Technologie/Automatisierung", "Kultur" und "Organisation" ist. Aber auch "Architektur" oder "Sicherheit" können interessante Bereiche sein.

Interpretieren der Daten

Nun ist es wichtig, mit den Ergebnissen dieser Erstanamnese auch etwas anzufangen. Aus diesem Bild lassen sich verschiedene Erkenntnisse gewinnen. Fassen wir diese einmal zusammen:

  1. Offensichtlich sind die Teams sich sehr einig darüber, wie es bei ihnen um die Automatisierung ihrer Tasks steht. Das rote und das blaue Team scheinen recht zufrieden mit ihrem Stand zu sein, im grünen Team scheint es relativ viele manuelle Tätigkeiten zu geben.
  2. Über die Kultur gibt es offensichtlich keine Einigkeit. Hier muss wohl geklärt werden, was mit der "Kultur" eigentlich gemeint ist, da die Punkte auch innerhalb der Teams recht verteilt sind. Zudem sollte ich das Gespräch mit dem grünen und dem blauen Team suchen, um herauszufinden, welche Probleme es da geben mag. Vielleicht bringen zwei Personen des grünen Teams da ihre Unzufriedenheit über die vielen manuellen Tätigkeiten zum Ausdruck?
  3. In der Architektur sind sich die Teams im Großen und Ganzen auch einig. Das blaue Team ist allerdings auffällig geteilt. Haben da vielleicht Scrum Master und Product Owner ein anderes Bild als die Entwickler im Team?
  4. Bei der Organisation herrscht völliges Chaos. Auch hier kann angenommen werden, dass den Leuten nicht klar war, was eigentlich mit der Frage nach der Organisation beantwortet werden sollte. Oder vielleicht erkennen einige große Verbesserungspotentiale und andere nehmen den Status Quo einfach hin?

Ich betone es nochmal: Wichtig ist zu akzeptieren, dass es keine perfekten Ergebnisse gibt. Lass hier gerne Unschärfen zu und gib Raum für Spekulation. Nur dann bekommst Du die Leute auch dazu, sich zu öffnen, eine Meinung zu äußern und regst vielleicht sogar schon erste Diskussionen im Team an.

Und wenn wir gerade bei Diskussionen sind: Verstecke dieses Plakat nicht. Hänge es auch eine Weile nach der Veranstaltung gut sichtbar aus. Wenn Du mit Remote-Teams arbeitest, fotografiere die Ergebnisse und stelle diese jedem Mitarbeiter zur Verfügung, mit der Aufforderung, darüber im Team zu diskutieren. Wenn Du schon während der Veranstaltung die Möglichkeit hast, mit den Teams in Kontakt zu kommen und über die Ergebnisse zu sprechen – umso besser.

CI/CD-Gesundheit

Nach dieser ersten Runde hast Du ein ungefähres Bild davon, wie es grob um das Verständnis einzelner Themen im Unternehmen bestellt ist. Werden wir nun etwas konkreter. Wir möchten ja das DevOps-Qi analysieren. Also konkretisieren wir nun die Fragestellung und schauen uns mal die CI/CD-Prozesse an. Im Gegensatz zur ersten "Umfrage" müssen wir auch mehr Input liefern. Vielleicht ist nicht jedem Mitarbeiter klar, was der Unterschied zwischen Continuous Delivery und Continuous Deployment ist. Daher macht es auf jeden Fall Sinn, in einfachen, klaren Sätzen zu erläutern, was in jeder Phase zu erwarten ist.

An dieser Stelle ist es nützlich, die ersten Kontrollfragen einzubauen. Genau genommen sollen sich der "regular Output" und die Einordnung in den Phasen immer einigermaßen decken. Läuft das arg auseinander, weißt Du, dass es hier entweder Verständnisprobleme oder eklatante Implementierungsprobleme gibt (z. B. Software wird ungetestet in Produktion deployt). Diese Kontrollfragen werden wir auch im weiteren Verlauf immer wieder mit einbauen.

Auswertung der Erkenntnisse

Beschäftigen wir uns mit den gewonnenen Daten:

  • Ganz ähnlich wie in der ersten Auswertung ist man sich im grünen Team nicht so ganz einig darüber, wo man steht. Dies unterstreicht, dass in diesem Team dringender Handlungsbedarf besteht.
  • Auch scheint im grünen Team nicht klar zu sein, worum es bei den Releases geht. Vielleicht betreut das Team eine 3rd-Party-Software mit ein wenig Customizing und führt einfach nur ein manuelles Update in Produktion aus? Vielleicht gibt es keine Testumgebung oder Testprozesse?
  • Im roten und blauen Team sind die Kollegen auf jeden Fall schon mal enger beieinander. Im roten Team kann es sein, dass mal geklärt werden muss, was das Verständnis einer Testumgebung ist. Vielleicht sind einige Kollegen der Meinung, dass dies die teaminterne Entwicklungsumgebung ist?
  • Im blauen Team scheinen die ersten schon darauf zu schielen, dass Updates direkt in Produktion gehen, während einige noch gar nicht den Einsatz einer Testumgebung sehen.

Grundsätzlich scheint sich dieses fiktive Unternehmen aber im guten Mittelfeld aufzuhalten und alles in allem ist das Bild hier etwas klarer als in der Umfrage zuvor.

Starte mit der Heilung

Nach diesen beiden Umfragen kannst Du erste sinnvolle Maßnahmen ableiten, um dein DevOps-Qi in Balance zu bringen. In der Mehrheit aller Projekte, die ich gesehen habe, konnte ich feststellen, dass ein einheitliches Bild über DevOps nicht existiert. DevOps ist eben nicht nur ein Stück Software, ein Produkt oder CI/CD, sondern ein gemeinsames Verständnis davon, wie Software zur Verfügung gestellt werden sollte. Dies umfasst:

  • kulturelle Aspekte, wie zum Beispiel
    • "Ich als Entwickler interessiere mich dafür, wie der Benutzer die Software erlebt und handle danach."
    • "Ich als Operations-Engineer möchte wissen, welches Know-how ich aufbauen muss, um die inhouse entwickelte Unternehmensplattform zu hosten."
  • organisatorische Aspekte, wie zum Beispiel
    • "Wir als Entwicklungsteam binden den Support-Mitarbeiter, der unseren Kunden bei der Benutzung der Software hilft, in unsere agilen Zeremonien ein, um die Feedback-Schleifen zu verkürzen."
    • "Ich als Leiter der Entwicklung organisiere abteilungsübergreifende Meetings, aus denen Aufgaben in den Boards der Entwicklung und des Betriebs generiert werden."
  • technische Aspekte, wie zum Beispiel
    • "Wir nutzen dieselben Tools für das Deployment von Ressourcen mit derselben Plattform in allen Abteilungen."
    • "Wir definieren alle unsere technologischen Standards in gemeinsamen, leicht verständlichen und klar kommunizierten Architecture Decision Records (ADRs)."

Deine Aufgabe ist es also nun, mit der Erklärung zu starten, was eigentlich DevOps für Dein Unternehmen bedeutet. Schöpfe dafür alle Mittel aus. Erstelle Präsentationen, lade zu regelmäßigen Meetings ein, dokumentiere Dein DevOps und die damit verbundenen Ansprüche. Und vor allen Dingen: Rede darüber. Mache Dir Gedanken über einen Punkt und dann kommuniziere diesen. Anschließend nimm Dir das nächste Thema vor und kommuniziere dieses.

Ein paar Grundkenntnisse, bevor wir mit der Behandlung beginnen

Wir haben in den Umfragen zuvor schon festgestellt, dass selbst innerhalb der Teams eine durchaus unterschiedliche Wahrnehmung vorherrscht. Oft wird von einer "Wall of Confusion" gesprochen. Tatsächlich ist es gar keine "Wall", sondern vielmehr ein riesiger Irrgarten – der "Maze of Confusion".

Halten wir also fest – verschiedene Rollen haben eine unterschiedliche Wahrnehmung von DevOps im Unternehmen. Dazu kommt, dass neben der Wahrnehmung auch unterschiedliche Erwartungshaltungen existieren. Die einen möchten die Kosten reduzieren, manche fokussieren sich auf die Geschwindigkeit, wieder andere wollen einfach nur die Nachtschichten loswerden, die mit einem Release-Wechsel einhergehen.

Last but not least haben wir schon in den vorangegangenen Befragungen festgestellt, dass sich das Verständnis darüber, was DevOps überhaupt ist, völlig unterscheidet.

Ich habe mal IT-Mitarbeiter und Manager gefragt, was sie unter DevOps verstehen. Ich bin auf über 50 Erklärungen gestoßen. Eine kleine Auswahl: bessere Kommunikation, klare Verantwortlichkeit, End-to-End, Cloud, Continuous …, Freiheit, mehr Tools zu benutzen, Requirement Engineering, Kultur, nur was für Start-ups, Ansible/Terraform/…, MVP, Agile, ...

Alle drei Themen bringen uns also unser DevOps-Qi ganz schön durcheinander.

Die Behandlung

In diesem  Schritt widmen wir uns den Details. Wir wissen jetzt, welche Themen in welchem Team bestehen, haben schon erste Gespräche mit den Teams geführt und wissen, worauf wir achten müssen. Wir sind uns auch sicher, in welcher groben Region der Patient seine Probleme hat. Gehen wir also weiter in die Tiefe, fokussieren uns auf die Teams und gehen in Detailgespräche.

Aufbau eines Fragenkataloges

Um ein möglichst genaues Bild von einem Team zu erhalten, bauen wir einen Fragenkatalog auf, der mit allen Mitgliedern eines Teams bearbeitet wird. Dieser Katalog ist aufgeteilt in verschiedene "Maturity-Level" (unsere Tiere) von Level 0 bis 5.

Neben den Maturity-Leveln wird eine Gliederung in Ober- und Unterbereiche vorgenommen. Diese kannst Du Dir wie folgt vorstellen:

  • Kultur und Organisation: Verantwortung, Zusammenarbeit und Kollaboration, Teilen von Inhalten, Teamorganisation und Leadership und Feedback
  • Automatisierung: Deployment & Integration
  • User-Centric: Request Management, System Feedback und Interaktion & Measurement
  • Infrastruktur und Architektur: Monitoring, Infrastrukturmanagement, Toolchain & Architektur

Dies sind nur Beispiele. Natürlich kannst und sollst Du die Kategorien so gestalten, wie es für Dich am besten passt und es auch im Einklang mit den zuvor ermittelten Ergebnissen steht. Am Ende wirst Du eine Tabelle in dieser oder ähnlicher Form erhalten:

Erstellen der Fragen

Nun folgt der harte Teil des Projektes, nämlich die Ausformulierung eines Fragenkataloges. In jeder "Questionnaire"-Spalte sollte pro Zeile eine klare Aussage enthalten sein, mit der sich ein Projektteam eindeutig identifizieren kann. Nutzen wir die in Abb. 6 gezeigte erste Spalte (Responsibility, Collaboration, Communication) und formulieren diese aus:

  • Level 0 – Dem Dev-Team ist überhaupt nicht bekannt, wo diverse Anforderungen gestellt werden und wie Zielsysteme gestaltet sein müssen, um den Unternehmensanforderungen gerecht zu werden. Das Ops-Teams hat hingegen keine Kenntnis darüber, welche Applikation durch welches Team verantwortet wird.
  • Level 1 – Dev und Ops werden von unterschiedlichen (disziplinarisch und organisatorisch getrennten) Teams verantwortet. Die Kommunikation ist über Tickets gelöst, direkte Zusammenarbeit ist schwierig oder gar unmöglich. Schuldzuweisungen sind an der Tagesordnung.
  • Level 2 – Dev und Ops werden von unterschiedlichen Teams verantwortet. Eine Zusammenarbeit findet statt und wird durch mehr oder weniger regelmäßige Meetings koordiniert. Die Kommunikation ist aber weiterhin ineffizient.
  • Level 3 – Erste Ops-Aufgaben (z. B. des Software-Auslieferungs-Prozesses) werden in die tägliche Arbeit des Teams integriert. Eine direkte Zusammenarbeit zwischen Dev und Ops findet statt, beide Teams verantworten gemeinsam die Applikation.
  • Level 4 – Die Software wird regelmäßig auf die Bedürfnisse des Betriebs angepasst und vice versa die Plattform kontinuierlich durch das Ops-Team verbessert.
  • Level 5 – Es gibt keine getrennten Teams. Die End-to-end-Verantwortung für die Applikation liegt in einem gemeinsamen Team. Unternehmensstandards sind klar dokumentiert und automatisiert, so dass eine Ressource jederzeit automatisiert deployt werden kann, ohne den Entwicklungsprozess zu behindern.

Jede Spalte sollte durch mindestens 3 Fragen repräsentiert werden, um ein sinnvolles Ergebnis zu erhalten. Obiges Beispiel könntest Du mit folgenden Aussagen auffüllen:

Die Verantwortung über die Plattform der 20 Entwicklerteams…

  • … ist in Hand der Entwicklungsteams und das Ops-Team hat keine Kenntnis über die Funktionsweise.
  • liegt bei einem Plattform-Team, das in Ops angesiedelt ist, als eigenständiges Produkt-Team operiert und eng mit den Entwicklerteams zusammenarbeitet.

Auch Kontrollfragen machen Sinn. Diese erfragen denselben Inhalt in anderer Form, um zu prüfen, ob ein deckungsgleiches Ergebnis zu einer vorherigen Frage erreicht wird.

Durchführung der Interviews

Ist der Fragenkatalog vollständig aufgebaut, suche Dir ein Team, das dem ganzen DevOps-Qi-Thema wohlgesonnen gegenübersteht und schließe Dich mit dem Team mal 3-4 Stunden ein. Warum als erstes ein "wohlgesonnenes" Team? Du wirst Deinen Fragenkatalog kontinuierlich überarbeiten und verbessern. Die ersten Interviews ergeben sicher noch einiges an Verbesserungspotential. Du solltest dabei alle Rollen des Teams mit dabei haben. Also mindestens den PO, den Scrum Master und zwei oder mehr Entwickler. Arbeitet das Team schon eng mit dem Business oder anderen Fachbereichen zusammen, müssen auch diese dabei sein. Denke an das "Maze of Confusion". Nur wenn Du alle Rollen einbeziehst, wirst Du eine gute Übersicht über das Team erhalten. Das Interview sollte durch eine neutrale Person als Moderator geführt werden, die zudem einige Erfahrungen mit verschiedenen DevOps-Ansätzen hat.

Ich habe auch verschiedene Experimente im Rahmen der Fragestellung durchgeführt. Alternativ zu einem Gespräch mit dem ganzen Team kannst Du auch eine App nutzen, in der Du den Fragenkatalog hinterlegst. Dann lässt Du alle Teammitglieder die Fragen beantworten und gehst erst im Anschluss an die Auswertung in das Teamgespräch. Vorteil ist, dass die Leute ohne äußere Beeinflussung antworten und die Ergebnisse somit ehrlicher sein können. Speziell, wenn Du die Daten in der Umfrage-Software anonymisiert hast. Auf der anderen Seite bekommst Du dadurch Beeinflussungen mit, "wie das Team so tickt". So oder so ist es Deine Aufgabe als Interviewer, einen Rahmen zu schaffen, in dem alle Beteiligten offen und ehrlich mit Dir an dem Katalog arbeiten.

Interpretieren der Daten

Ist der Fragenkatalog abgearbeitet, kannst Du einen Graphen über die Ergebnisse legen und ermitteln, wo das Team aktuell steht und damit visualisieren, wo die Stärken und Schwächen des Teams liegen.

Dieses Ergebnis kannst Du mit Hilfe eines Spinnennetzdiagramms kondensieren und mit anderen Teams vergleichen.

Möchtest Du die Ergebnisse miteinander vergleichen und innerhalb des Unternehmens veröffentlichen, sprich dies gut mit den beteiligten Teams ab. Auf jeden Fall solltest Du jedem Team das Vorgehen vorab vorstellen, so dass sich jeder bewusst ist, was mit den Daten passiert. Eine Sache der Höflichkeit ist es zudem, jedes Team über die interne Veröffentlichung von Daten zu informieren. Gerade die "Klassifizierung" eines Teams kann je nach "Mood" im Unternehmen auch mal für schlechte Stimmung sorgen. Hier ist auf jeden Fall Feingefühl gefragt. Achte zudem darauf, nur grundsätzliche Daten zu veröffentlichen, auf gar keinen Fall personenbezogene.

Übergabe vom Spezialisten zum Hausarzt

Ich habe weiter oben geschrieben: "Hole Dir einen Spezialisten ins Haus." Das ist auch vollkommen richtig. Mein DevOps-Qi kann ich zwar versuchen, selbst in Ordnung zu bringen, aber wie auch bei Krankheiten wird es schwierig, eine Selbstdiagnose zu stellen. Ich denke, Du wirst, wenn Du bis hierher gelesen hast, feststellen, dass es kein Projekt für ein bis zwei Wochen ist, sondern eine aufwändige Diagnose und Behandlung erfordert. Dementsprechend benötigt Deine Organisation auch einen "Hausarzt", der Dich kennt und dauerhaft behandelt. Fange also gleich beim Start des Projektes damit an, den internen "DevOps-Qi-Heilpraktiker" zu finden. Führe die ersten Interviews auf jeden Fall mit einem Spezialisten durch, der in diesem Rahmen Deinen internen Hausarzt ausbildet.

Dieser Hausarzt wird auch in regelmäßigem Kontakt mit Deinen Teams stehen und aus den Ergebnissen ermitteln, welche Verbesserungsmaßnahmen abzuleiten sind. Viele Dinge lassen sich bestimmt innerhalb eines Teams lösen, andere müssen abteilungsübergreifend angegangen werden. Dieser Hausarzt sollte also ein kommunikativer Mensch sein, der in der Lage ist zu vermitteln, warum eine Änderung im Prozess XY auch einen Vorteil für das gesamte Unternehmen darstellt.

Regelmäßige Kontrolltermine

Zu guter Letzt solltest Du regelmäßige Kontrolltermine durchführen. Leider ist die Gefahr hoch, einmalig ein Projekt zur Optimierung Deines DevOps-Qi durchzuführen und dann die Ergebnisse in der nächsten Schublade verschwinden zu lassen. Ein Prozess, der eine gewisse Regelmäßigkeit in das ganze Verfahren bringt, verhindert dies. Spätestens nach der dritten Befragung ohne nennenswerte Änderungen eines eher ungünstigen Status Quo wird dies sicherlich zu Fragen führen.

Spätestens hier wird klar, dass der interne Hausarzt unabdingbar ist. Ein externer Berater macht zwar für den Start des gesamten Projektes Sinn und kann Dich das erste halbe Jahr konstruktiv unterstützen, den gesamten Workflow ans Laufen zu bringen. Aber am Ende des Tages liegt es bei Dir, einen kontinuierlichen Verbesserungsprozess zu etablieren, der den gesamten Unternehmensorganismus betrachtet.

Fazit

Für den Menschen ist ein regelmäßiger Gesundheits-Check-up Pflichtprogramm und zusätzliche Maßnahmen steigern das allgemeine Wohlbefinden, die Produktivität und die allgemeine Lebensqualität. Warum sollte es bei einem Unternehmen anders sein?

Diese Tatsache ist so offensichtlich, dass man sich wirklich die Frage stellen muss, wie es sein kann, dass man IT-Organisationen über Jahre ohne jede Struktur einfach vor sich hin arbeiten lässt. Mach Dir bewusst, dass Du dadurch Geld, Menschen und Deine Unternehmensvision verbrennst. Also schnappe Dir einen Experten, suche Dir die richtigen Sponsoren in Deiner Organisation und leg los.

Autor
David Koenig

David Koenig

David ist seit über 20 Jahren in der IT aktiv und hat den Schaffensprozess von Software von allen Seiten kennengelernt. Er nutzt dieses Wissen, um die Lücke zwischen Betrieb, Entwicklung, Plattform, Berater und Kunde zu schließen.…
>> Weiterlesen
Das könnte Sie auch interessieren
Kommentare (0)

Neuen Kommentar schreiben