Vermeidung von Rechenschaftspflicht: 5 Dysfunktionen eines DevOps-Teams
Dies ist der vierte 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 Dysfunktionen eines DevOps-Teams: Abwesenheit von Vertrauen 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.
Nun möchte ich die vierte Dysfunktion eines Teams untersuchen - die Vermeidung von Verantwortung.
Vermeidung von Rechenschaftspflicht
Die vierte Dysfunktion ist die Vermeidung von Verantwortlichkeit unter den Teammitgliedern. Im Zusammenhang mit der Teamarbeit bezieht es sich speziell auf die Bereitschaft der Teammitglieder, ihre Kollegen auf Leistung oder Verhaltensweisen anzusprechen, die dem Team schaden könnten. Die Essenz dieser Dysfunktion ist die mangelnde Bereitschaft der Teammitglieder, das zwischenmenschliche Unbehagen zu tolerieren, das damit einhergeht, einen Kollegen auf sein Verhalten anzusprechen, und die allgemeinere Tendenz, schwierige Gespräche zu vermeiden. Die Mitglieder großer Teams überwinden diese natürlichen Neigungen und entscheiden sich stattdessen dafür, sich gegenseitig in die Gefahr zu begeben.
Die grundlegende Prämisse von DevOps ist, dass die meisten Organisationen mit IT-Funktionen separate Teams haben, die für die Softwareentwicklung und den IT-Betrieb (auch bekannt als Service Management) verantwortlich sind. Diese Teams werden durch verwandte, aber unterschiedliche Problemstellungen motiviert, die eine natürliche Spannung zwischen denjenigen erzeugen, die Änderungen vornehmen, und denen, die einen Anreiz haben, die Serviceverfügbarkeit zu maximieren und somit Änderungen zusammen mit anderen offensichtlichen Bedrohungen zu verhindern. Es ist also nicht schwer, sich vorzustellen, dass diese Spannungen mit der Bildung neuer "DevOps-Teams" einen Siedepunkt erreichen. Aber wie ein Team auf diese Probleme reagiert, wird darüber entscheiden, ob es erfolgreich sein kann oder nicht.
Eine der besten Möglichkeiten, es Ihren DevOps-Teammitgliedern zu erleichtern, sich gegenseitig zur Rechenschaft zu ziehen, besteht darin, öffentlich genau zu klären, was das Team erreichen muss, wer was liefern muss und wie sich jeder verhalten muss, um erfolgreich zu sein. Für die meisten Unternehmen ist die Definition von Erfolg/Misserfolg vage oder undefiniert, was dazu führen kann, dass Ihr DevOps-Team keine klaren Erwartungen hat, für die es sich gegenseitig zur Rechenschaft ziehen kann. Als Führungskraft ist es unerlässlich, sich die Zeit zu nehmen, um zu definieren, wie Erfolg aussieht, und eine Kultur der Verantwortlichkeit zu schaffen. Um diese Art von Kultur zu schaffen, sollten die Teammitglieder regelmäßig darüber kommunizieren, wie sie das Gefühl haben, dass ihre Teamkollegen im Vergleich zu den erklärten Zielen und Standards abschneiden.
Der Feind der Rechenschaftspflicht ist die Mehrdeutigkeit
Ein weiterer Aspekt Ihres DevOps-Teams, der klar formuliert werden muss, ist die Trennung von Aufgaben und Rollen und Verantwortlichkeiten der Teammitglieder. DevOps ist und kann nicht auf eine einzige Rolle reduziert werden. Wenn überhaupt, geht es mehr um die Zusammensetzung von Teams als um einzelne Rollen. Wenn Sie DevOps betreiben, haben Sie regelmäßig Entwickler, Administratoren, DBAs, Speicher usw. im selben Raum, die alle an derselben Sache arbeiten. Man kann diese Interaktion nicht wirklich in eine separate Rolle abstrahieren.
Spike Morelli (@spikelab), ein DevOps-Berater, listete eine Reihe von Fähigkeiten auf, die jeder mit "DevOps" in seiner Berufsbezeichnung haben sollte:
Wenn Ihre DevOps-Initiative Gestalt annimmt, sollte ein Teil des Lernprozesses darin bestehen, diese neuen erforderlichen Fähigkeiten/Rollen, die Erwartungen und Abhängigkeiten sowie alle wichtigen Leistungsindikatoren, die Sie erreichen möchten, klar zu dokumentieren. Aber damit es funktioniert und um Teamdysfunktionen zu vermeiden, müssen Führungskräfte bereit sein, mit gutem Beispiel voranzugehen, sich schwierigen Problemen zu stellen und von ihren Teammitgliedern persönliche Verantwortung zu verlangen. Irgendwann wird das Konzept in die Teamkultur einsickern, dem Team mehr Autonomie und der Führungskraft mehr Zeit geben, sich auf andere dringende Probleme zu konzentrieren.