Agile und DevOps: Freunde oder Feinde?

DevOps ist wie Agile, jedoch über das Softwareteam hinaus angewendet. Die wahre Frage lautet jedoch: Welcher Ansatz würde in einem Wettkampf siegen?

Ian Buchanan Ian Buchanan
Themen durchsuchen

In der einen Ecke haben wir den zertifizierten Scrum Master, seinen Freunden auch als "der Extremprogrammierer" und seinen Kindern als der "LeSS SAFe DAD" bekannt: Agile!

In der anderen Ecke den Lean-Culture-Profi, der auf Continuous Delivery und Infrastruktur als Code setzt. Seinen linken Arm nennt er Dev, den rechten Ops: DevOps!

Ich mag etwas übertrieben haben, aber wenn man Meinungen über Agile und DevOps hört, könnte man sie für völlig verschiedene Ideen halten. Zur Verwirrung trägt bei, dass sich beide Konzepte jeder Definition zu entziehen scheinen. Sie haben sogar eigene Jargons und Slogans. Agile als der ältere Ansatz ist vielleicht etwas weniger vage, aber zumindest für DevOps gibt es Definitionen wie Sand am Meer. Durch diesen Mangel an klaren Definitionen ist es zu gängigen Bedeutungsverschmelzungen gekommen. 

Agile wird oft mit Scrum gleichgesetzt, DevOps mit Continuous Delivery. Diese übermäßige Vereinfachung führt zu unnötigen Spannungen zwischen Agile und DevOps. Vielleicht überrascht es dich, dass die beiden eigentlich beste Freunde sind.

Die historische Verbindung zwischen DevOps und Agile lässt sich nicht leugnen. Als Patrick Debois und Andrew Clay Schafer bei der Agile Conference 2008 versuchten, zu einer Übereinkunft über die "Agile Infrastruktur" zu gelangen, schlugen sie die Brücke zu DevOps. Der Ausdruck "DevOps" wurde zwar erst später von Patrick Debois geprägt, aber die Agile Conference hält mit dem DevOps-Track diese Verbindung immer noch in Ehren. Wenn wir uns Scrum und Continuous Delivery genauer anschauen, entdecken wir, dass es neben der Geschichte aber auch noch praktische Verbindungen zwischen Agile und DevOps gibt.

Agile ist mehr als Scrum

In manchen Teams macht Scrum den Unterschied zwischen einem ständigen, frustrierenden Kampf und produktiver, erfolgreicher Teamarbeit aus. In anderen Teams ersetzt Scrum politische Schachzüge und Überengagement durch Objektivität und einen klaren Fokus. Es kann auch als Dogma vertreten werden. Wenn die Gegebenheiten im Unternehmen oder bei der Arbeit selbst etwas anderes verlangen, nutzt ein agiles Team zwar die grundlegenden Scrum-Prinzipien, passt jedoch die entsprechenden Praktiken an, um effektiver zu arbeiten. Dies ist besonders bei der Anwendung von Scrum außerhalb der Softwareentwicklung wichtig.

Planung für ungeplante Aufgaben

Die in Agile erfahrenen Mitglieder der DevOps-Community wissen, dass Scrum beim Verfolgen ungeplanter Aufgaben hilfreich ist. Manche Aufgaben von Operations-Teams lassen sich planen: die Releases für eine größere Systemumstellung, die Migration zwischen Rechenzentren oder auch die Durchführung von Systemupgrades. Der größte Teil der Arbeit von Ops-Teams besteht jedoch aus ungeplanten Aufgaben infolge von Leistungsspitzen, Systemausfällen oder Sicherheitsvorfällen. Ereignisse dieser Art erfordern eine sofortige Reaktion. Das Team kann nicht warten, bis die entsprechenden Aufgaben in einem Backlog für die nächste Sprint-Planungssitzung priorisiert wurden. Aus diesem Grund nutzen viele auf DevOps ausgerichtete Teams Kanban statt Scrum. So können sie geplante und ungeplante Aufgaben gleichermaßen verfolgen und das Wechselspiel zwischen beiden analysieren. Manche Teams setzen auch auf einen hybriden Ansatz, der oft als "Scrumban" oder "Kanplan" (Kanban mit Backlog) bezeichnet wird.

Ausschlaggebend für die weite Verbreitung von Scrum ist in vielerlei Hinsicht die Tatsache, dass dabei keine technischen Praktiken vorgeschrieben werden. Die schlanken Managementverfahren von Scrum sind für viele Teams ein großer Vorteil. Wo früher die Prioritäten mehrerer Master miteinander konkurrierten, gibt es jetzt nur noch einen Satz Prioritäten im Backlog. Das frühere Übermaß an laufenden Arbeiten wurde durch einen auf Erfahrungswerten beruhenden konkreten Zeitplan ersetzt. Zusammen können diese Änderungen für ein ganz neues Maß an Produktivität im Team sorgen. Möglicherweise fehlen dem Team dennoch technische Praktiken wie Code-Reviewsautomatisierte Akzeptanztests und Continuous Integration.

Verfechter von anderen agilen Prozessen wie Extreme Programming sind überzeugt von der Bedeutung technischer Praktiken für eine nachhaltige Geschwindigkeit im Team sowie für die Transparenz gegenüber dem Management und den Stakeholdern. Manche Scrum-Teams gehen dazu über, technische Aufgaben im Backlog festzuhalten. Diese Vorgehensweise ist zwar im Einklang mit den Leitlinien von Scrum, führt jedoch in der Praxis schnell zu Problemen aufgrund der Voreingenommenheit der Produktinhaber im Hinblick auf die Features. Wenn es sich bei den Produktinhabern nicht gerade um Technikexperten handelt, sind sie mit der Kosten-Nutzen-Analyse der technischen Praktiken schnell überfordert. Dies gilt insbesondere bei technischen Aufgaben, die Einfluss auf die Zuverlässigkeit, Leistung und Sicherheit und somit auf den Operations-Bereich haben.

Product Owner und Service Owner

Wir bei Atlassian haben erkannt, dass wir mit zwei unterschiedlichen Rollen für die von uns betriebenen Produkte besser zurechtkommen. Unsere Produktinhaber wissen sehr gut, welche Features die Benutzer benötigen, können diese Features jedoch weniger gut gegen nichtfunktionale Aspekte wie Leistung, Zuverlässigkeit und Sicherheit abwägen. Deshalb gibt es für einige SaaS-Produkte bei Atlassian zusätzlich einen Serviceverantwortlichen, der für die Priorisierung dieser nichtfunktionalen Aspekte zuständig ist. Mit der Ausnahme gelegentlicher Verhandlungen zwischen den beiden Verantwortlichen können diese Rollen in voneinander unabhängigen Teams vertreten sein. Sicherlich gibt es auch andere Möglichkeiten, das Feedback des Operations-Teams zu "verstärken", aber uns hilft diese Methode, die gängige Voreingenommenheit der Produktinhaber im Hinblick auf Features zu überwinden. Der Ansatz mit zwei Verantwortlichen ist nicht der einzige Weg zu DevOps. Es ist nur wichtig, die nichtfunktionalen Aspekte ebenfalls als "Features" zu betrachten und sie genauso zu planen und zu priorisieren wie die funktionalen User Storys.

Letztlich sind alle diese Kritikpunkte in Bezug auf Scrum nicht auf Scrum selbst zurückzuführen. Wie bei allen agilen Methoden gibt es bei Scrum integrierte Mechanismen zur Prozessverbesserung, die als Retrospektiven bezeichnet werden. Daher gehen wir davon aus, dass manche Scrum-Teams DevOps als Inspirationsquelle nutzen und mit Scrum-Retrospektiven ihre Vorgehensweisen in Richtung DevOps optimieren und anpassen. Dennoch kommen die wenigsten Teams ohne Denkanstöße von außen aus. Solange DevOps noch nicht Mainstream ist (und vielleicht sogar im Studium oder in der Ausbildung vermittelt wird), ergibt es sich nicht natürlicherweise aus Scrum. Wahrscheinlich ist es unerheblich, ob das Team einen Agile- oder einen DevOps-Coach engagiert, solange dieser Erfahrung beim Automatisieren von Erstellung, Tests und Deployment im Zusammenhang mit Software vorweisen kann.

DevOps besteht nicht nur aus Continuous Delivery

Bei richtiger Umsetzung hilft Continuous Delivery (CD), die laufenden Arbeiten zu begrenzen, während das automatisierte Deployment zur Lockerung von Einschränkungen beiträgt. So kann ein Team mithilfe von CD häufigere und hochwertigere Releases erzielen, statt sich zwischen Geschwindigkeit und Qualität entscheiden zu müssen. Dennoch ist hier wie bei Scrum und Agile anzumerken, dass den auf Continuous Delivery fokussierten Teams möglicherweise der breiter gefasste Kontext von DevOps entgeht.

CD befasst sich nicht mit Kommunikationsproblemen zwischen dem Unternehmen und dem Softwareteam. Wenn das Unternehmen einen auf das ganze Jahr ausgelegten, budgetgesteuerten Planungszyklus verfolgt, muss das Team, das die Commits in die Produktion überträgt, möglicherweise mehrere Monate warten, bis das Unternehmen reagieren kann. Die Reaktion ist dann häufig nur eine Notlösung, beispielsweise eine Stornierung des Projekts oder – noch schlimmer – eine Verdoppelung des Projektteams (die deshalb negativ zu bewerten ist, weil das Hinzukommen einer großen Anzahl neuer Teammitglieder zu Unterbrechungen führt).

Im Agile Fluency-Modell stellt der "Focus on Value" (Fokus auf dem Nutzen), bei dem sich die Teams auf Transparenz und Abstimmung konzentrieren, die erste Ebene der Versiertheit (Fluency) dar. Wenn ein Team in dieser Hinsicht nicht versiert ist, verkommt CD schnell zu einem endlosen Kreislauf technischer Verbesserungen, die dem Unternehmen keinen nennenswerten Nutzen bringen. Ein Team erzielt vielleicht schnelle, hochwertige Lieferungen – dies jedoch bei einem Produkt mit geringem Nutzen für die Endbenutzer oder das Unternehmen. Selbst wenn sich viele Benutzer positiv äußern, wird der geringe Nutzen vielleicht bei Betrachtung des gesamten Unternehmensportfolios deutlich. Ohne diese Versiertheit kann ein Team nur schwer zwischen technischen Praktiken und Features abwägen. Dies gilt insbesondere für Teams mit einer Legacy-Codebasis ohne automatisierte Tests und ohne ein auf häufige Deployments ausgelegtes Design. In einer Legacy-Umgebung kann eine Transformation hin zu CD mehrere Jahre dauern. Daher muss das Team unbedingt in der Lage sein, die Vorteile für das Unternehmen herauszustellen.

The Three Ways

DevOps ist mehr als nur eine Automatisierung der Deployment Pipeline. Laut John Allspaw bedeutet DevOps, dass Mitglieder des Operations-Teams wie Entwickler denken und umgekehrt. Vor diesem Hintergrund erläutert Gene Kim die grundlegenden Prinzipien von DevOps als "The Three Ways":

The First Way Systemdenkweise Betrachtet wird die Leistung des gesamten Systems statt der Leistung eines einzelnen Arbeitssilos oder einer einzelnen Abteilung. Dabei spielt es keine Rolle, ob der Beitrag von einem ganzen Geschäftsbereich oder von einem einzelnen Mitarbeiter ausgeht.
The Second Way Erweiterung der Feedbackkreisläufe Hier geht es um das Erstellen des strukturierten Feedbackkreislaufs. Das Ziel nahezu jeder Prozessverbesserungsinitiative ist die Verkürzung und Erweiterung von Feedbackkreisläufen, damit die nötigen Korrekturen vorgenommen werden können.
The Third Way Unternehmenskultur des stetigen Experimentierens und Lernens Schaffung einer Unternehmenskultur, die zwei Dinge fördert: auf der einen Seite stetiges Experimentieren, Risikobereitschaft und Lernen aus Fehlern, auf der anderen Seite das Wissen, dass Wiederholung und Übung den Meister machen.

 

Im Mittelpunkt von Continuous Delivery (CD) steht The First Way: die Automatisierung der Abläufe von Dev zu Ops. Automatisierung trägt selbstverständlich maßgeblich zur Beschleunigung eines Deployment-Systems bei. Die Systemdenkweise betrifft jedoch nicht nur die Automatisierung.

The Second Way beruht auf dem Grundsatz "Auch Entwickler haben Pager". Pager mögen nicht unbedingt erforderlich sein, aber die Entwickler sollen in die Belange des Operations-Teams einbezogen werden. So können sie die Folgen ihrer Entwicklungsentscheidungen besser einschätzen. Vor diesem Hintergrund platzieren sie Protokollmeldungen vielleicht an einer besser geeigneten Stelle und sorgen für einen aussagekräftigeren Text der Meldungen. Es geht nicht nur um das Bewusstsein. Die Entwickler tragen mit ihren internen Systemkenntnissen auch zur Fehlerbehebung bei, sodass Lösungen schneller gefunden und implementiert werden können.

The Third Way bezieht sich auf inkrementelle Experimente im System als Ganzes, d. h. nicht nur durch Änderungen an der Anwendung in der Pipeline. So ist relativ leicht ersichtlich, wie lange die Automatisierung dauert und wie sie mit einer immer leistungsstärkeren Infrastruktur weiter optimiert werden kann. Weniger offensichtlich ist das Entstehen von Verzögerungen durch Übergaben zwischen verschiedenen Rollen oder Organisationen. Die Teams nehmen also im gesamten Auslieferungs-Workflow Prüfungen und Anpassungen vor, um die menschliche Zusammenarbeit zu verbessern. Für CD sind die ständigen Anpassungen und Optimierungen unerlässlich. Wenn das Team nicht überlegt, wie es effektiver arbeiten könnte, und sein Verhalten daher an anderen Punkten ausrichtet, entwickelt sich auch CD nicht weiter. Das Team muss sich in der Lage sehen, seine eigenen Probleme zu lösen.

Bei Scrum bietet jede Retrospektive die Gelegenheit, Praktiken und Tools zu verbessern. Diese Gelegenheit ist jedoch vertan, wenn das Team kurzfristige und langfristige technische Probleme nicht im Zuge der Retrospektiven löst und stattdessen wartet, bis der Produktinhaber CD-Aufgaben in das Backlog aufnimmt – was niemals der Fall sein wird.

DevOps ist wie Agile, jedoch über das Softwareteam hinaus angewendet

Scrum bezieht sich in erster Linie auf das Agile-Prinzip "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage." (Begrüße Änderungsanforderungen, auch zu einem späten Zeitpunkt in der Entwicklung. Agile Prozesse nutzen Änderungen als Wettbewerbsvorteil des Kunden.)

Continuous Delivery hat hauptsächlich Bezug zum Agile-Prinzip "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." (Die höchste Priorität liegt darin, die Kunden durch eine frühe und kontinuierliche Bereitstellung wertvoller Software zufriedenzustellen.)

Agile bedeutet also vor allem, dass eingehende und ausgehende Änderungen positiv aufgefasst werden. Rituale wie Standups und die Sprint-Planung sind weniger wichtig. Im "Agile Manifesto" sind zehn weitere Prinzipien festgehalten. Teams sollen jedoch keine Auswahl aus diesen Prinzipien treffen, sondern sie alle berücksichtigen. Zusammen stehen die Prinzipien für eine Haltung gegenüber Änderungen, die sowohl für Agile als auch für DevOps gilt.

Diese Teams stehen vor der Herausforderung, empfindliche Systeme mit enormer Bedeutung für das Unternehmen zu betreiben. Auch die dringendsten Änderungsanforderungen betreffen diese kritischen Systeme. Die für Agile typische positive Einstellung gegenüber Änderungen begrüßt Änderungen nicht um ihrer selbst willen. Vielmehr soll das Entwicklerteam die Verantwortung für die Qualität der Änderungen übernehmen und die Kapazität insgesamt verbessern, um dem Unternehmen einen Mehrwert zu bieten. Auch diesen Fokus auf dem geschäftlichen Nutzen haben Agile und DevOps gemein.

Abschließend ist festzuhalten, dass weder Agile noch DevOps als eigenständige Unternehmensziele verstanden werden sollten. Bei beiden handelt es sich um die Unternehmenskultur betreffende Bewegungen, die dem Unternehmen Inspiration zu besseren Möglichkeiten der Zielerreichung liefern sollen. Agile und DevOps funktionieren im Zusammenspiel besser als bei Rivalität. Wer Konfrontationen zwischen den beiden Ideen vermeiden möchte, muss sich mit den ihnen zugrunde liegenden Werten und Prinzipien beschäftigen. Schnelle, zu eng gefasste Definitionen führen zu Silodenken. Da du nun weißt, dass hinter Agile mehr steckt als nur Scrum und hinter DevOps mehr als nur CD, kannst du dir die leistungsstarke Kombination aus Agile und DevOps zunutze machen.

Weiter geht's
Agile Teams