Produktentwicklung und IT-Operations zusammenbringen So wird der agile IT-Betrieb zur Realität

Viele Unternehmen müssen etablierte IT-Prozesse auch in Zeiten von Agile- und DevOps-Methoden reibungsfrei betreiben – mit Standards aus dem IT-Servicemanagement wie ITIL. Ein Widerspruch? Nein, wer Agile und Operations richtig zusammenführt, erhält den agilen IT-Betrieb.

Informationstechnologie ist einer der dynamischsten Bereiche unserer Welt. Alle 15 Jahre verändert sich die Infrastruktur. Aktuell wandeln sich die IT-Technologien von „Peak Load“ zu „Consumption“, also weg von der Ausrichtung auf Spitzenlasten und hin zu einer verbrauchsabhängig skalierbaren IT.

Damit einher geht eine Entwicklung, bei der die nutzenden Unternehmen ihre IT-Infrastruktur eher als Verbrauchsgut ansehen, das sie wie Strom oder Wasser von einem Versorger beziehen. Es geht in den Unternehmen immer weniger darum, Server zu mieten und Software zu lizenzieren, um darauf basierend Innovation voranzutreiben. Stattdessen gilt IT-Infrastruktur zunehmend als Service, den Firmen aus der Cloud beziehen und bei Bedarf konsumieren.

Kurze Sprints und schnelle Fortschritte

Für diese neue Art des Betriebs haben sich die Anforderungen an IT-Teams in den vergangenen Jahren verändert. Vor allem die Bereitstellung von Anwendungen muss schneller geschehen und die Release-Zyklen werden immer kürzer. Viele Cloud-Anwendungen haben teilweise mehrmals täglich ein neues Inkrement.

Diese Geschwindigkeit lässt sich nicht mit herkömmlichen Entwicklungsmethoden erreichen, stattdessen ist agile Entwicklung der Standard. Dabei werden Use Cases und Aufgaben in kleine Arbeitspakete (Sprints) verpackt. Das ermöglicht den Entwicklerteams, schnell auf veränderte Anforderungen zu reagieren und gleichzeitig mehr Arbeit parallel zu erledigen.

Durch die Fokussierung auf einen bestimmten, kleindimensionierten Arbeitsumfang (Sprintziel) bleibt das Team im Flow. Unterbrechungen führen seltener zu Task-Switching und behindern den Fortschritt oder Abschluss eines Produkt-Increments. Außerdem wird mit dem DevOps versucht, Entwicklung und Betrieb enger zusammenzuführen. Dadurch erhalten die Entwickler und Entwicklerinnen schneller eine Rückmeldung, ob die Änderung oder Ergänzung aus einem Sprint im produktiven Betrieb das macht, was sie soll. Damit wurde die bis dahin vorherrschende Struktur „Plan, Build, Run“ durch ein agiles DevOps-Modell ersetzt.

Agile Methoden kollidieren mit dem Alltag im IT-Betrieb

Agile Methoden sind inzwischen für Entwicklerteams Alltag. Doch der IT-Betrieb hadert mit ihnen. Grund dafür ist eine gewisse Gratwanderung, die hier bewältigt werden muss. Einerseits soll das Team schneller und agiler werden, andererseits muss es an bestimmten Arbeitsschritten und Verhaltensweisen festhalten. Dies betrifft beispielsweise die Erfüllung bestimmter Sicherheitsrichtlinien, auditierter Prozesse und SLA-Anforderungen.

Vor allem „Brownfield-Unternehmen“ stoßen hier auf Schwierigkeiten. Diese Firmen arbeiten nicht nativ in der Cloud, sondern nutzen bereits vorhandene Lösungen auf einer bestehenden Infrastruktur außerhalb der Cloud. Hier kollidieren agile Methoden wie Scrum mit der herkömmlichen Arbeitsweise von IT-Organisationen.

Scrum ist stark auf die Produktentwicklung ausgerichtet und blendet den Betrieb aus. Die Sprintziele werden stets zu Beginn fixiert und sollen nicht im laufenden Sprint verändert werden. Das ist allerdings nur schwer mit den täglichen Aufgaben der Betriebsteams in Einklang zu bringen. Sie arbeiten größtenteils reaktiv, beispielsweise im Support. Hierfür sind die altbekannten ITIL-Prozesse zuständig, bei denen Arbeitspakete bestimmte „Stationen“ wie Incident-, Change- oder Release-Management durchlaufen. Diese stark arbeitsteiligen Strukturen lassen sich nur schwer mit agilen Methoden in Einklang bringen.

Etwas anders sieht es mit Scrumban aus, der Verknüpfung von Kanban und Scrum. Das Konzept übernimmt einige Elemente von Kanban in Scrum, etwa ein Backlog mit klar zugewiesenen Aufgaben und die visuelle Darstellung in Karten. Damit lassen sich der tägliche Support und die Arbeit an Projekten besser in Einklang bringen. Durch ein vernünftiges und transparentes Ticketing-System werden Kapazitätskonflikte besser sichtbar. Auf dieser Basis lässt sich ein Gesamtkonzept entwickeln, das den Betrieb eines Entwicklungsprojektes direkt mitdenkt.

Agile Operations: Eine Lösung für die Praxis

Um nun die Planung und Entwicklung eines Produktes mit seinem Betrieb praxistauglich zu verknüpfen, kommt der Ansatz der Agile Operations in Spiel. Dafür benötigt man neben der passenden Methode außerdem eine andere Teamstruktur. DevOps und Agile enthalten bereits die wichtigsten Konzepte: Die Product Owner (PO) sind ganzheitlich für das Produkt verantwortlich. Sie stellen die Produktvision sowie die Roadmap auf.

Die Teams arbeiten in Squads zusammen an einem Sprint und werden dabei von anderen Kolleginnen und Kollegen, etwa aus Chaptern (ein fachlicher Querschnitt über die Squads hinweg) oder Gilden (freiwillige übergreifende Interessengruppen, wie zum Beispiel Testautomatisierung) unterstützt. Zudem sorgt ein Agile Coach für die Einhaltung der Regeln und stellt die Autonomie des Teams sicher.

Die Integration von Operations geschieht über zwei neue Rollen: Lead Operations (LO) und Architect (AR). Die erste Rolle verantwortet den Betrieb des Produktes innerhalb des Squads und die zweite Rolle verantwortet die technische Architektur des Produkts in einer übergreifenden Perspektive, die Entwicklung und Betrieb berücksichtigt. Beide stimmen sich vor jedem Sprint mit dem PO ab und definieren gemeinsam die Gewichtung zwischen Operations und Entwicklung sowie dem Backlog.

Dieses Vorgehen stimmt weitgehend mit Kanban-Methoden überein. Damit wird – soweit planbar – eine Auswahl an Arbeitspaketen getroffen, die anschließend mit der Sprintplanung harmonisiert werden. Durch Agile Operations teilt sich das Team pro Sprint in Entwicklung und Betrieb auf – je nach Bedarf des Teams und seiner Stakeholder. Am Ende ist es die Entscheidung des Product Owners, wie er die Kapazitäten auf beides verteilt. Die Folge ist eine höhere Flexibilität sowie das verbesserte Verständnis in den Teams – sowohl für die Entwicklung als auch für den Betrieb des Produkts.

Die Erfolgsformel: Agile plus Operations gleich bessere Produkte

Auf den ersten Blick sieht es so aus, als ob der Ansatz hauptsächlich den IT-Betrieb beeinflusst. Doch ein genauer Blick zeigt, dass systematisches, aktives Vorgehen die Produktqualität insgesamt verbessert. Das DevOps-Credo „Du baust es, Du betreibst es“ sorgt dafür, dass die Verantwortung für Entwicklung und Betrieb nicht länger zerteilt ist.

Die Qualitätsansprüche des IT-Betriebs bezüglich Ausfallsicherheit fließen früher oder später automatisch in die Produktentwicklung ein. Der Grund ist einfach: Auch Developer haben keine Lust, freiwillig mitten in der Nacht aufzustehen, um eine Störung zu beheben.

* Florian Weigmann ist seit Mai 2022 Chief Portfolio Officer (CPFO) bei der PlusServer GmbH. Sein besonderes Augenmerk liegt dabei auf den Bereichen Datenarchitektur und Datensicherheit innerhalb skalierbarer Cloud-Infrastrukturen. Zudem eruiert er gemeinsam mit seinem Team die Mehrwerte neuer virtueller Produkte und Services für die plusserver Kunden und entwickelt das plusserver Angebot entsprechend weiter. Vor seiner Ernennung zum CPFO war er Chief Product Officer bei plusserver.

(ID:48462218)