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 Kampf siegen?

Ian Buchanan Ian Buchanan

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!

Although I've taken the hype to an extreme, the sound bites about Agile and DevOps can make them sound like very different ideas. Compounding the confusion, both concepts seem to defy definition, even as they have their own jargon and slogans. As the elder, Agile may be less vague, but it's certainly common for people to become frustrated with the myriad of definitions for DevOps. The lack of definition has lead to some common conflation. 

Many people think Agile means Scrum and DevOps means Continuous Delivery. This oversimplification creates an unnecessary tension between Agile and DevOps so you may be surprised to find that they are best friends!

There's no denying the historical connection between DevOps and Agile. When Patrick DuBois and Andrew Clay Schafer tried to connect at the Agile 2008 Conference about "Agile Infrastructure", the connection to DevOps was born. Although Patrick later coined the term "DevOps", the Agile Conference continues to honor this connection with a DevOps track. But let's dive deeper than history and consider the practical connections between Agile and DevOps, when we look below the surface of Scrum and Continuous Delivery.

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

Planung für ungeplante Aufgaben

In the DevOps community, those with Agile experience acknowledge that scrum is useful for tracking planned work. Some work in operations can be planned: releasing a big system change, moving between data centers, or performing system upgrades. But much of the work of operations is unplanned: performance spikes, system outages, and compromised security. These events demand immediate response. There's no time to wait for the items to be prioritized in a backlog or for the next sprint planning session. For this reason, many teams that have come to embrace DevOps thinking, look beyond Scrum to Kanban. This helps them track both kinds of work, and helps them understand the interplay between them. Or, they adopt a hybrid approach, often called Scrumban or Kanplan (kanban with a backlog).

In many ways, the key to Scrum's wide adoption may be that it prescribes no technical practices. Scrum's lightweight management practices often make a big difference for a team. Where there was once competing priorities from multiple masters, there is now a single set of priorities in the backlog. And where there was once too much work in progress, there is now a plan constrained by what time has shown is really possible. In combination, these can take a team to new levels of productivity. However, the team may find themselves constrained by the lack of technical practices, such as coding reviewsautomated acceptance tests, and 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.

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

DevOps besteht nicht nur aus Continuous Delivery

When done well, the discipline of Continuous Delivery (CD) helps to limit work in progress, while the automation of deployment helps to elevate constraints. In this way, CD helps a software team deliver more frequently and with higher quality, instead of having to choose between the two. However, just as teams focusing only on Scrum can miss the broader context of Agile, so too can teams focusing on Continuous Delivery miss the broader context of DevOps.

The practice of CD does not directly address problems in communication between the business and a software team. If the business has a year-long, budget-driven planning cycle, then a team delivering every commit into production may still have to wait months before the business can react. All too often those reactions come as step-functions, like canceling the project, or worse doubling the project team (because a large influx of new people is disruptive).

The Agile Fluency Model indicates the first level of fluency as "Focus on Value", where teams focus on transparency and alignment. Without this fluency, CD can easily devolve into an endless cycle of technical improvement that yields no appreciable value to the business. A team might get good at delivering fast with high quality, but for a product that has low value for end-users or the business. Even when there are many users who say good things, that assessment of low value might only be possible at a larger business portfolio level. Without this important fluency, it is hard to weigh technical practices against features. This is particularly important for a team with a legacy codebase, that may not have automated tests or a design suitable for frequent deployment. In a legacy context, a CD transformation may take years. So it's that much more important to be able to demonstrate business benefit.

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 emphasizes the performance of the entire system, as opposed to the performance of a specific silo of work or department — this can be as large as a division or as small as an individual contributor.
The Second Way Verstärkung des Feedbackkreislaufs 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 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 is characterized by the practice, "Devs wear pagers too."  Although the literal use of pagers may not be necessary, it means pulling developers into operational issues. This helps developers understand the consequences of their development choices. For example, that can inspire developers to put log messages in better places and to make those messages more meaningful. It's not just about awareness. Developers also bring their internal understanding of the system to troubleshooting efforts, so a resolution can be found and implemented faster.

The Third Way is about making incremental experiments in the system as a whole, not just as changes to the application moving through the pipeline. In other words, it's relatively easy to see how long automation takes and to use increasingly powerful infrastructure to keep improving it. It's harder to understand how the hand-offs between roles or organizations introduces delays. This means teams "inspect and adapt" across the whole delivery workflow, looking for opportunities to improve human collaboration. For that matter, CD requires a habit of adapting and improving. If the team doesn't reflect on how to become more effective, and then tune and adjust its behavior on anything else, then CD will not grow and thrive either. The team needs to feel empowered to solve their own problems.

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.

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

Finally, neither Agile nor DevOps are business goals in and of themselves. Both are cultural movements that can inspire your organization with better means for achieving your goals. Agile and DevOps work better in combination, than as adversaries. The trick to avoiding confrontation between these two ideas is to understand the deeper values and principles upon which they are formed. Quick, but narrow, definitions lead to siloed thinking. Now that you know there's more to Agile than Scrum, and there's more to DevOps than CD, you're ready to try the powerful Agile + DevOps combination.

Up Next
Tutorials