5 Dysfunktionen eines DevOps-Teams: Unaufmerksamkeit gegenüber Ergebnissen

Dies ist der fünfte in einer Reihe von Beiträgen rund um die DevOps-Kultur und die Lektionen, die wir aus Patrick Lencionis Buch "The Five Dysfunctions of a Team - A Leadership Fable" gelernt haben.

• 5 Dysfunctions of a DevOps Team: Absence of Trust, untersuchte, wie Vertrauen die Grundlage für die Anpassung der Kultur Ihres Teams an die Transformation für die DevOps-Bewegung ist.
• 5 Dysfunctions of a DevOps Team: Fear of Conflict" untersuchte, wie leistungsstarke Teams keine Angst davor haben, einen leidenschaftlichen Dialog über Themen und Entscheidungen zu führen, die für das Geschäft oder die Mission von entscheidender Bedeutung sind.
• 5 Dysfunctions of a DevOps Team: Lack of Commitment" untersuchte, wie Unternehmen aller Formen und Größen eine bessere Akzeptanz in Bezug auf Ziele und Ergebnisse in Bezug auf ihre DevOps-Initiative benötigen.
• 5 Dysfunctions of a DevOps Team: Avoidance of Accountability, untersuchte, wie Klarheit über neue Rollen, Erwartungen und KPIs erforderlich ist, um sich gegenseitig zur Rechenschaft zu ziehen.

Nun möchte ich die fünfte Dysfunktion eines Teams untersuchen - die Unaufmerksamkeit gegenüber Ergebnissen.

Unaufmerksamkeit gegenüber Ergebnissen

Die fünfte Dysfunktion, die Unaufmerksamkeit gegenüber den Ergebnissen, ist die ultimative Dysfunktion eines Teams und bezieht sich auf die Tendenz der Teammitglieder, sich um etwas anderes als das kollektive Ziel/die Mission der Gruppe zu kümmern. Ein unerbittlicher Fokus auf bestimmte Ziele und klar definierte Ergebnisse ist eine Voraussetzung für jedes Team, das sich selbst nach Leistung beurteilt. Und obwohl es stimmt, dass viele Organisationen in einem kapitalistischen wirtschaftlichen Umfeld ihren Erfolg letztlich an Gewinn, Umsatz oder Aktionärsrendite messen, bezieht sich diese Dysfunktion auf eine viel weiter gefasste Definition von Ergebnissen, die mit ergebnisorientierter Leistung zusammenhängt.

Eine der wichtigsten Zutaten für DevOps ist die Geschwindigkeit. Viele, wenn nicht sogar alle DevOps-Teams (und in Wahrheit auch agile Teams) messen sich an der Häufigkeit und Qualität von Releases. Die Fähigkeit, 1) zu verstehen, was am wichtigsten ist (abgeleitet aus der Verantwortlichkeit) und 2) schnell in der Lage zu sein, Entscheidungen zu treffen und unter Druck zu handeln, ist eine monumentale Fähigkeit, die gemeistert werden muss, um Geschwindigkeit zu erreichen. Automatisierung kann helfen, aber sie ist auch nicht die Lösung für jedes Problem.

Zeit ist der dominierende Parameter.

Einige DevOps-Teams verwenden OODA-Schleifen (Observe, Orient, Decide, and Act), die vor über 50 Jahren entwickelt wurden, um militärische Kämpfe zu unterstützen. Die Grundprämisse war, dass der Sieg durch die Schaffung von Situationen erfolgen kann, in denen man schneller angemessene Entscheidungen treffen und den Gegner überraschen kann. Genau dieses Szenario sehen sich DevOps-Teams heute angesichts des kontinuierlichen Wandels innerhalb von Cloud Computing, virtuellen Systemen und modernen, webbasierten Anwendungen gegenüber. Das Zusammentreffen von Cloud Computing und Open-Source-Code hat es einfacher denn je gemacht, Systeme schnell in die Produktion zu bringen und häufig zu iterieren.

Diese Agilität hat jedoch oft ihren Preis: Da sich das Entwicklungstempo beschleunigt, müssen die IT-Betriebsmitarbeiter ständig mit dem aktuellen Zustand des Systems Schritt halten. Sichtbarkeit und Kontext leiden darunter. Ops- und Dev-Leute werden zu Gegnern statt zu Verbündeten. Im modernen IT-Betrieb kann der OODA-Loop-Prozess DevOps-Teams dabei helfen, Problemen einen Schritt voraus zu sein und schnell und präzise zu reagieren. Eine OODA-Schleife kann auch die Fähigkeit eines DevOps-Teams erleichtern, auf bestimmte Ziele und klar definierte Ergebnisse zu reagieren.

Weitere Informationen zu OODA-Schleifen finden Sie hier.

Vorsicht voraus

Ein Trend, den wir in Unternehmen beobachten, ist die Schaffung von DevOps-Teams. In Bezug auf die 5 Dysfunktionen eines Teams hat dies mögliche Konsequenzen, die von der Zusammensetzung des Teams abhängen. Diese kleinen Teams, die sich ausgruppieren, um herauszufinden, wie Sie DevOps in Ihrem Unternehmen umsetzen können, können der Verlockung des Status zum Opfer fallen. Der Teamstatus dieses handverlesenen Teams beginnt in die Kultur einzusickern, und sie sehen Erfolg oft nur in Verbindung mit ihrer besonderen Organisation. Als Führungskraft ist dies definitiv etwas, worauf man achten sollte.

So offensichtlich diese Dysfunktion auf den ersten Blick erscheinen mag und so klar sie auch ist, dass sie vermieden werden muss, so wichtig ist es, zu beachten, dass viele Teams einfach nicht ergebnisorientiert sind. Sie leben und atmen nicht, um sinnvolle Ziele zu erreichen, sondern um einfach nur zu existieren oder zu überleben. Unglücklicherweise für diese Gruppen kann kein noch so großes Maß an Vertrauen, Konflikten, Engagement oder Verantwortlichkeit den mangelnden Wunsch zu gewinnen ausgleichen.

Vielleicht mehr als bei jeder anderen Dysfunktion muss ein DevOps-Teamleiter den Ton angeben, um sich auf Ergebnisse zu konzentrieren. Wenn Teammitglieder das Gefühl haben, dass die Führungskraft etwas anderes als Ergebnisse schätzt, werden sie dies als Erlaubnis ansehen, dasselbe für sich selbst zu tun. Die Ermöglichung einer optimierten Zusammenarbeit zwischen verschiedenen Parteien, vorzugsweise in DevOps-Manier, ist unerlässlich, um das OODA-Modell zu unterstützen und die geschäftliche Agilität zu fördern. Unternehmen wollen die Vorteile von DevOps nutzen - Kosteneinsparungen durch Automatisierung, Agilität und Innovationsförderung, um nur einige zu nennen. In der modernen IT-Betriebsumgebung kann es um Leben und Tod gehen, schnell die besten Entscheidungen zu treffen.