Scrum und DevOps, wie passt das zusammen?

Viel zu oft wird die Frage gestellt, welches agile Vorgehensmodell in der Softwareentwicklung verwenden werden sollte: Scrum oder DevOps? Wieso ist das so? Denn in der Vergangenheit hat sich immer wieder gezeigt, dass sich diese beiden Systeme perfekt ergänzen.

Scrum

Scrum, ist ein einfaches Framework, welches ursprünglich zur agilen Softwareentwicklung eingesetzt wurde, aber davon unabhängig ist. Es wird inzwischen in vielen anderen Bereichen eingesetzt und basiert auf Werten, Events und Prinzipien. Der Fokus liegt auf dem, was im Sprint passiert. In diesem agilen Vorgehensmodell gibt es keine festgelegten Vorschriften, wie der Prozess aussehen soll, sondern es handelt sich lediglich um ein Minimum von Anforderungen. Es steht den Anwendern des Frameworks frei, weitere Praktiken hinzuzufügen. Dies ist sogar gewünscht, um den Fluss der Wertschöpfung innerhalb des Scrum Frameworks zu verbessern.

DevOps

Im konventionellen Verständnis sind Softwareentwicklung und IT-Betrieb grundverschiedene Bereiche. Der DevOps-Ansatz vereint diese jedoch mit dem Ziel einer beschleunigten Entwicklung von qualitativ hochwertigeren Produkten. Dafür werden spezielle Anreize, Werkzeuge (Tools) und Prozesse eingesetzt. DevOps betrachtet den gesamten Wertstrom im System, anstatt nur in die Entwicklungsphase zu zoomen und diese zu optimieren. So entsteht ein Systemdenken, welches die Zusammenarbeit der verschiedenen Teilbereiche verbessert. Dies führt auch zu einer schnelleren Softwareentwicklung mit besserer Kooperation zwischen den einzelnen Teams.

DevOps funktioniert deswegen so gut mit Scrum, weil der agile Ansatz auf den gesamten Wertstrom angewendet werden kann, anstatt nur in der IT-Abteilung. Anhand des folgenden Beitrags wird erläutert, wie ein solches kombiniertes Vorgehen aussehen kann und welche Verbesserungen damit zu erwarten sind. Ähnlich der agilen Arbeitsweise handelt es sich hierbei nicht um ein starres Regelwerk, sondern vielmehr um eine Inspiration: Jedes Team muss die für sich passende Vorgehensweise finden.

Im klassischen Scrum-Ansatz besteht das Entwicklungsteam aus Experten, die die Arbeit verrichten und am Ende eines jeden Sprints ein potenziell Release-fähiges Increment liefern. DevOps hingegen betrachtet den gesamten Wertstrom und setzt Systemdenken ein. Dadurch erweitert sich das Scrum-Team um alle, die am Product Backlog Item im gesamten Wertstrom von Ende zu Ende beteiligt sind. So entsteht eine Zusammensetzung aus Marketing-Mitarbeitern, UI/UX-Designern, Entwicklern, Test-Teams und vielen weiteren Einheiten, um ihren Kunden den größten Mehrwert zu bieten.

DevOps drei Wege im Scrum Framework

Eine Erkenntnis der letzten Jahre ist, dass sich alle DevOps Praktiken auf drei Prinzipien eingrenzen lassen, diese basieren auf dem Lean-Denken und dem Systemdenken: die sogenannten „Three Ways“. Keiner dieser drei Wege steht in Konflikt mit dem Scrum Framework und den Scrum Values, da es sich nicht um konfliktträchtige Tools oder Praktiken handelt. Grundsätzlich ist es wichtig zu verstehen, dass Scrum Teams, welche DevOps Three Ways übernehmen, eine andere Art der Zusammenarbeit haben als klassische Scrum Teams.

 

Erster Weg: Work always flows in one direction – Downstream

 

Der erste Weg im DevOps Three Ways befasst sich mit der Optimierung des Flows einzelner Product Backlog Items (PBI) von der ersten Kundenanfrage bis zur Auslieferung des Produktes auf die Produktionsumgebung, Ende zu Ende.

  1. 1. Flow Ende zu Ende

Alles, was den reibungslosen Ablauf der PBIs im Wertstrom behindert, kann ein Engpass sein, der beseitigt werden sollte. In Scrum übernimmt der Scrum Master die Rolle, alle Hindernisse für einen reibungslosen Fluss der Wertlieferung an den Kunden zu lösen.

Wenn sich das Scrum-Team für ein Flow-basiertes Modell entscheidet, muss der Scrum-Master dieses kennenlernen und das gesamte Scrum-Team darin coachen, wie Scrum mit Flow-basierten Modellen arbeitet.

Aufgrund von Missverständnissen werden Scrum und DevOps oft als konkurrierende Methoden betrachtet.

  1. Missverständnis: „Mit Scrum kann nur zum Sprintende alle zwei Wochen eine neue Version geliefert werden“

Ein Missverständnis bei Scrum ist, dass nur nach dem Sprint Review auf die Produktionsumgebung geliefert werden darf. Dies ist jedoch nicht der Fall -vielmehr handelt es sich hier um eine Gelegenheit, über das Produktionsergebnis Feedback zu bekommen. Die Sprint Retrospective sollte hierfür genutzt werden, um den Prozess der Produktentwicklung zu verbessern. Bei Continuous Delivery ist auch nichts falsch daran, mehr als einmal im Sprint zu liefern. Hierbei handelt es sich lediglich um den geforderten Mindeststandard, welcher von Scrum gefordert wird. Also sollte dies ein Grund zur Freude sein, denn nicht viele Teams sind in der Lage, ihr Produktionsergebnis mehrmals in einem Sprint – oder sogar mehrmals täglich –in die Produktionsumgebung zu liefern.

  1. Missverständnis: „Das gesamte PBI, welches in dem Sprint Planning dem Sprint zugewiesen wurde, muss vollständig geplant sein und abgeschlossen werden. Der Sprint ist eine Verpflichtung“

Scrum-Teams, die einen DevOps-Ansatz anwenden, werden eine andere Art von Sprint Planning durchführen. Der Fokus liegt mehr auf dem Sprint Ziel als dem Sprint Backlog. Dieses Ziel gibt an, wodurch in diesem kurzen Zeitraum der größte Mehrwert geschaffen werden kann und die Backlog Items beschreiben, wie dieses geschehen soll. Während des Sprint Plannings wird genug Arbeit für die Sprintdauer prognostiziert und später können weitere Aufgaben hinzugefügt werden, solange sie nicht das Ziel des Sprints gefährden.

  1. Missverständnis: „Das Daily Scrum Meeting dient dem Reporting und sollte nur einmal zum Beginn des Tages durchgeführt werden“

Beim Daily Scrum Meeting mit DevOps-Ansatz geht es nicht nur um das Reporting, sondern um eine wechselseitige Synchronisation der individuellen Pläne. Aus diesem Grund führen einige Teams dieses mehr als einmal am Tag durch. Weiterhin liegt der Fokus darauf, die Product Backlog Items in Richtung Sprint Ziel hin zu überprüfen. Somit wird es zu einem Werkzeug zur Optimierung des Wertflusses. In diesem Scrum Event können nach Absprache weitere Items in das Sprint Backlog hinzugefügt werden, wenn das Team Fortschritte bei der bereits vorhandenen Arbeit macht.

 

Zweiter Weg: Create, shorten and amplify feedback loops

Der zweite Weg der „DevOps Three Ways“ widmet sich der Wichtigkeit des Feedbacks vom Kunden. Bei Scrum bilden verschiedene Events, wie das Daily Scrum Meeting, Sprint Review und die Retrospektive, eingebaute Feedbackschleife. Scrum Teams, die DevOps einsetzen, haben jedoch eine andere Feedbackschleife.

2. Flow Ende zu Ende mit Feedback

Das Produkt befindet sich hier bereits auf der Produktionsumgebung. Es wird dort von Nutzern verwendet und bewertet. Durch die einheitliche Betrachtung des gesamten Wertstroms, gibt es für das Team auch nur ein Dashboard für alle Metriken. In diesem befinden sich Messwerte auf Geschäftsebene, Anwendungsebene und Infrastrukturebene. Durch diese Ende zu Ende Sichtweise kann das Scrum-Team Frühzeitig die Leistung des Produktes messen und Feedback vom Endnutzer erhalten und so die derzeitige Strategie überdenken und justieren, um den Mehrwert zu optimieren. Es findet eine hypothesengetriebene Entwicklung statt, in der das Scrum-Team die A/B-Testmethode verwendet. Hierbei handelt es sich um eine Bewertung zweier Varianten eines Systems, bei der die Originalversion gegen eine leicht veränderte Version getestet wird. Hierzu gehört z.B. die Positionierung von Feldern, das Wording oder die Farbkombinationen. Ein geliefertes Feature ist damit erst abgeschlossen, wenn es für den Kunden einen Mehrwert liefert. Somit ist es die Aufgabe des gesamten Scrum-Teams sicherzustellen, dass dieser generiert wird.

 

Dritter Weg: Continued experimentation, in ordert to learn from mistakes and achieve mastery

Der dritte Weg der „DevOps Three Ways“ ermöglicht dem Scrum-Team zu experimentieren und den größtmöglichen Gewinn aus den gewonnenen Erkenntnissen zu ziehen. Allzu oft wird der Sprint wie ein Mini-Wasserfall Model behandelt, im Sprint Planning das Sprint Backlog voll beladen und den Entwicklern kein Raum für Kreativität gelassen. Hier ist es die Aufgabe des Scrum-Masters sicherzustellen, dass die Organisation Scrum nicht nur äußerlich anzuwenden, sondern auch dessen Nutzen inhaltlich versteht.

3. Flow Ende zu Ende mit Feedback und Experimentieren

Ein Ziel von Scrum ist die kontinuierliche Verbesserung und das stetige Lernen. Hierzu dient die Sprint Retrospektive am Ende eines jeden Sprints. Mit diesem Scrum-Event wird das Gelernte festgehalten und in dem nächsten Sprint sofort angewendet. Bei traditionellen Projekten finden Retrospektiven, wenn überhaupt, meist erst am Projektende statt. Dann aber nützen die Erkenntnisse daraus dem abgeschlossenen Projekt nichts mehr…

DevOps bedeutet einen Kulturwandel

Sich in Richtung DevOps zu entwickeln bedeutet, wie bei Scrum, einen Kulturwandel zu vollziehen. Die Abgrenzung zwischen Entwicklung und Betrieb kann es in agilen Unternehmen nicht mehr geben, stattdessen steht eine gegenseitige Wertschätzung im Vordergrund. Es wird als Team zusammengearbeitet, um einen Mehrwert zu liefen – und dies über den gesamten Wertstrom der Anwendung hindurch. Dies bewirkt auch einen Wechsel der Verantwortlichkeit vom Entwicklungsteam, hin zu allen Beteiligten der Organisation. Es entsteht ein „Collective Ownership“. Es bedarf dem Abbau von Silos, dem Ende von Fingerpointing zwischen Entwicklung und Betrieb, der Platzschaffung für Kreativität und am wichtigsten, der Bildung von Vertrauen.

Wie dieser Beitrag zeigt, haben Scrum und DevOps mehr gemeinsam als die meisten annehmen. Beide Vorgehensmodelle basieren auf Werten und Prinzipien statt auf Regeln, wodurch stets die Möglichkeit für Weiterentwicklung gegeben ist. Gerade in einer Zeit, in der ein kürzeres Time to Market, stressfreie und regelmäßige Releases, höhere Qualität und Transparenz gefordert werden, sollte stätig daran gearbeitet werden die Vorhandenen etablierten Methoden zu verbessern und wenn möglich, zu kombinieren.

Die LionGate und (Biz)DevOps

Die LionGate AG unterstützt Sie dabei agil zu arbeiten. Wir bringen Business, Entwicklung und Betrieb gemeinsam an einen Tisch und schaffen in kürzester Zeit gemeinsam ein lauffähiges Produkt (MVP). In der Vergangenheit haben wir dieses bereits für große Konzerne getan, beispielsweise in der Telekommunikationsbranche. Wir betreiben erfolgreich Managed Cloud Solutions im DevoOps-Modell beim Change Projekt zur digitalen Transformation. Entscheiden Sie sich für drastisch reduzierte Implementierungskosten, für dynamische Anpassungen an die Marktgegebenheiten und für realisierbare Mehrwerte in kürzester Zeit. LionGate hat die Erfahrung und Kompetenz, Sie und Ihre integrierten Teams durch diesen agilen Prozess zu führen.