Wie greifen Agile und DevOps ineinander?

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 der 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.

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 ansehen, entdecken wir, dass es neben der Geschichte aber auch noch praktische Verbindungen zwischen Agile und DevOps gibt.

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 Agile-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.

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 System-Upgrades. 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 Quellen 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 beiden Änderungen für ein ganz neues Maß an Produktivität im Team sorgen. Möglicherweise fehlen dem Team dennoch technische Verfahren wie Code-Prüfungen, automatisierte Akzeptanztests und Continuous Integration.

Verfechter von anderen Agile-Prozesse 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 Product Owner im Hinblick auf die Features. Wenn es sich bei den Product Ownern 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.

Wir bei Atlassian haben erkannt, dass wir mit zwei unterschiedlichen Rollen für die von uns betriebenen Produkte besser zurechtkommen. Unsere Product Owner 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 Service Owner, 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 Product Owner 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 Agile-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.

Bei richtiger Umsetzung hilft Continuous Delivery (CD), die laufenden Arbeiten (WIP) 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.

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":

Im Mittelpunkt von Continuous Delivery 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 (Der dritte Weg) 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 Product Owner CD-Aufgaben in das Backlog aufnimmt – was niemals der Fall sein wird.

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 an späten Punkten 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 Stand-up-Meetings 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.