Falsch verstandene Kennzahlen im DevOps

Als Softwareentwickler erledigen wir einen Großteil unserer konkreten Arbeit am Computer. Viele Entscheidungen treffen wir jedoch auf Grundlage der Geschichten, die wir akzeptiert haben, oder der Diagramme, die wir auf unsere Whiteboards zeichnen. Ich zeige euch drei Diagramme, die häufig falsch eingesetzt werden.

Die in den Diagrammen dargestellten Abkürzungen sind wertvoll, weil sie verhindern, dass wir das Rad immer wieder neu erfinden. Diese Denkmodelle können im Kopf eines einzelnen Entwicklers, in einem Team, in einem Unternehmen oder in der gesamten Branche bestehen. Sie sind mächtig, können aber sowohl gute als auch schlechte Ergebnisse hervorbringen.

Besonders problematisch wird es, wenn unsere Abkürzungen Informationen verschleiern oder schlicht falsch sind.

Versteckt eure Burndown-Charts!

Ein Diagramm, das ich bei allen selbsternannten Agile-Teams sehe, ist das Burndown-Chart.

Das Diagramm soll zeigen, ob das Team bei der Umsetzung dessen, wozu es sich verpflichtet hat, auf Kurs ist. So soll das Team frühzeitig gewarnt werden, damit es Stakeholder informieren oder bei Bedarf Prioritäten neu setzen kann.

Wenn wir jedoch ein Ziel in das Diagramm eintragen, unterstellt das einige weitreichende Annahmen darüber, wie Softwareentwicklung funktioniert. Es setzt voraus, dass Arbeit vorhersehbar und gleichmäßig erledigt werden kann – was nicht stimmt. Das muss aber nicht unbedingt ein Problem sein. Es kann dem Team als Frühwarnsignal dienen, dass etwas nicht wie erwartet läuft, und ihm ermöglichen, angemessen zu handeln.

Häufiger wird das Burndown-Chart jedoch als Peitsche des Managements eingesetzt. Ein Projektmanager oder ein böswilliger Scrum Master könnte mitten im Sprint auftauchen und das Team zur Rede stellen, weil das Burndown für ihn schlecht aussieht. Es ergibt jedoch keinen Sinn, darüber zu diskutieren, ob ein Burndown-Chart gut oder schlecht ist. Das Diagramm bildet lediglich die aktuelle Realität ab.

Wir müssen daran denken, dass das Burndown-Chart für das Team da ist. Für sich allein sagt es uns nichts Wertvolles oder Konkretes. Wenn unser Burndown uns überrascht oder beunruhigt, sollten wir herausfinden, was uns genau daran überrascht und wie wir als Team damit umgehen können.

Wird das Burndown-Chart falsch eingesetzt, schafft es nicht nur keinen Mehrwert, sondern frustriert auch aktiv Entwickler, die komplexe Probleme lösen wollen, mit denen sie zuvor noch nicht konfrontiert waren.

Umgang mit verspäteten Projekten

Dass Projekte gelegentlich in Verzug geraten, lässt sich nicht vermeiden. Jedes Team übernimmt sich irgendwann. Teams können dazu gedrängt werden oder ihr Ziel schlicht verfehlen.

Hoffentlich erkennen wir früh im Prozess, dass wir unser ambitioniertes Ziel voraussichtlich nicht erreichen werden, damit wir noch Zeit zum Handeln haben. Doch die Standardreaktion auf eine wahrscheinlich verfehlte Frist ist falsch. Wenn uns bewusst wird, dass sich eine Deadline verschiebt, verstärkt unsere intuitive Reaktion das Problem leider nur.

Die Standardreaktion sieht so aus: Unternehmen stellen meist mehr Ressourcen und mehr Entwickler bereit, um das Problem zu lösen. Die Erwartung oder Hoffnung ist, dass wir schneller ans Ziel kommen, wenn mehr Hände und Köpfe an unserem Problem arbeiten.

In der Realität führt das Onboarding neuer Mitarbeiter für ein Projekt jedoch unmittelbar zu einem Produktivitätsrückgang. Die Zeit, die für die Weitergabe von Fachwissen, die Überprüfung der Arbeit und die Bewältigung der Herausforderungen beim Skalieren eines Teams erforderlich ist, wird das ohnehin verspätete Team zusätzlich ausbremsen.

Bis genügend Zeit vergangen ist und die neuen Teammitglieder eingearbeitet sind, sorgen die zusätzlichen Ressourcen nur dafür, dass wir unsere Deadline mit noch geringerer Wahrscheinlichkeit einhalten. Wie The mythical Man -Month empfiehlt, gibt es bei einer voraussichtlich verfehlten Deadline nur zwei Möglichkeiten: den Umfang reduzieren oder die Deadline verschieben.

Das Hinzufügen weiterer Ressourcen hat auch versteckte Kosten. Wenn Ressourcen benötigt werden, um ein Projekt zu retten, das hinter dem Zeitplan liegt, werden die Retter aller Wahrscheinlichkeit nach intern gefunden. Das wirkt sich nicht nur auf die Projekte aus, denen diese Personen ursprünglich zugeteilt waren, sondern schafft auch eine instabile Teamstruktur. Kontinuierliche Verbesserung wird dadurch schwierig, wenn nicht sogar unmöglich.

Wäre das selten der Fall, wäre es kein Problem. Leider ist es für viele Unternehmen die Norm: Mitarbeiter werden in einem verwirrenden Tanz wechselnder Prioritäten von Projekt zu Projekt verschoben.

Aber nicht alles ist hoffnungslos, auch wenn ich ein düsteres Bild von verfehlten Deadlines gezeichnet habe. Es gibt Maßnahmen, die wir ergreifen können.

Reißt das Pflaster ab und reduziert den Umfang

Der wichtigste Schritt ist, frühzeitig zu prüfen, ob sich ein Projekt verspäten wird. Häufig ist es die beste Lösung, den Umfang zu reduzieren und sich bewusst zu machen, wie ihr ihn auf einen sinnvollen Umfang reduzieren könnt.

Den Umfang zu reduzieren kann demotivierend sein oder in manchen Fällen sogar nicht akzeptabel. Dann müssen wir jedoch darin investieren, bei Bedarf einfacher zusätzliche Ressourcen für unsere Projekte einsetzen zu können.

Wenn die Deadline näher rückt und ihr merkt, dass ihr euer Ziel verfehlen werdet, ist es schwierig, die Situation noch zu korrigieren. Es gibt jedoch einige Schritte, mit denen ihr das Hinzufügen von Ressourcen zu einem Projekt bei Bedarf erleichtern könnt.

Tipps für ein einfacheres Onboarding

Ich empfehle, alle Softwareprojekte wie Open Source zu behandeln. Das bedeutet, dass der Fokus darauf liegen muss, Beiträge einfach zu machen.

Es muss Dokumentation für die Nutzung, das Testen und die Weiterentwicklung des Projekts geben. Tests müssen automatisiert sein, und das Quality Gate darf kein Senior Engineer sein – vielmehr sollte es ein pedantischer Roboter sein. Die Tools, in denen wir unseren Source Code speichern, wurden entweder zur Unterstützung von Open-Source-Workflows entwickelt oder sind stark von ihnen inspiriert. Nutzt daher die nativen Funktionen dieser Plattformen.

Stellt zumindest sicher, dass Folgendes vorhanden ist:

• Eine README mit guter, leicht zugänglicher Dokumentation dazu, wie das Produkt gebaut, genutzt und getestet wird

• Links zu Pipelines, Coding Styles und externer Dokumentation sind vorhanden

• Ein klar beschriebener Workflow

• Alle wichtigen Ansprechpartner werden genannt, einschließlich ihrer Kontaktdaten

Das Schwierige an diesen Maßnahmen ist, dass sie wie eine Versicherung funktionieren. Wenn ihr sie vermeintlich nicht braucht, kann es leicht passieren, dass ihr ihre Bedeutung vergesst. Doch an dem Tag, an dem ihr sie braucht, könnt ihr es euch nicht leisten, diese Schritte nicht unternommen zu haben.

Die überraschende Wahrheit über Automatisierung

Als DevOps-Mensch habe ich eine nicht ganz gesunde Vorliebe für Automatisierung. Wir wissen, dass Automatisierung eine Voraussetzung dafür ist, mit wachsender Teamgröße überproportional zu skalieren. Sie bietet außerdem zahlreiche Vorteile hinsichtlich Qualität, Auditierbarkeit, Liefergeschwindigkeit und Vertrauen.

Unsere Intuition sagt uns, dass mit zunehmenden Investitionen in Automatisierung die Menge manueller Arbeit sinkt. Die Accelerate DevOps Research widerspricht dem jedoch. Ihre Erkenntnisse zeigen, dass Deployment-Automatisierung tatsächlich mehr manuelle Arbeit schafft. Der Grund: Es gibt nun eine große Menge an Änderungen, die getestet und geprüft werden müssen.

Wir sollten uns jedoch bewusst sein, dass wir nur eine Art manueller Arbeit beseitigt haben. Entscheidend ist, das Richtige zu messen. Andernfalls wird euer Automatisierungsvorhaben als Fehlschlag bewertet, obwohl ihr einen Teil eures Workflows erfolgreich automatisiert habt.

Dieser Anstieg manueller Arbeit ist der Grund, warum viele Automatisierungsvorhaben pausiert oder als erfolglos eingestuft werden. Wir müssen nun nicht nur mehr manuelle Arbeit leisten, sondern auch unsere Automatisierung warten.

In Unternehmen, die gerade erst mit der Automatisierung ihrer Prozesse beginnen oder nur begrenzte Erfahrung damit haben, besteht oft Misstrauen gegenüber Automatisierung. Das führt zu redundanter Arbeit, die sowohl von Robotern als auch von Menschen erledigt wird.

Um die Vorteile der Automatisierung zu nutzen, brauchen wir auch einen Wandel in der Denkweise. Wenn wir uns vor Beginn eines Automatisierungsprozesses dieses Anstiegs manueller Arbeit bewusst sind, lassen sich hoffentlich unangenehme Überraschungen vermeiden. In diesem Blogpost habe ich einige allgemein akzeptierte Zahlen vorgestellt. Mehr über ein Missverständnis auf Unternehmensebene erfahrt ihr in der Agile Alignment Trap.

Ich hatte das Vergnügen, an den DevOpsDays Zurich 2019 teilzunehmen und meine Gedanken auf der Bühne im Vortrag „Misused Figures of DevOps“ zu teilen.