Do not automate all the things
Es ist der Schlachtruf der DevOps-Bewegung: Automate all the Things!, ein Anspruch der in seiner radikalen Absolutheit oft von dem Hyperbole and Half-Meme unterstrichen wird. Nicht nur in Bezug auf DevOps sondern mittlerweile auch für die Agilität im Allgemeinen ist diese Haltung zu einem der zentralen Distinktionsmerkmale geworden, ohne sie wäre es vermutlich nicht zu der damit verbundenen Erfolgsgeschichte gekommen. Und doch - mittlerweile sollte man das Ganze kritisch hinterfragen.
Zur Erinnerung, eigentlich ist Automatisierung in der agilen Produktentwicklung etwas Gutes. Manuelle Release-, (Regressions-)Test-, Dokumentations- und ähnliche Prozesse können schnell absurde Umfänge annehmen, in der Durchführung ewig dauern und gigantische Kontroll- und Koordinierungs-Bürokratien erzeugen. Da das jegliche Beweglichkeit und Reaktionsfähigkeit ersticken würde bleibt nur eines - automatisieren, im Wettlauf gegen die Zeit.
Was im Rahmen dieses Vorgehens aus dem Blick geraten kann ist aber, dass die Automatisierung auch im wahrsten Sinn des Wortes Schattenseiten hat. Nicht umsonst wird sie im Deutschen auch als Dunkelverarbeitung bezeichnet, sobald Prozesse einmal selbstständig ablaufen sind sie vor dem menschlichen Auge verborgen (zumindest in der IT, wo Automatisierung fast immer Digitalisierung bedeutet, unter Umständen sogar irgendwo in der Cloud statt in den eigenen Systemen).
Bedingt dadurch kann es vorkommen, dass Informationen gar nicht mehr auffallen (oder erst dann wenn es zu spät ist). Eines der häufigsten Beispiele dafür sind Burndown-Charts. Dort wo sie manuell an der Wand erstellt werden ist es für ein Team schon früh sichtbar ob es Fortschritte macht oder ob es sich festgefahren hat, dort wo sie automatisiert erstellt werden (z.B. auf einer versteckten Web-Seite in Jira) werden sie oft nur zum Sprintende angeschaut, schlimmstenfalls nie.
Selbst wenn sie sichtbar angezeigt werden, können wichtige Informationen aber übersehen werden. Auch hier gibt es ein häufiges Beispiel: die Summe der Punkte auf den Tickets, die anzeigen seit wann sich hier nichts mehr bewegt hat. Dort wo sie automatisiert hochgezählt werden treten oft schnell Abstumpfungs-Effekte ein, dort wo sie manuell hinzugefügt werden entsteht eine bewusstere Beschäftigung mit dem Thema, die häufiger zu Korrekturmassnahmen führt.
Nicht zu unterschätzen ist auch der Effekt der eintritt wenn die Beschäftigung mit den eigenen Prozessen zu einem Standard-Bestandteil von Regelmeetings wird. Das kann etwa im Rahmen von Reviews oder Retrospektiven stattfinden, es können aber auch eigene Termine dafür geschaffen werden, z.B. solche in denen man gemeinsam die eigenen technischen und organisatorischen Schulden begutachtet. Das Ergebnis ist eine Verankerung der Themen im kollektiven Gedächtnis der Organisation.
Um langsam zum Schluss zu kommen - heisst das, dass man die Prozessautomatisierung doch wieder seinlassen soll? Natürlich nicht, und die bisher genannten Beispiele verleiten auch nicht dazu. Repetitive Tätigkeiten sollen (bzw. müssen) weiterhin automatisiert werden wenn Agilität das Ziel ist, das bleibt unverändert. Eine "Ent-Automatisierung" lohnt sich aber trotzdem, vor allem bei vielen Datenerhebungen, um so Probleme offensichtlich zu machen und Lösungsfindungen anzustossen.
