Im ersten Teil des Artikels haben wir darüber nachgedacht, dass Agile mehr als Scrum ist und dass agile Entwicklungsteams auf dem Weg zu einer DevOps-Kultur dazu übergehen sollten, technische Aufgaben als Features zu verstehen. Dieser zweite Teil knüpft daran nahtlos an.
DevOps ist mehr als Continuous Delivery
Wenn man es richtig macht, hilft Continuous Delivery, Work in Progress zu begrenzen, und die Automatisierung des Deployments unterstützt die Beseitigung von Beschränkungen. Dadurch versetzt CD ein Software-Team in die Lage, häufiger und mit höherer Qualität auszuliefern, statt aus beiden Vorteilen einen auswählen zu müssen. Aber ebenso, wie einem Team, das sich nur auf Scrum fokussiert, der breitere Kontext von Agile entgeht, läuft ein Team, dass sich nur auf CD fokussiert, Gefahr, den breiteren Kontext von DevOps zu verpassen.
Die CD-Praxis adressiert Probleme in der Kommunikation zwischen Business und Software-Team nicht direkt. Wenn es im geschäftlichen Bereich einen Budget-getriebenen Planungszyklus von einem Jahr gibt, muss ein Team, das jeden Commit in die Produktion ausliefert, vielleicht trotzdem Monate warten, bis das Business reagieren kann.
Das Agile Fluency Model indiziert die erste Fluency-Ebene als Focus on Value; hier fokussieren sich Teams auf Transparenz und Ausrichtung. Ohne diese Fluency kann CD sich schnell in einen endlosen Zyklus technischer Verbesserungen entwickeln, die keinen relevanten Geschäftswert schaffen. Ein Team wird vielleicht super darin, schnell und mit hoher Qualität auszuliefern – aber für ein Produkt, das für die Endnutzer oder das Business wenig Wert hat.
Ohne die wichtige Fluency ist es schwierig, die technischen Belange gegenüber Features abzuwägen. Das ist besonders wichtig für ein Team mit einer Legacy-Codebasis, in der es keine automatisierten Tests und kein Design gibt, das für häufige Deployments geeignet ist. In einem Legacy-Kontext kann die CD-Transformation Jahre dauern. Umso wichtiger ist es, Geschäftswert demonstrieren zu können.
Die drei Wege
DevOps ist mehr als die Automatisierung der Deployment-Pipeline. Es geht darum, dass Ops wie Devs denken und umgekehrt. Von Gene Kim gibt es The Three Ways als Prinzipien für DevOps:
| Der erste Weg | Systemdenken | Betont die Performance des gesamten Systems - im Gegensatz zur Performance einzelner Silos oder Abteilungen. |
| Der zweite Weg | Verstärkte Feedback-Zyklen | Erschaffung von Feedback-Schleifen. Das Ziel fast aller Prozessverbesserungs-Initiativen besteht darin, Feedback-Zyklen zu kürzen und zu verstärken. Also müssen notwendige Korrekturen kontinuierlich vorgenommen werden. |
| Der dritte Weg | Kultur des kontinuierlichen Experimentierens und Lernens | Etablierung einer Kultur, die auf zwei Dinge abzielt: kontinuierliche Experimente, das Eingehen von Risiken und das Lernen aus Fehlern sowie das Verständnis, dass Wiederholung und Übung die Voraussetzungen für Meisterschaft sind. |
Continuous Delivery fokussiert sich auf den ersten Weg: die Automatisierung des Flows von Dev zu Ops. Automatisierung spielt eine offensichtliche Rolle dabei, das Deployment-System beschleunigen zu helfen. Aber zu Systemdenken gehört mehr als nur Automatisierung.
Der zweite Weg ist durch die Praxis Devs wear pagers, too charakterisiert. Zwar muss es nicht ein Pager im Wortsinne sein, aber dahinter steckt, dass Entwickler in IT-Fragen involviert werden. Das hilft Entwicklern, die Konsequenzen ihrer Entwicklungsentscheidungen zu verstehen. Und es geht nicht nur um Bewusstsein. Entwickler bringen auch ihr internes Verständnis eines Systems in den Troubleshooting-Prozess ein, wodurch eine Lösung schneller gefunden und implementiert werden kann.
Der dritte Weg besteht darin, inkrementelle Experimente im System als Ganzem durchzuführen, nicht nur als Änderungen an der Applikation, die sich durch die Pipeline bewegt. Mit anderen Worten: Es ist relativ einfach zu sehen, wie lange Automatisierung braucht, und eine wachsende, leistungsstarke Infrastruktur zu nutzen, um diese Automatisierung zu verbessern. Schwieriger ist es zu verstehen, wie Hand-offs zwischen Rollen oder Organisationen zu Verzögerungen führen.
Das bedeutet, dass Teams über den gesamten Delivery-Workflow hinweg Inspect & Adapt betreiben und nach Möglichkeiten suchen müssen, die menschliche Zusammenarbeit zu verbessern. Eigentlich erfordert CD eine Kultur der Adaption und der Verbesserung. Wenn das Team nicht reflektiert, wie es effektiver werden kann, und dann sein Verhalten daraufhin abstimmt und anpasst, wird CD nicht wachsen und gedeihen. Das Team muss sich ermächtigt fühlen, seine eigenen Probleme zu lösen.
In Scrum ist jede Retrospektive eine Gelegenheit zur Verbesserung der Praktiken und Werkzeuge. Aber wenn das Team keine Vorteile aus diesen Gelegenheiten zieht, um sowohl kurzfristige als auch langfristige technische Probleme zu lösen, dann warten sie im Grunde nur darauf, dass der Product Owner kommt und CD-Aufgaben ins Backlog packt, was nie geschehen wird.
DevOps ist angewandtes Agile übers Software-Team hinaus
Scrum bildet hauptsächlich das agile Prinzip ab, auf veränderte Anforderungen reagieren zu können, selbst wenn sie spät im Prozess hereinkommen. Agile Prozesse zügeln Veränderungen zum kompetitiven Vorteil des Kunden.
Continuous Delivery bildet vor allem das agile Prinzip ab, die Kunden durch die frühzeitige und kontinuierliche Auslieferung werthaltiger Software zufriedenzustellen.
Das bedeutet, dass es bei Agile in erster Linie um das Annehmen ein- und ausgehender Veränderungen geht. Allerdings umfasst das Agile Manifest zehn weitere Prinzipien. Statt zu versuchen, unter diesen Prinzipien eine Auswahl zu treffen, sollten sie im Ganzen berücksichtigt werden. Zusammen repräsentieren sie eine Einstellung im Hinblick auf Veränderungen, die sowohl Agile als auch DevOps gemeinsam haben.
Die Leute waren in der Zwickmühle, versuchen zu müssen, fragile Systeme zu betreiben, die zugleich sehr wichtig für das Business sind. Und weil sie so wichtig fürs Business sind, sind sie auch diejenigen, für die die meisten dringenden Änderungen gebraucht werden. Die agile Idee, Veränderung anzunehmen, meint nicht Veränderung um ihrer selbst willen. Es geht darum, die Entwicklung für die Qualität der Veränderungen in Verantwortung zu halten, während die Gesamtkapazität verbessert wird, um Wert auszuliefern. Der Fokus auf dem Geschäftswert ist ein weiterer Aspekt, den Agile und DevOps teilen.
Schlussendlich sind weder Agile noch DevOps Geschäftsziele an und für sich. Beides sind kulturelle Bewegungen, die das Unternehmen im Hinblick auf bessere Möglichkeiten zum Erreichen seiner Ziele inspirieren können. Der Trick, um zu vermeiden, dass es Konfrontationen zwischen beiden Ideen gibt, besteht darin, die tieferen Werte und Prinzipien zu verstehen, auf denen sie aufgebaut sind. Schnelle und knappe Definitionen führen zu Silo-Denken. Erst, wer verstanden hat, dass Agile mehr ist als Scrum und DevOps mehr als Continuous Delivery, ist bereit, die mächtige Kombination aus beiden Ansätzen für sich zu nutzen.
Weiterführende Infos
Atlassian-Studie: Trends und Benchmarks in der Software-Entwicklung 2016
Das Agile-Portal in unserer Infothek
Don’t feed the Undone-Monster! – Vortrag von der Tools4AgileTeams-Konferenz 2016
Continuous Documentation (Jörg Müller-Kindt auf der Tools4AgileTeams2016)
