Früher war alles besser
Die Toten Hosen – Wort zum Sonntag
Früher war alles gut
Da hielten alle noch zusammen
Die Bewegung hatte noch Wut
Ja, früher war einiges besser. Sage ich als „Noch-Jungspund“.
Beispiel gefällig?
Früher brauchtest du sehr gute Argumente dafür, wenn du einen Prozess automatisieren wolltest.
Und heute?
Heute kannst du dir nicht einmal die Zeit nehmen, einen Prozess zu verstehen, bevor du ihn automatisieren musst.
Das Prinzip dahinter: Alles muss automatisiert werden.
Der Zweck: Die menschliche Lebenszeit ist zu wertvoll, um sich wiederholende Tätigkeiten auszuführen.
Oder auf „Management-Deutsch“: Wir müssen die menschliche Ressource einsparen und so weit wie möglich automatisieren. Damit sparen wir Kosten.
Das blöde daran: Dieses naive Vorgehen ist richtig teuer und extrem fehleranfällig.
„Wenn sie einen Scheißprozess digitalisieren, dann haben sie einen scheiß digitalen Prozess.“
Thorsten Dirks, CEO von Telefónica Deutschland auf dem Wirtschaftsgipfel der ‚Süddeutschen Zeitung‘ über schlechte Digitalisierungsprojekte
Warum du nicht alles automatisieren solltest? Zumindest nicht sofort…
Ich bin ein totaler Anhänger der Automatisierung. Menschen in meinem Umfeld verschwenden ihre Lebenszeit damit, Dinge zu tun, die ein Computer viel besser tun könnte. Aber inzwischen verschwenden noch viel mehr Menschen in meinem Umfeld ihre Lebenszeit damit, Prozesse zu automatisieren, die sie nicht verstanden haben.
Das Ergebnis?
Fehleranfällige Systeme, chaotische Bugfix-Orgien, ein Postmortem nach dem anderen, Downtimes und unzufriedene Nutzer.
Und die Erkenntnis: Wir haben das Problem nicht verstanden.
Erst das Problem, dann die Lösung
Ich liebe die agile Arbeitswelt. Die radikal agile Arbeitswelt, nicht dieses stumpfe Etwas, das dir als agil verkauft wird.
Letzte Woche hatte ich bereits im Artikel „Sind agile Arbeitsweisen effizient? Nein, aber …“ beschrieben, warum agile Arbeit nicht effizient ist. Heute gehen wir in die Praxis. Wie näherst du dich eigentlich am besten dem Problem der Automatisierung? Und ab wann solltest du wirklich automatisieren?
Schritt 1: Das Problem verstehen. Wirklich verstehen.
„Wenn ich eine Stunde habe, um ein Problem zu lösen, beschäftige ich mich 55 Minuten mit dem Problem und 5 Minuten mit der Lösung.“
Zitat wird Albert Einstein zugeschrieben.
Um das Problem wirklich zu verstehen, haben sich für mich einige Methoden etabliert. Die einfachste und gleichzeitig eine der wirkungsvollsten Methoden sind die Leitfragen, zum Beispiel:
- Was ist das konkrete Problem, was wir lösen möchten? Warum? Warum? Warum? … (5 Whys)
- Kann ich das Problem in Teilprobleme herunterbrechen?
- Habe ich die Rahmenbedingungen verstanden? Welche sind das? Wie wirken sie sich aus? Wozu sind sie nützlich?
- Für wen ist die Automatisierung gedacht? Welche konkreten Anforderungen hat derjenige? Warum? Was steckt dahinter?
- Was soll die Automatisierung explizit nicht leisten? Warum?
- …
Am Ende der Problemdefinition ordnest du das Problem auf dem Cynefin-Framework einer Kategorie zu. Wie dir das Cynefin-Framework im radikal agilen Kontext hilft? Das zeige ich dir ein anderes Mal.
Hast du das zu lösende Problem einer Cynefin-Kategorie zugewiesen, dann kannst du schön ablesen, wie du damit umgehen solltest. Um es kurz zu halten. Du kannst nur Probleme der Kategorie „Einfach“ und „Kompliziert“ automatisieren.
Problemdefinition am Beispiel „Wie du eine CI/CD-Pipeline aufbaust“
Problembeschreibung: Du möchtest regelmäßig und verlässlich Software-Artefakte in Produktion bringen.
Warum musst du das Problem lösen? Bei den bisherigen Releases gab es immer wieder Probleme bei der Auslieferung in Produktion. Deshalb soll der Prozess standardisiert werden.
Rahmenbedingungen festlegen:
- Das Artefakt muss gebaut werden.
- Das Artefakt muss auf Herz- und Nieren getestet werden: Security, Code Qualität, funktionale Eignung, Verhalten bei Sonderfällen, Zusammenspiel mit anderen Komponenten.
- Nutzbare Technologien sind durch das Unternehmen vorgegeben.
- Die Fähigkeiten der Teammitglieder müssen beachtet werden.
- …
Welche weiteren Fragestellungen ergeben sich aus der Problemstellung?
- Sollen in einer bestimmten Stage manuelle Tests erfolgen? z.B. Smoke-Tests, explorative Tests?
- Soll automatisch in Produktion deployed werden oder auf Knopfdruck?
- Welches Branching-Modell ist für dich am wirkungsvollsten?
- Wie konfigurierst du deine Applikation?
- Wie stellst du die Kompatibilität zu anderen Komponenten sicher? Durch echte Komponenten (dadurch blockieren sich die einzelnen Teams, es führt schnell vom 100tel ins 1000tel) oder durch Mockups (dadurch fallen Fehler später auf, die Implementierung basiert auf Annahmen).
- …
Das Problem „Software-Artefakte regelmäßig und verlässlich in Produktion bringen“ kann zu diesem Zeitpunkt als „Kompliziert“ klassifiziert werden.
Schritt 1: Das eigentliche Problem identifizieren
Schritt 2: Dann Ideen zur Lösung identifizieren
Hast du dein Problem jetzt eingekreist und die Cynefin-Kategorie festgestellt, geht es nun weiter, mögliche Lösungsoptionen zu evaluieren.
Vorsicht: Automatisierung ist keine Lösungsoption. Es ist nur ein Hilfsmittel.
Lösungsideen lassen sich durch eine einfache Technik finden: Die Perspektive ändern und dadurch die unterschiedlichen Lösungsoptionen entdecken.
Lösungsoptionen finden am Beispiel „Wie du eine CI/CD-Pipeline aufbaust“
Schritt 2: Lösungsoptionen herausarbeiten
- Zusammenfassen/Verallgemeinern: Du setzt dich mit anderen zusammen, die das gleiche Problem haben und versuchst einen guten Kompromiss auszuarbeiten, mit dem alle zufrieden sind. Die Lösung wird dann von einem für alle aufgebaut. In dem Beispiel baut ein Team eine Pipeline und stellt sie den anderen Teams als Blueprint zur Verfügung. Oder es wird ein Enablement-Team gebildet, das diese Aufgabe und die Wartung übernimmt.
- Herunterbrechen in Teilprobleme: Du nimmst das Problem und versuchst einfache Teilprobleme zu identifizieren. Diese einfach zu lösenden Teilprobleme sind dann die einzelnen Schritte, die für sich automatisiert und dann in Form einer Pipeline orchestriert werden können.
- Shift left: Das Problem in einem möglichst früheren Schritt gelöst. Was spricht dagegen, Softwareartefakte direkt auf den Workstations der Entwickler zu bauen, durchzutesten, auf Sicherheitslücken und Code Smells zu überprüfen und in ein zentrales Repository zu deployen?
- …
Schritt 3: Dann die Lösung
Nun wählst du anhand der identifizierten Rahmenbedingungen eine konkrete Lösung aus. Bedenke: Diese Lösung ist eine Annahme, manchmal auch als (Arbeits-)Hypothese bezeichnet. Du hast zu dem Zeitpunkt noch nicht nachgewiesen, dass diese Lösung funktioniert. Du triffst also eine Annahme, welche Lösungsoption dir den meisten Nutzen bringt.
Dann probierst du sie auf einfachste Weise aus und überprüfst dann, ob das Ergebnis so ist, wie du es dir vorgestellt hast. Erst wenn du diese Schritte durchgeführt hast und die Nützlichkeit der Annahme und des Ergebnisses sichergestellt hast, erhebst du dieses Vorgehen zum Standard.
Merkst du was? Hier beginnt der PDCA-Zyklus: Plan-Do-Check-Act.
Gewählte Lösungsoption manuell validieren am Beispiel „Wie du eine CI/CD-Pipeline aufbaust“
Du hast anhand der Rahmenbedingungen die Option „Herunterbrechen in Teilprobleme“ als für dich beste Variante identifiziert. Nun gehst du Schritt für Schritt durch diese Teilprobleme.
Schritt 3: Lösung manuell durchführen und Erfahrung sammeln
- Du führst diesen Prozess pro Teilschritt noch einmal aus,
- Du führst den Teilschritt so lange manuell aus, bis du dir sicher bist, ein gutes Vorgehen gefunden zu haben,
- Du automatisierst diesen Teilschritt nach auf die gleiche Weise wie den Prozess.
- Du testest die Automatisierung so lange, bis du dir sicher bist, dass sie einwandfrei funktioniert,
Schritt 4: Dann die Automatisierung
Jetzt bist du so weit. Du kannst endlich mit der Automatisierung beginnen.
Was hast du bisher erreicht?
- Du hast ein Glasklares Bild davon, was du konkret automatisieren möchtest.
- Du weißt genau, warum du gerade diese Lösungsoption gewählt hast und kannst dir sicher sein, dass sie nachhaltig funktioniert.
- Du hast dokumentiert, warum du dich genau für diese Lösung entschieden hast und welche Lösungsoptionen du aus welchen Gründen verworfen hast, damit spätere Diskussionen im Keim erstickt werden.
Jetzt automatisierst du den bereit manuell getesteten und validierten Prozess. Das ist der einfachste Schritt, weil du bereits die notwendige Vorarbeit geleistet hast.
Automatisieren am Beispiel „Wie du eine CI/CD-Pipeline aufbaust“
Du hast bereits die Teilschritte automatisiert. Jetzt ist der Zeitpunkt gekommen, diese Teilschritte in die richtige Reihenfolge zu bringen und mit der Pipeline-Technologie umzusetzen.
Schritt 4: Jetzt wird automatisiert
Ist dir das Vorgehen zu formal?
Ich kann dich beruhigen. Wenn du dieses Vorgehen verinnerlicht hast, ist es bei einfachen Problemen eine Sache von wenigen Minuten, die Schritte durchzugehen, für die Nachwelt und dein zukünftiges ich zu dokumentieren und dann mit der Umsetzung zu beginnen.
Ist es ein kompliziertes Problem, dann dauert das Vorgehen zwar länger. Allerdings kommst du erfahrungsgemäß in sehr vielen Fällen mit einer deutlich besseren und einfacheren Lösung heraus, als wenn du sofort mit der Automatisierung begonnen hättest. Die Wahrscheinlichkeit, dass du dich nach dieser Problemanalyse bei der Automatisierung verzettelst, ist deutlich geringer.
Und: Auch hier hast du genau die Informationen erarbeitet, die du für die Nachwelt und dein zukünftiges ich dokumentieren solltest. Außer du hast Spaß daran, immer wieder valide Lösungen neu zu bewerten, durchzudiskutieren, weil es ein neues Tool X gibt, dass verspricht, es ein bisschen besser zu können.
Möchtest du eine nachhaltige, sichere CI/CD-Pipeline aufbauen und brauchst dafür einen Mentor?
Dann schreib mir eine kurze E-Mail an johannes@radikal-agile.de.
Denn: In Wirklichkeit ist das Beispiel oben stark vereinfacht, um das Vorgehen zur nachhaltigen und wartbaren Automatisierung zu beschreiben. Auch wenn das Thema CI/CD-Pipelines ein gelöstes Problem zu sein scheint, wirken die meisten Pipelines eher wie Jugend forscht. Du bezahlst für einen Tesla und bekommst eine Seifenkiste, die bei jeder Kurve auseinanderbrechen kann.
Um eine nachhaltige, wartbare und dauerhaft nützliche CI/CD-Pipeline aufzubauen, müssen deutlich mehr Fragen im Vorfeld gestellt und geklärt werden, die konkreten Konzepte verstanden und bewertet werden und die richtigen Technologien für das konkrete Problem herausgesucht und orchestriert werden. Dabei kann ich dich unterstützen.
Warum ist mir das Thema CI/CD-Pipelines so wichtig?
CI/CD-Pipelines sind das Rückgrat der modernen Software-Entwicklung und einer der wichtigsten Faktoren, die über Sieg oder Niederlage entscheiden.
Die radikal agilen Lösungen fokussieren sich auf den Flow, also den Arbeitsfluss.
Neben der darauf ausgerichteten Arbeitsweise, (z.B. mithilfe des radikal agilen Kanban-Workshops) ist das Software-Fließband, also die CI/CD-Pipeline eine der entscheidenden Komponenten für die Teamproduktivität.