Lange Zeit waren die Entwicklung (Development) und der Betrieb (Operations) klar getrennte Ressorts. Entwickler kümmerten sich um ihre Software: Sie trieben in ihrem Produkt Innovationen voran und implementierten neue Funktionen, oft agil organisiert und mit dem Ziel einer kurzen Time-to-Market. Die Administratoren aus dem Betrieb, verantwortlich für die Infrastruktur, setzten ihre Prioritäten verständlicherweise eher auf Stabilität, Verfügbarkeit und Performanz – weil sie daran gemessen wurden. Auch eine möglichst hohe Standardisierung lag in ihrem Fokus.
DevOps reißt die klassischen Silos und die sogenannte „Wall of Confusion“ (s. Abb. 1) durch die Organisation in cross-funktionalen Teams nieder. Mit diesem Ansatz lösen Unternehmen also genauer gesagt die funktionale Trennung beim Verantwortungsübergang zwischen Entwicklung (Devs) und Betrieb (Ops) auf.
Abb. 1: Zielkonflikt zwischen Dev und Ops
Zu diesem organisatorischen Umdenken passt die agile Softwareentwicklung hervorragend. Veränderung ist nämlich der Normalzustand von agil arbeitenden Teams. Damit die Qualität nicht leidet und die Disruption im Arbeitsablauf nicht zu stark ist, teilen agile Teams große Veränderungen in kleine, handhabbare Häppchen. Der stete Wandel bezieht sich allerdings auch auf Prozesse und Praktiken selbst: Regelmäßig steht die Effizienz auf dem Prüfstand. Experimente sind ein beliebtes agiles Instrument für deren Evaluation nach dem Prinzip „Inspect and Adapt“. Best Practices für Agile und DevOps sind Feedbackschleifen und Retros, die feste Bestandteile von agilen Modellen wie Scrum und Kanban sind.
Der Product Owner im Fokus
Der Arbeitsbereich des Product Owners ist der sogenannte Product Backlog. In Form von Aufgaben und User-Storys sind dort fachliche und funktionale sowie nicht-funktionale Anforderungen (wie zum Beispiel die Qualitätsanforderungen) dokumentiert. Der Product Owner hat insbesondere die Verantwortung dafür, die Aufgaben dort zu priorisieren. Spielt das Team nach DevOps-Regeln, erweitert sich der Katalog nicht-funktionaler Anforderungen um technische Aufgaben zur Verbesserung der Wartbarkeit und Betreibbarkeit der Software. DevOps vergrößert so gesehen den Anteil technischer Aufgaben im Product Backlog.
Da Product Owner ein möglichst herausragendes Produkt vertreten möchten, kommt es oft zu einer Priorisierung neuer Features. Es besteht dann die Gefahr, dass qualitative und operative Anforderungen nicht ausreichend im Fokus stehen. Viele Product Owner mit einem weniger starken technischen Background haben darüber hinaus manchmal Probleme damit, den Kosten-Nutzen-Faktor technischer Themen wie Verfügbarkeit, Performanz oder Sicherheit richtig einzuschätzen. Das Team muss für eine erfolgreiche Umsetzung von DevOps daher den eventuell vorhandenen Mangel an Know-how ausgleichen und den Product Owner entsprechend beraten und unterstützen.
In vielen Projekten hat es sich deshalb als sinnvoll erwiesen, rund 15 Prozent des Budgets für kleinere technische Verbesserungen einzuplanen. Sind diese in weniger als drei Arbeitstagen umzusetzen, müssen die Teammitglieder diese „Quick Wins“ im Normalfall auch nicht mit dem Product Owner absprechen (s. Abb. 2). Das sorgt für Entlastung bei ihm, und das Team kann die Qualität, Betreibbarkeit und Wartbarkeit der Software unbürokratisch verbessern.
Abb. 2: DevOps-Team
Vertikale Verantwortungsverteilung durch Story Parents
Das Prinzip „Story Parent“ beschreibt den Ansatz, jeder User-Story eine Bezugsperson zuzuweisen – von deren „Geburt“ im Product Backlog Refinement bis zur „Volljährigkeit“, also der Installation des Features in Produktion. Der jeweilige „Parent“ verpflichtet sich in diesem Modell, die inhaltliche Verantwortung für das Feature zu übernehmen und Experte für das Thema zu werden. Dies bedeutet nicht, dass der Story Parent die tatsächliche Implementierung der einzelnen Entwicklungsaufgaben der User-Story übernehmen muss. Dies können auch Kollegen aus dem Entwicklungsteam übernehmen. Der Story Parent steht aber als versierter Ansprechpartner für die jeweilige User-Story zur Verfügung und entlastet so den Product Owner.
Zu den weiteren Aufgaben des Story Parents gehören Testing und Quality Assurance (QA). Er lässt die User-Story im Rahmen der Absicherung auf der Ende-zu-Ende-Umgebung testen und überprüft die korrekte Funktionalität des implementierten Features nach dem Live-Gang. Story Parents stehen ganz im Zeichen von DevOps und einer vertikalen Denkweise: Verantwortung lastet nicht nur auf den Schultern des Product Owners, sondern sie wird auch im Team verteilt, von der Idee über die Planung und Umsetzung bis hin zum Deployment in Produktion.
Gerade große Scrum-Teams, die aus sieben oder mehr Personen bestehen, profitieren von dem Konzept der Story Parents. Doch auch für große, komplexe Systemlandschaften, die von agil arbeitenden Teams betreut werden, kann das Modell seine Vorteile ausspielen. Story Parents sind ein guter Tradeoff zwischen Vermeidung von Wissensinseln und Team-Effektivität.
Verbesserte Problembehebung mit Feedbackschleifen
Kommunikation ist auch bei DevOps das A und O, weshalb Feedbackschleifen aus dem produktiven Betrieb der Software essenzieller Bestandteil jeglicher Bemühungen sind. Nur so können Entwickler einer User-Story wirklich erfassen, welche Konsequenzen ihre Entscheidungen am Ende haben: Der Betrieb einer Software stellt nun einmal ganz andere Herausforderungen als deren Entwicklung, was die Fehlerbehebung ohne betriebsbezogenes Wissen erschwert. Und es ist hinlänglich bekannt: Je später ein Fehler oder ein Problem erkannt wird, desto aufwendiger und damit teurer wird die Korrektur.
Bringt der Entwickler sein tiefgreifendes Verständnis für die inneren Funktionsweisen eines Systems in die Fehlersuche und -behebung ein, ist dies auch zum Nutzen der operativen Seite. Zielgerichteteres Logging mit sehr informativen Log-Nachrichten, ein verbessertes Monitoring, aussagekräftigere Health-Checks und sinnvolle Smoke-Tests sind nicht selten die Folge dieser Zusammenarbeit. Von dem persönlichen Wissensgewinn des Entwicklers in Bezug auf betreibbare und wartbare Software einmal abgesehen. Erfolgreiches DevOps ermöglicht es, die Wartbarkeit und die Betreibbarkeit von Features bereits bei der Entwicklung der User-Story zu berücksichtigen.
Kanban für effektiveres Krisenmanagement
Die Operations-Abteilungen in Unternehmen übernehmen in der Regel planbare Arbeiten wie große Releases oder eine Anpassung der IT-Infrastruktur. Doch auch inhärent ungeplante Tätigkeiten wie Systemausfälle oder die Schließung von Sicherheitslücken sind ihr Metier. Es versteht sich von selbst, dass diese Aufgaben sofortiges Handeln erfordern und das Team sie nicht erst im nächsten Sprint beheben kann. Für solche Fälle ist nicht Scrum der richtige Weg, sondern Kanban.
Diese Methode gibt den Projektverantwortlichen eine transparente Übersicht über den Gesamtstatus eines Projekts und zeigt personelle Engpässe auf. Insbesondere in kritischen Situationen können die Product Owner – oder Story Parents – so schnellere und bessere Entscheidungen treffen. Eine Mischung aus Scrum und Kanban kommt ebenfalls häufig zum Einsatz. Beim sogenannten Scrumban ergänzen Teams Kanban mit einem Backlog, der planbare Aufgaben beinhaltet.
Fazit
Agilität und DevOps stehen nicht diametral gegenüber, sondern sind heutzutage in der Regel eng miteinander verwoben und üben gegenseitig Einfluss aufeinander aus. Operative Anforderungen sind dank DevOps nicht mehr nur in den Köpfen von Operations-Teams verankert, auch Product Owner setzen sich damit nun auseinander. Feedbackschleifen, die Projektbeteiligte nicht nur innerhalb ihrer User-Story durchführen, tragen zu mehr Resilienz und einem reibungsloseren Geschäftsablauf bei.
Und auch auf klassische Betriebsaufgaben lassen sich agile Methoden anwenden. So haben DevOps und agile Softwareentwicklung sich gegenseitig beflügelt. Die wichtigste Entwicklung ist aber die verbesserte Kommunikation. Sie ist der Schlüssel für viele Unternehmen, die Digitalisierung zu einem Erfolg auf ganzer Linie zu führen.
