Den Shift-left-Trugschluss vermeiden

Bei DevOps geht es darum, nach links zu verlagern und Feedback-Schleifen zu verkürzen. Oder zumindest darum, ein Drittel des Weges zurück zu verlagern. So ungefähr.

Doch in der Formulierung „Shift Left“ stecken zwei große Annahmen. Erstens gehen wir davon aus, dass Feedback vorhanden ist, das wir nach links verlagern können. Zweitens nehmen wir an, dass Menschen dieses Feedback tatsächlich nutzen, damit es wertvoll wird.

Leider geraten viele Teams in eine oder sogar beide dieser Fallen. Sie befinden sich in dem, was ich als Shift-Left-Trugschluss bezeichne.

Nichts nach links verlagern

Wenn wir im DevOps-Kontext über Feedback sprechen, denken wir meist an interne und externe Kennzahlen für Qualität und Nutzung eines Produkts. Dazu kann gehören, zu messen, welche Teile unserer Anwendungen von den meisten Kunden genutzt werden, oder interne Qualitäts- und Performance-Kennzahlen wie Speichernutzung und fehlgeschlagene Tests.

Bei Shift Left geht es darum, Feedback aufzunehmen und denjenigen verfügbar zu machen, die etwas entwickeln. Damit es bei möglichst geringen Kosten die größte Wirkung erzielt, sollte das Feedback schnell und deutlich sein. Wenn ihr darüber mit einem Softwareentwickler wie mir sprecht, könnt ihr sicher sein, dass wir sofort mit scheinbar zufälligen Kombinationen cooler Tools loslegen, um mit einem großartigen Mechanismus zur Bereitstellung von Feedback voll ins Schwarze zu treffen. Doch dabei gibt es ein Problem: Was passiert, wenn dieser Balltret-Roboter in Produktion geht und wir keinen Ball finden, den er treten kann?

Denn es spielt keine Rolle, wie cool euer Prometheus und Grafana sind oder wie euer bevorzugtes SaaS-Metrics-Startup verspricht, eure Daten mit unendlich vielen Dimensionen einfach abfragbar zu machen. Tretet einen Schritt zurück und versucht, eine einzige nützliche Information zu finden. Ermittelt, wie viele Serverfehler eure Anwendung in den letzten 24 Stunden gemeldet hat. Macht es manuell. Wiederholt diesen manuellen Prozess einige Male im Monat und haltet ihn in einer Excel-Tabelle oder Ähnlichem fest. Wenn ihr es ganz wild treiben wollt, nehmt einen Post-it und klebt euren Datenpunkt an euren Schreibtisch. Technische Messwerte wie Serverfehler sind natürlich einfach zu erfassen. Für eine wirklich wertvolle Herausforderung fragt den fachlich Verantwortlichen, welche Kennzahlen ihm wichtig sind. Noch besser: Sucht einen echten Nutzer eurer Anwendung und fragt ihn, wie zufrieden er damit ist.

Und wenn ihr kein nützliches Feedback findet, sollte euer Fokus darauf liegen, herauszufinden, wie ihr welches bekommt – nicht auf einem imaginären Shift-Left-Prozess.

Shift Left ins Leere

Der zweite Aspekt des Shift-Left-Trugschlusses besteht darin, all das wertvolle Feedback einzuholen, es dorthin zu bringen, wo es die größte Wirkung entfaltet, und dann völlig daran zu scheitern, danach zu handeln. Das geschieht, weil wir das Feedback entweder einfach ignorieren oder technologisch beziehungsweise organisatorisch nicht in der Lage sind, es nutzbar zu machen. Wenn wir nicht in der Lage oder nicht bereit sind, auf Feedback zu reagieren, ist es verschwendet. Auch all der Aufwand und die Energie, die wir in seine Beschaffung gesteckt haben, sind dann verschwendet.

Wenn wir in Tools wie XRay investieren, um auf Schwachstellen oder Lizenzverstöße zu prüfen, können wir viel wertvolles Feedback erhalten. Doch das kann zu einer Flut von Verstößen, Warnungen und Fehlern führen, die uns lähmt und für die Schwere unserer Probleme abstumpft. Tausend Warnungen zu ignorieren ist viel einfacher als nur eine.

Beginnt im Fall von Lizenzen beispielsweise damit, zu klären, welche Lizenzen für euch zulässig sind, bevor ihr Prüfungen in die Pipeline einbaut. Geht dann eure Abhängigkeiten durch, findet einen einzelnen Verstoß und handelt! Werdet ihr die betroffene Komponente nicht mehr nutzen? Könnt ihr eine kommerzielle Lizenz oder ein alternatives Produkt finden? Oder im schlimmsten Fall selbst eine Alternative entwickeln?

Wenn ihr mit einem Verstoß nicht umgehen könnt, solltet ihr diese spezielle Feedback-Schleife nicht nach links verlagern.

Das Problem hat zwei Seiten. Erstens habt ihr euren Aufwand für die Bereitstellung dieses Feedbacks schlicht verschwendet. Die eigentliche Tragödie des Shift-Left-Trugschlusses besteht hier jedoch darin, dass ihr eure Teams darauf trainiert, Feedback zu ignorieren. Dadurch schwächt ihr ihren Einfallsreichtum, ihre Autonomie und ihr Vertrauen in die Organisation. Es sagt viel über uns aus, dass wir in die Gewinnung dieser Art von Feedback investieren können, ohne anschließend danach zu handeln!

Bei Feedback-Schleifen geht es um Feedback

Bei Feedback geht es darum, die Ergebnisse unseres Systems in Eingaben für unser System umzuwandeln. Wenn wir das nicht tun, also unser System weder über unsere Nutzer noch über Monitoring mit Informationen versorgen und verändern, sollten wir gar nicht erst von Feedback-Schleifen und Shift Left sprechen.

Der beste Ausgangspunkt ist also das Feedback. Danach können wir überlegen, wie wir daraus eine Schleife machen.

Hier sind einige Möglichkeiten, mit Feedback zu arbeiten.

Pair oder Mob Programming

Das gibt euch die Möglichkeit, intern mit eurem Feedback und euren Informationen zu arbeiten. Sobald ihr Mob Programming im Griff habt, könnt ihr Externe wie InfoSec und QA zu den Mob-Programming-Sessions einladen, damit sie euch helfen, das Feedback nach links zu verlagern.

Mehr Menschen in die frühe Designphase einbeziehen

Wenn ihr mit umfangreichen Arbeiten beginnt, stellt sicher, dass alle mit einem relevanten Value Stream dabei sind. Nicht nur Designer und Entwickler tragen zur Wertschöpfung bei und schaffen den Kontext für die Entwicklungsarbeit. Dazu können Partner, Plattform-Teams, QA und Security gehören. Von Anfang an für Sicherheit, Tests und Betriebsfähigkeit zu designen und zu architektieren, bringt große Vorteile. Außerdem ist es viel günstiger und macht mehr Spaß, als diese Aspekte später im Prozess nachträglich anzufügen, wenn weitreichende Änderungen schmerzhaft sind.

Macht es auf die einfache Art

Entscheidet euch zunächst für eine wichtige Business-Kennzahl, auf die ihr reagieren möchtet. Wenn sie sich problemlos automatisch messen lässt, macht das. Wenn es aber auch nur ein wenig herausfordernd ist, haltet inne und vereinfacht sie weiter.

Schätzt die Kennzahl regelmäßig grob und prüft, ob euch das Mehrwert bringt. Falls ja, lohnt sich wahrscheinlich die Automatisierung und die Verlagerung nach links. Das ist auch ein guter Zeitpunkt, um mit der Wahl der richtigen Visualisierungsmethoden zu experimentieren. Visualisierungen können Trends hervorheben oder verbergen. Während ihr noch mit der Datenerfassung experimentiert, habt ihr eine hohe Transparenz darüber, wie sich die Daten entwickeln. Nutzt das und stellt sicher, dass ihr sie wirkungsvoll visualisieren könnt.

Shift Left ist nicht kostenlos

Wir müssen Shift Left vorantreiben, wenn wir im digitalen Umfeld, in dem wir leben, wettbewerbsfähig bleiben wollen. Shift Left jedoch einfach als Buzzword zu verwenden und die technologischen sowie organisatorischen Voraussetzungen zu ignorieren, ist verschwenderisch und kann sogar erheblichen Schaden anrichten.

Hier sind drei Anzeichen dafür, dass ihr in die Shift-Left-Falle getappt seid und herauskommen müsst:

• Ihr erhaltet viel Feedback, aber es beeinflusst eure Maßnahmen nicht

• Ihr verbringt mehr Zeit mit den Tools als damit, die Daten zu verstehen

• Ihr wünscht euch immer wieder, bestimmtes Feedback wäre früher erstellt worden

Priorisiert also Shift Left, aber hütet euch vor der Shift-Left-Falle!