Erst wenn Entwicklung und Betrieb gemeinsam mit Fachabteilungen und Management wertschöpfend an einem Produkt arbeiten, können die Vorteile von DevOps realisiert werden. Radikaler ausgedrückt: Das Thema heißt nicht DevOps, sondern BizDevOps. Die Integration von Business und DevOps verändert die Zusammenarbeit, Organisation und Abläufe von Unternehmen so, dass alle Beteiligten Impulse für die digitale Transformation des Unternehmens setzen und schneller wirtschaftlichen Nutzen generieren.

Entwicklung und Betrieb näher zueinander bringen, um den Output für das Business zu erhöhen – mit diesem Ziel setzen immer mehr Unternehmen auf DevOps. Organisatorische Grenzen zwischen funktionalen Silos innerhalb der IT fallen. Interdisziplinäre Teams verfolgen gemeinsame Ziele, und auf Basis neuer Technologien entstehen attraktivere Serviceangebote. Agile Vorgehensweisen und automatisierte Prozesse beschleunigen die Bereitstellung integrierter Services für innovative Geschäftsmodelle. Die vielen Änderungen, die dafür erforderlich sind, stellen so manche IT-Organisation vor eine echte Zerreißprobe. Doch der Einsatz lohnt sich, wie der „State of DevOps Report 2017“ [1] von Puppet belegt. Demnach stellen die High Performer unter den mehr als 3 200 Befragten 46mal häufiger neuen Code bereit. Sie realisieren Änderungen 440mal schneller, verkürzen die mittlere Wiederherstellungszeit um den Faktor 96 und senken die Fehlerrate bei Änderungen um den Faktor 5. Angesichts solcher Zahlen stellt sich nicht mehr die Frage, ob DevOps sinnvoll ist, sondern vielmehr, wie man das Konzept praktisch umsetzt.

DevOps ohne Business bringt wenig

Die Erfahrung aus vielen Kundenprojekten zeigt: Der DevOps-Ansatz in der IT bringt wenig, wenn die Fachabteilung wasserfallartig Vorhaben ohne Einbeziehung der IT plant. Denn dadurch gerät die IT sofort wieder in einen reaktiven Modus und wird als Engpass wahrgenommen. Was Unternehmen stattdessen brauchen, ist eine Veränderung der Einstellungen und Arbeitsweisen sämtlicher Unternehmensteile. Dazu gehören die verschiedenen Fachabteilungen des Business ebenso wie Entwicklung und Betrieb der IT. Wir sprechen deshalb von BizDevOps. Damit ist ein Set miteinander verbundener kultureller Veränderungen und technischer Arbeitsweisen gemeint, mit dem IT und Business gemeinsam die digitale Transformation des Unternehmens vorantreiben. Welche Schwierigkeiten dabei zu bewältigen sind und wie man sie meistert, lässt sich am besten anhand eines häufig anzutreffenden Szenarios aus dem Unternehmensalltag beschreiben: Die IT wird als Blockierer wahrgenommen.

Kontextwechsel sind teuer

Tatsächlich werden die Entwicklungs- und Betriebsteams der IT in vielen Unternehmen als Blockierer wahrgenommen. Der Grund: Weil sie durch die laufenden Projekte und Change Requests aus dem Business voll ausgelastet sind, winken sie bei neuen Anfragen schon fast routinemäßig ab. Die Folge: Einzelne Fachabteilungen versuchen, die Ressource IT möglichst lange an sich zu binden, um ihre mitunter individuelle Agenda umzusetzen. So blockieren sie ihrerseits die IT. Das führt unter anderem dazu, dass Entwicklungsteams häufig parallel an mehreren Projekten arbeiten müssen. Diese Kontextwechsel kosten viel Zeit. Als Faustregel für den Zeitverlust durch Kontextwechsel gilt nach Gerald M. Weinberg [2]: zehn Prozent mal Anzahl der simultanen Projekte. Das bedeutet: Ein Entwickler, der in drei Projekten gleichzeitig arbeitet, verbringt dreißig Prozent seiner Zeit ineffektiv. Eine Ursache dafür liegt darin, dass Entwicklungsteams häufig ohne Kenntnis höherer Ziele und Planungen die Arbeit an Projekten und Changes (Servicebetrieb von bereits entwickelten Anwendungen) priorisieren müssen. Hinzu kommt, dass nach der Theory of Constraints von Eliyahu Goldratt [3] die Wartezeit exponentiell mit der prozentualen Auslastung einer Arbeitsstation steigt. Bei hundert Prozent Auslastung ist die Wartezeit somit unendlich. Häufig versuchen Fachabteilungen in dieser Situation, die Blockade ihrer Projekte durch Eskalation zu lösen. Das hilft zwar nicht beim Sortieren und Abarbeiten der Aufgaben für das Entwicklungsteam, dennoch ist es oft der einzige Weg, Entwicklungen anzustoßen. Der damit verbundene zusätzliche Aufwand ist jedoch kontraproduktiv.

Was Entwickler tun können

Das Blockadeszenario ist nicht nur unwirtschaftlich, sondern auch ausgesprochen demotivierend für Entwicklerteams. Sie für die Mitarbeit an der Lösung des Problems zu gewinnen, ist daher in der Regel einfach, wenn sie die Gelegenheit bekommen, Veränderungen zu treiben. Als erste und wichtigste Maßnahme helfen dabei enge Feedbackzyklen mit den verschiedenen Stakeholdern im Unternehmen. Denn nur im Zusammenspiel aller Beteiligten – im Sinne von BizDevOps – lässt sich die Blockade in der IT dauerhaft auflösen. Bei der Umsetzung kommen eine Vielzahl unterschiedlicher Methoden und Tools zum Einsatz, die je nach Größe, Branche, Ausgangssituation und Strategie des Unternehmens variieren können. Generell lassen sich jedoch die im Folgenden dargestellten vier Maßnahmen als wichtige Schritte auf dem Weg zu einer IT mit höherer Wertschöpfung identifizieren.

Priorisieren in Übereinstimmung mit den übergeordneten Unternehmenszielen: So selbstverständlich diese Maßnahme erscheinen mag – in vielen Unternehmen sind entsprechende Vorgaben graue Theorie. Um das zu ändern, müssen die Entwicklerteams zunächst die Stakeholder zusammenbringen und ein Problembewusstsein schaffen. Dann geht es gemeinsam an die Beantwortung von Fragen wie: Welche Ziele stehen im Vordergrund? Welche Kriterien gelten bei der Priorisierung? Wie lassen sich konkurrierende Interessen vereinbaren?

Liefertransparenz durch Metriken schaffen und kommunizieren: Wenn jedem klar ist, welche Leistungen in welchen Zeiträumen erbracht werden, tun sich alle Beteiligten leichter, Arbeitspakete zu schnüren, die dann planmäßig abgearbeitet werden können. Dazu gehören unter anderem auch das Tracking von Durchlaufzeiten bei Change Requests und das Messen der Fehlerrate: Wie viele Changes schlagen eigentlich fehl und verursachen damit Rework? Regelmäßiges Reporting für das Team und die Stakeholder ist ein wichtiger Beitrag zum Funktionieren jeder DevOps-Organisation. Darüber hinaus gilt unabhängig von der offiziellen Kommunikation das Grundprinzip: Jeder soll offen mit Informationen umgehen, damit alle Beteiligten sich auf die aktuelle Situation einstellen können. So können alle Beteiligten Verbesserungen wahrnehmen oder zur Beseitigung von Defiziten aktiv beitragen.

Arbeit organisieren mit Scrum Boards und Kanban Boards: Methoden wie Scrum und Kanban liefern wertvolle Tools, um auch in einem komplexen Umfeld den Fokus zu behalten. Doch Tools allein reichen dafür nicht aus. Alle Mitglieder des Teams müssen sich immer wieder bewusst auf die gemeinsamen Ziele fokussieren. Nur weil eine Aufgabe schnell und einfach abzuhaken ist, zahlt sie nicht unbedingt auf das aktuelle Ziel des Teams ein. Gemeinsam vorankommen ist gefragt. Kleine Losgrößen etablieren, Work in Progress vermeiden und Aufgaben fertigstellen ist wichtig. Doch für das Team ist es nicht immer förderlich, dass jemand eine neue Aufgabe beginnt, sobald er eine abgeschlossen hat. Um ein Sprintziel zu erreichen, ist es oft wichtiger, andere bei ihren Aufgaben zu unterstützen. Darüber hinaus sorgt die gemeinsame Arbeit dafür, dass der Ausfall einzelner Teammitglieder besser kompensiert wird.

Retrospektiven – Blick zurück nach vorn: Regelmäßige Retrospektiven mit Fokus auf Action Items (Maßnahmen) zur kontinuierlichen Verbesserung zeigen, was in der Vergangenheit funktioniert hat – und was nicht. Das ist die Grundlage für Verbesserungen und dafür, eine Antwort auf die zentrale Frage zu finden: Was können wir tun, um die volle Pipeline besser zu managen? Aus den Fehlern und Erfolgen der Vergangenheit zu lernen, erfordert allerdings auch Zeit, die von vornherein eingeplant sein will. Gene Kim, Jez Humble und Patrick Debois empfehlen im DevOps Handbook [4], zwanzig Prozent der Zeit für solche Verbesserungen freizuhalten.

Die Umsetzung der Maßnahmen sind der erste Schritt in die DevOps-Transformation, und die Erfahrung zeigt: Den Startimpuls kann jeder setzen – egal ob Biz, Dev oder Ops!