Scrum ist inzwischen 23 Jahre alt und in einer Zeit entstanden, die – in unserer Branche – fast vorsintflutlich anmutet. Kein Wunder also, dass inzwischen die ersten Nachfolger am Start stehen. Devops gilt dabei als aussichtsreicher Kandidat. Aber wie unterscheiden sich beide Modelle eigentlich und könnten sie sich vielleicht auch gut ergänzen? Tatsache ist, dass aufgrund von Missverständnissen Scrum und Devops oft als konkurrierende Methoden betrachtet werden:

Bei Devops geht es um das häufige Liefern von neuen Versionen mit kleinen Verbesserungen. In entsprechenden Fallstudien werden oftmals mehrere Releases pro Tag erwähnt. Scrum kennt zwar keine minimale Zeit für den Planungs-Zyklus (Sprint), jedoch macht es in der Praxis nur selten Sinn, diese kürzer als eine Woche zu wählen. Eignet sich damit Scrum nicht für Continuous Delivery, also der kontinuierlichen Auslieferung neuer Funktionen? Wenn man den Scrum-Guide genau liest, stellt man fest, dass Scrum die Bereitstellung eines sogenannten Done Increments, also einer auslieferbaren Produktversion spätestens am Ende jedes Sprints fordert. Es gibt jedoch keine Regel, die verbietet, während des Sprints auch häufiger ein solches Done Increment bereitzustellen und auch auszuliefern, also gerne auch mehrfach am Tag.

Ein wichtiger Aspekt von Devops ist, daran zu arbeiten, den oben beschriebenen Devops-Zyklus so schnell und so häufig wie möglich durchlaufen zu können. Das ist nur möglich, wenn ein großer Teil der Abläufe wie zum Beispiel Build, Test, Release und Deployment automatisiert sind. Devops aber auf die Einführung entsprechender Tools zur Automatisierung zu begrenzen, würde bedeuten, den größten Teil des Verbesserungspotenzials außen vor zu lassen. Devops beginnt zunächst mit einem Mindset, mit der systemischen Betrachtung des gesamten Erstellungs- und Betriebsprozesses für Softwareprodukte mit dem Ziel, für die Anwender ein möglichst positives Benutzererlebnis zu schaffen. Dafür müssen unterschiedlichste Perspektiven berücksichtigt werden und verschiedene Konzepte müssen ineinandergreifen. Aus dieser Gesamtbetrachtung entsteht dann an verschiedenen Stellen ein Automatisierungsbedarf, der wiederum Tools notwendig macht. Devops also mit Tools zu beginnen, wäre wie das Pferd vom Schwanz her aufzuzäumen.

Du möchtest Scrum besser kennenlernen und verstehen? Unsere Videokurse zeigen dir, wie es geht!

Scrum stellt ein Framework dar, das Rahmenbedingungen für die Planung und Umsetzung von Software-Produkten bis zur Bereitstellung eines auslieferfähigen Inkrements definiert. Mit Devops soll die Zusammenarbeit zwischen verschiedenen Verantwortungsbereichen optimiert und mit möglichst kurzen Feedbackzyklen eine bedarfsgerechte Fokussierung der Entwicklungsinvestitionen erreicht werden. Beide Konzepte entsprechen somit der Philosophie agiler Entwicklung und können sich gut ergänzen. Wie könnte denn nun ein solches kombiniertes Vorgehen aussehen? Das soll anhand eines fiktiven Teams kurz skizziert werden, wobei es sich dabei nicht um eine Blaupause handelt, sondern lediglich als Inspiration dienen soll. Jedes Team muss hier die passende Vorgehensweise für sich selbst finden.

Ein Beispiel: Unser fiktives Team hat ein Product-Backlog, in dem alle möglichen Verbesserungen am Produkt gesammelt werden. Der Product-Owner versucht dabei, die Themen zu identifizieren, die ein optimales Kosten-Nutzen-Verhältnis haben. Das Development-Team hat ein tiefgreifendes Verständnis darüber, wie die Anwender das Produkt nutzen, da es nicht nur für die Implementierung, sondern auch für den Betrieb und den Anwender-Support verantwortlich ist. Product-Owner und Development-Team legen für jeden Sprint ein sogenanntes Sprint-Goal fest, ein Fortschritt, der am Ende des Sprints erreicht werden soll. Gemeinsam suchen sie nach der schnellsten und einfachsten Lösung zu diesem Ziel, um erste Erfahrungen zu sammeln und die so entstandene rudimentäre Lösung dann mit diesen neuen Erkenntnissen sukzessive auszubauen.

Das Development-Team implementiert nun die einzelnen Funktionen, die zur Erreichung des Sprint-Goals erforderlich sind. Dabei fokussiert sich das Team mit seinen interdisziplinären Kompetenzen auf die Fertigstellung einer Funktion statt gleichzeitig an vielen verschiedenen Stellen zu arbeiten. Ist die Funktion fertiggestellt und getestet, so wird sie umgehend auf das Produktivsystem ausgeliefert. Dabei nutzt das Team Techniken wie Feature-Flags und Blue-Green-Deployment. Damit kann die neue Funktion zunächst einem kleinen Anwenderkreis bereitgestellt werden und erst wenn dort keine Probleme auftreten, wird der Kreis der Nutzer erweitert. Bei Problemen wird die Funktion umgehend abgeschaltet und die Anwender können wieder ein stabiles System nutzen. Der Product-Owner ist im Entstehungsprozess kontinuierlich einbezogen. Treten im Betrieb kritische Probleme auf, so kümmert sich das Development-Team umgehend darum. Mit seinen interdisziplinären Kompetenzen aus Infrastruktur und Software kann eine Analyse und Behebung des Problems zügig umgesetzt werden. Noch wichtiger ist allerdings die anschließende Ursachenanalyse, um ähnliche Probleme zukünftig zu vermeiden und den Gesamtprozess robuster zu machen. Diese Erfahrungen wiederum werden auch die Art und Weise der Implementierung beeinflussen.

Am Ende des Sprints findet ein Sprint-Review statt. Dabei fasst das Scrum-Team nochmals zusammen, welche Funktionen in diesem Sprint ausgeliefert werden konnten. Das Ziel dabei ist es, Feedback von den Stakeholdern zu bekommen. Mit diesen Erkenntnissen kann entschieden werden, mit welchen Erweiterungen im nächsten Sprint der Mehrwert des Produktes optimal erweitert werden kann.

Den hier beschriebenen Ablauf kann man sich gut in einem sehr kleinen Unternehmen, etwa in einem Startup, vorstellen. Dort gibt es meist keine klare Abgrenzung der Zuständigkeiten. Alle Beteiligten arbeiten Hand in Hand, um das gemeinsame Produkt und damit die gemeinsame Vision erfolgreich zu gestalten. Jeder bringt hierfür seine Erfahrungen und Kompetenzen ein und legt dort Hand an, wo es gerade notwendig ist. Mit Scrum und Devops können aber auch größere Unternehmen beginnen, eine solche Kultur zu entwickeln. Hierzu ist es meist notwendig, dass nicht nur die Unternehmensstruktur neu definiert wird, sondern auch die Produktmodularisierung muss dazu passen. Bei Unternehmen, die mit einer Devops-Kultur komplexere Produkte mit mehreren Teams entwickeln, beobachtet man häufig eine Architektur, die eine End-to-End-Verantwortung der Teams begünstigt. So wird das Produkt in einzelne Teilbereiche aufgegliedert, für die ein Team dann komplett verantwortlich ist – von der UI bis zur Persistierung der Daten, von der Definition von Mehrwerten durch das Teilmodul bis zum reibungslosen Betrieb.

Devops bedeutet damit viel mehr als nur die Lieferung von neuen Software-Inkrementen in kurzen Zyklen. Es bedeutet die Ausdehnung von agilen Prinzipien auf den Unternehmenskontext und lässt sich somit hervorragend mit Scrum kombinieren.