Für manchen Betrachter mögen Agile und DevOps wie grundsätzlich unterschiedliche Konzepte erscheinen. In diesem Zusammenhang setzen viele Leute jedoch Agile mit Scrum und DevOps mit Continuous Delivery (CD) gleich. Diese Simplifizierung erschafft unnötige Reibung zwischen Agile und DevOps, denn tatsächlich kommen sie bestens miteinander aus. In diesem Artikel wollen wir uns mit den praktischen Verbindungen zwischen diesen Konzepten beschäftigen und einen Blick unter die Oberfläche von Scrum und CD werfen.
Agile ist mehr als Scrum
In manchen Teams macht Scrum den Unterschied zwischen einem ständigen frustrierenden Kampf und produktiver, lohnenswerter Teamarbeit aus. In anderen ersetzt Scrum Politik und Overcommitment durch Objektivität und Fokussierung. Wieder andere fassen Scrum als Dogma auf.
Wenn die Zwänge der Geschäfts- oder Arbeitswelt etwas Neues erfordern, wird ein agiles Team die zugrundeliegenden Scrum-Prinzipien anwenden, seine Praktiken prüfen und sich auf eine Art und Weise anpassen, die es effektiver macht. Das ist besonders wichtig, wenn Scrum außerhalb des Kontextes der Software-Entwicklung zur Anwendung kommt.
Planung für ungeplante Arbeit
In der DevOps-Community erkennen viele Leute an, dass Scrum nützlich für das Tracken geplanter Arbeit ist: die Auslieferung einer großen Systemänderung, der Wechsel zwischen Rechenzentren, die Durchführung von System-Upgrades usw. Oft sind technische Arbeiten aber ungeplant: Performance-Spitzen, Systemausfälle, Sicherheitsbeeinträchtigungen etc. Solche Ereignisse verlangen sofortige Reaktionen. Es ist keine Zeit, Dinge in einem Backlog zu priorisieren oder auf die nächste Sprint-Planung zu warten.
Aus diesem Grund blicken viele Teams, die sich dem DevOps-Denken verschrieben haben, über Scrum hinaus auf Kanban. Dies hilft ihnen, beide Arten von Arbeit zu tracken und die Wechselwirkungen zwischen ihnen zu verstehen. Oder sie adaptieren einen hybriden Ansatz wie Scrumban oder Kanplan (Kanban mit einem Backlog).
Mitverantwortlich für die breite Adaption von Scrum ist wohl die Tatsache, dass dieses Framework nicht in die technische Praxis eingreift. Die leichtgewichtigen Management-Praktiken von Scrum machen für ein Team oft den Unterschied aus. Wo es zuvor miteinander konkurrierende Prioritäten für diverse Stakeholder gab, hat das Team nun einen einzelnes Set von Prioritäten im Backlog. Wo es vorher zu viel Work in Progress gab, ist die laufende Arbeit jetzt auf das beschränkt, was sich im Verlauf der Zeit als wirklich machbar erwiesen hat.
In Kombination können diese Aspekte ein Team auf eine neue Produktivitätsebene hieven. Doch eben jenes Team kann sich durch das Fehlen von technischen Praktiken wie Code-Reviews, automatisierten Akzeptanztests und Continuous Integration eingeschränkt sehen.
Andere agile Prozesse wie Extreme Programming haben eine ausgeprägte Meinung dazu, wie technische Praktiken die Fähigkeit des Teams unterstützen, eine kontinuierliches Tempo aufrechtzuerhalten und dem Management und den Stakeholdern Transparenz und Sichtbarkeit zu bieten. Manche Scrum-Teams nehmen die Zuflucht, technische Aufgaben ins Backlog aufzunehmen.
Das passt zwar gut ins Scrum-Rahmenwerk, aber hier kann schnell das praktische Problem auftreten, das mit der Voreingenommenheit des Product Owners für Features einhergeht. Der PO mag technisch durchaus versiert sein, aber am Ende hat er vielleicht doch nicht die Fähigkeiten, Kosten und Nutzen technischer Aufgaben zu evaluieren. Es wird für ihn noch schwieriger, wenn die technischen Aufgaben in den Betrieb hineinreichen und Stabilität, Performance und Sicherheit tangieren.
Product Owner und Service Owner
Manche Teams und Organisationen sind daher dazu übergegangen, zwei unterschiedliche Rollen für die Produkte, die sie betreiben, zu definieren. Product Owner verstehen sehr gut, welche Features die User brauchen, aber es ist für sie problematisch, diese Features gegenüber nicht-funktionalen Aspekten wie Performance, Stabilität und Sicherheit zu bewerten.
Also haben diese Teams für SaaS-Produkte einen Service Owner etabliert, der dafür verantwortlich ist, diese nicht-funktionalen Arbeiten zu priorisieren. Von Zeit zu Zeit wird es zwischen den beiden Ownern zu einem Kuhhandel kommen, aber zumeist werden diese Arbeiten von unabhängigen Teams erledigt werden können.
Das muss nicht der einzige Weg sein, um Feedback aus dem technischen Bereich zu verstärken, aber es hilft, die gängige Feature-Fokussierung zu überwinden. Der Ansatz, mit zwei Ownern zu arbeiten, ist kein Universalrezept. Wichtig ist vor allem, auch die nicht-funktionalen Charakteristika als Features zu verstehen und in der Lage zu sein, sie zu planen und zu priorisieren wie eine funktionale User-Story.
Wie alle agilen Methoden hat Scrum einen eingebauten Mechanismus für die Verbesserung von Prozessen – die Retrospektive. Daher ist es zunächst mal vernünftig zu glauben, dass Scrum-Teams das DevOps-Konzept als Inspirationsquelle betrachten und Retrospektiven als Gelegenheit nutzen werden, sich im Hinblick auf DevOps auszurichten.
Aber die Praxis zeigt, dass die meisten Teams eine Injektion mit Ideen von außen brauchen. DevOps ist kein organisches Resultat aus Scrum. Ob das Team mit einem Agile- oder DevOps-Coach arbeitet, ist egal, solange die Person Erfahrungen mit der Automatisierung - vom Bauen übers Testen bis zum Deployen - von Software einbringen kann.
Im zweiten Teil dieses Artikels geht es um die Frage, inwiefern DevOps mehr als Continuous Delivery ist.
Weiterführende Infos
Atlassian-Studie: Trends und Benchmarks in der Software-Entwicklung 2016
Das Agile-Portal in unserer Infothek
Don’t feed the Undone-Monster! – Vortrag von der Tools4AgileTeams-Konferenz 2016
Continuous Documentation (Jörg Müller-Kindt auf der Tools4AgileTeams2016)
