Der "Second Way of DevOps"

Schaut, welche Feedbackzyklen Euch fehlen. Denkt dabei auch über Eure Team- und Abteilungsgrenzen hinweg. Baut diese Schleifen auf. Beschleunigt Eure Feedbackzyklen. Nutzt Information Radiators.

Einleitung

Im letzten Teil haben wir uns mit dem ersten Weg von DevOps, wie Gene Kim sie beschreibt, beschäftigt. Dieses Mal lernen wir den zweiten Weg kennen.

Der zweite Weg

Der zweite Weg wird auch “Amplify feedback loops” genannt. Es geht also nicht um den Fluss von Arbeit, sondern um den Fluss von Feedback. Wer schon agil arbeitet, der hat bereits viele Feedbackschleifen, die ihn unterstützen. In Scrum zum Beispiel durch die Sprint Retrospective oder durch das Daily Scrum, im Pair Programming durch den kontinuierlichen Austausch zwischen Driver und Navigator, etc. Oft werden aber nur Feedbackzyklen innerhalb von Teams bzw. Abteilungen betrachtet. Wir wollen darüber hinausgehen und weiter denken. Wie kommt Feedback aus dem Betrieb zu den Entwicklern? Oder vom Endkunden zum Betrieb? Worüber geben wir Feedback?

Und wozu?

Kontinuierliches Feedback hilft uns, einen besseren Überblick über die Gesamtsituation zu behalten. Gleichzeitig verhindert es, dass kleine Probleme sich zu großen Katastrophen auswachsen können. Ein gemeinsames Verständnis für die Gesamtlage hilft dabei, ein Zusammengehörigkeitsgefühl innerhalb der Organisation zu stärken. Gutes Feedback ist die Grundlage für jeden empirischen Verbesserungsprozess.

Wie gehen wir konkret vor?

Wie auch beim ersten Weg gibt es kein Patentrezept, das man befolgen könnte, um garantiert zum Ziel zu kommen. Vielmehr müssen wir Lösungen speziell für die jeweilige Organisation finden. Einige typische Fragestellungen können aber helfen, den eigenen Weg zu finden.

Worüber bekommen wir Feedback?

Macht einmal eine Bestandsaufnahme darüber, welche Informationen Euch bisher zur Verfügung stehen. Sind diese Informationen auch für den Rest der Organisation verfügbar? Welche Informationen liegen in anderen Teams vor, die Ihr gerne sehen würdet? Dabei ist es nicht wichtig, ob Ihr die Information wirklich braucht, sondern nur, ob sie interessant wäre. Bei einem meiner früheren Arbeitgeber haben wir zum Beispiel live die Umsatzzahlen an Monitoren an der Wand angezeigt. Zwingend notwendig ist das für Softwareentwickler nicht. Aber es hat ein Gefühl dafür erzeugt, was es für das Unternehmen bedeutet, wenn wir die Release-Downtimes reduzieren oder eliminieren können. Oder auch, was ein Ausfall bedeutet. Wenn Ihr wisst, wer welche Informationen haben möchte, stellt sicher, dass diese Informationen auch zugänglich sind. Sammelt dann auch Ideen über Feedback, das Ihr gerne hättet, das bisher aber noch nicht vorliegt. Überlegt dann, wie Ihr dieses bekommen könnt. Dabei hilft es wieder, wenn Ihr das Team übergreifend macht.

Wie lange dauert es, bis Feedback ankommt?

Hier gilt: je kürzer desto besser. Feedback soll Euch helfen, schnell auf sich verändernde Situationen reagieren zu können. Feedback, auf das Ihr warten müsst, vergeudet wertvolle Zeit. Wenn Ihr zum Beispiel nur einmal nachts eine neue Softwareversion baut, werdet Ihr auch erst am nächsten Tag feststellen können, dass etwas kaputt gegangen ist. Wenn Ihr es schafft, mehr in Richtung Continuous Integration zu gehen, verbessert Ihr die Feedbackschleife und nutzt Eure Zeit besser und zielgerichteter. Kürzere Feedbackzyklen sind auch einer der Gründe, warum Eure Sprints nicht zu lang sein sollten.

In welcher Form bekommt Ihr das Feedback?

Damit Feedback nützlich ist, muss es auch wahrgenommen und verstanden werden. Viele Metriken anzuhäufen, die nie jemand ansieht, hat keinen Mehrwert. Macht Euch also Gedanken über die Art und Weise, wie Ihr Informationen zur Verfügung stellt. Hilfreich ist ein Self-Service-System, in dem jeder nach Informationen suchen kann. Die wichtigsten Information sollten aber noch sichtbarer sein. Wenn ein Build fehlschlägt, dann schickt Emails, schaltet rote Warnlampen an, etc. Benutzt Information Radiators - das heisst, Ihr hängt Monitore an Stellen auf, an denen sie von vielen Leuten gesehen werden. Dies können insbesondere auch Gemeinschaftsräume oder die Lobby sein. Zeigt dort die wesentlichen Dashboards an. Diese sind oft Ausgangspunkt für Gespräche mit Leuten aus komplett anderen Abteilungen, die eine Quelle neuer Ideen und einem besseren Verständnis für einander sind.

Denkt auch darüber nach, ob die gleiche Information in einer anderen Darstellungsweise nützlicher wäre. Wenn Ihr zum Beispiel die aktuelle Festplattenauslastung anzeigt, dann ist die sicher interessant. Aber die erste Ableitung davon, das heisst, die Geschwindigkeit mit der die Festplatte vollgeschrieben wird, ist oft hilfreicher.

Aber unsere Firmengeheimnisse?!

Jedem sollten möglichst alle interessanten Informationen ohne große Hürden zugänglich sein. Besteht nicht die Gefahr, dass die Konkurrenz das auch alles wissen will? Sicher wird es Geheimnisse geben, die geheim bleiben müssen - und von denen auch die eigenen Mitarbeiter nichts wissen dürfen. Die würde ich auch nicht auf einem Monitor in der Kantine anzeigen. Wichtig ist aber, dass wir ein Klima gegenseitigen Vertrauens schaffen. In seinem hervorragenden Buch “Team of Teams” hat General Stanley McChrystal berichtet, wie er bei seinen Planungen für Anti-Terror-Einsätze tägliche Konferenzen mit mehreren hundert Teilnehmern aus einer Vielzahl von Behörden abgehalten hat. Aus seiner Sicht hat diese radikale Abkehr vom “Need-to-know”-Prinzip erst zu einer gemeinsamen situational awareness geführt, die Voraussetzung für einen erfolgreichen Einsatz ist. Also: seid mutig und vertraut Euren Mitarbeitern. Und überschätzt nicht den Wert, den eine bestimmte Information für Eure Konkurrenz hat. Meiner Erfahrung nach ist der Gewinn an Reaktionsvermögen und gemeinsamen Verständnis sehr viel mehr wert als das Risiko, dass manche Informationen Unbefugten in die Hände fallen.

Fazit

Wie beim ersten Weg ist auch der zweite Weg ein Weg ohne Ziel, an dem man ankommen könnte. Egal wo Ihr gerade steht, könnt Ihr Euch darüber Gedanken machen, was der nächste kleine Schritt ist, Eure Feedbackschleifen zu verbessern - und es wird immer etwas geben, was Ihr noch besser machen könnt. Wichtig ist es, zu starten.