Agile Operations im IT-Betrieb
Agile Produktentwicklung, agiler IT-Betrieb?!
Agile- und DevOps-Methoden konzentrieren sich oft auf Softwareentwicklung. Dabei müssen bereits bestehende Prozesse parallel reibungsfrei betrieben werden. Häufig sind hier ITIL-Basiertes und Lean-Methoden zu finden. Ein Widerspruch? Nicht, wenn man Agile und Operations richtig zusammenführt.
Wir leben in einer hochtechnologischen Welt: Etwa alle 15 Jahre ändert sich die Infrastruktur. Aktuell ist ein Übergang von Peak-load-basierten Infrastrukturen hin zu consumption-basierten zu sehen. Aber auch dahingehend, dass Unternehmen ihre Systeme immer mehr als Gut ansehen, welchessie – ähnlich wie Strom oder andere Ressourcen – von einem Provider beziehen. Mit der steigenden Flexibilität, Geschwindigkeit und allgemein dem Wandel der Infrastruktur gehen aber auch verschiedenste Herausforderungen einher.
Arbeitspakete und Sprints verändern die Entwicklung
Um mit den Anforderungen an die Bereitstellung von Lösungen in Echtzeit fertig zu werden, hat sich der Einsatz von Agile, beziehungsweise agilen Methoden, in der IT etabliert. Use Cases und Aufgaben werden in kleine Sprints oder Arbeitspakete verpackt, was es den Entwicklungsteams ermöglicht, schnell auf veränderte Anforderungen zu reagieren und gleichzeitig mehr Arbeit parallel zu erledigen. Durch die Fokussierung auf einen bestimmten Arbeitsumfang (Sprintziel) mit geringerem Umfang bleibt das Team im Flow und Unterbrechungen führen seltener dazu, dass Task-Switching den Fortschritt oder Abschluss eines Produkt-Increments behindert. Zudem wurde im Zuge von Dev-Ops versucht, Entwicklung und Betrieb enger zusammenzuführen. Dadurch erhalten Developer schneller Rückmeldung, ob die Änderung oder die Ergänzung aus einem Sprint im Betrieb das tut, was sie soll. Damit wurde die bis dahin vorherrschende Plan-Build-Run-Struktur durch ein agiles DevOps-Modell abgelöst.
Agile im IT-Betrieb nur bedingt einsetzbar
Doch während die Einführung von agilen Methoden bei Entwicklerteams weit vorangeschritten ist, hadert vor allem der IT-Betrieb damit. Grund dafür ist die Gratwanderung, die hier bewältigt werden muss: Zum einen soll das Team schneller und agiler werden, zum anderen muss an einigen Vorgehen und Verhaltensweisen festgehalten werden – etwa bei der Einhaltung bestimmter Sicherheitsrichtlinien. Das gilt insbesondere für sogenannte „Brownfield-Unternehmen“, also Firmen, die beispielsweise nicht nativ in der Cloud starten, sondern Lösungen bereits auf bestehender Infrastruktur außerhalb der Cloud betreiben. Hier kollidieren agile Methoden wie Scrum gegebenenfalls mit der bestehenden Arbeitsweise der verantwortlichen IT-Abteilung. Scrum fokussiert sich lediglich auf die Produktentwicklung und blendet den Betrieb aus. Sprint-Ziele in Scrum werden stets zu Beginn fixiert und sollen der Logik nach nicht im laufenden Sprint verändert werden. Das ist kaum mit der täglichen Arbeit der Operations-Teams in Einklang zu bringen, denn hier wird größtenteils reaktiv gearbeitet – etwa im Support.
Etwas anders verhält es sich mit Kanban oder auch Scrumban. Bei diesen Methoden lassen sich die tägliche Support-Arbeit und das Arbeiten an Projekten besser in Einklang bringen und durch ein vernünftiges und transparentes Ticketing-System werden Kapazitätskonflikte besser sichtbar.
Agile Operations als Lösung
Der Agile-Operations-Ansatz bringt den Betrieb der Lösung von Beginn an in die Produktplanung und -erstellung mit ein. Daher benötigt man neben der passenden Methode für Agile Operations als zweiten Schritt eine neu gedachte Teamstruktur – speziell, weil Operations mitgedacht werden soll. DevOps & Agile haben hier bereits Vorarbeit geleistet: 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, 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 sicher. Um nun Operations zu integrieren, empfiehlt sich die Bestimmung eines Lead Operations (LO) sowie eines Architects (AR). Ersterer verantwortet den Betrieb des Produktes innerhalb der Squads und Letzterer stellt die technische Architektur des Produkts übergreifend sicher, sprich sowohl die Erstellung als auch den nachhaltigen Betrieb. Zudem stimmen sich beide vor jedem Sprint mit dem PO ab und definieren gemeinsam die Gewichtung zwischen Operations-Aufgaben und Entwicklung sowie dem Backlog (siehe auch Abbildung).
Dieses Vorgehen spielt wiederum der Kanban-Methode in die Karten, wobei – soweit planbar – eine Auswahl an Arbeitspaketen getroffen wird und diese mit der Sprint-Planung harmonisiert werden kann. Durch Agile Operations teilt sich das Team je Sprint in Development und Betrieb auf – je nach Bedarf des Teams und seiner Stakeholder. Am Ende ist es die Entscheidung des Product Owners, wie viel Kapazitäten er in dem einen oder anderen benötigt. Der Vorteil ist die höhere Flexibilität pro Produkt sowie das geschaffene Verständnis in den Teams – sowohl für die Entwicklung als auch für den Betrieb des Produkts.
Auch die Produktqualität profitiert
Nun könnte man meinen, dass der Ansatz der Agile Operations hauptsächlich den IT-Betrieb beeinflusst. Doch wenn man genau hinsieht, kann dieses Vorgehen die Produktqualität verbessern. Indem gemäß dem Credo „Du baust es, du betreibst es auch“ entwickelt wird, fließen die Qualitätsansprüche der IT-Operations früher oder später automatisch in die Produktentwicklung ein – schließlich haben EntwicklerInnen nur selten Lust, freiwillig mitten in der Nacht aufzustehen, um die Störung eines Produktes zu beheben.
Florian Weigmann, Chief Product Officer bei Plusserver
Lesen Sie mehr zum Thema
