Was hält Ihr DevOps-Team zurück (abgesehen davon, dass es als „DevOps-Team“ bezeichnet wird)

Eine Vernachlässigung der Rolle der agilen Entwicklung für den Erfolg von DevOps bedeutet, dass die meisten Unternehmen Schwierigkeiten haben werden, den höchsten Reifegrad zu erreichen.

Die Theorie der DevOps ist elegant einfach. Man hebt die traditionelle Abgrenzung zwischen den Bereichen Entwicklung und Betrieb auf, um näher an den Kunden heranzukommen und relevantere Funktionen häufiger bereitzustellen. Mit anderen Worten geht es darum, innovativ zu sein.

Die Realität sieht dagegen nicht ganz so aus. Dabei hat jede Organisation, die behauptet, ein DevOps-Team zu haben, bereits einen fatalen Fehler gemacht. Die Aufstellung eines Teams ist nicht dasselbe wie die Transformation Ihres gesamten Betriebsmodells, um die Stimme des Kunden in den Mittelpunkt Ihrer Unternehmensstrategie zu stellen. Außerdem glauben zu viele, es sei nur eine Frage der Tools und übersehen dabei die Tatsache, dass ohne die richtige kulturelle Unterstützung für DevOps die Tools niemals maximale Effizienzgewinne bringen werden. In erster Linie handelt es sich hierbei um eine Kultur der verstärkten Zusammenarbeit. Um dies zu unterstützen, muss es ein Gefühl der geteilten Verantwortung zwischen Entwicklungs- und Betriebsteams geben (die berühmte „You build it, you run it“-Mentalität, die 2006 von Amazon-CTO Werner Vogels postuliert wurde). Organisatorisch darf es zwischen den beiden Bereichen keine Silos geben, wobei sie jedoch autonom arbeiten können müssen.

Der Prozessmechanismus, der dieser wesentlichen kulturellen Entwicklung zugrunde liegen kann, ist eine andere, viel erprobte, aber kaum verstandene Methode: die agile Entwicklung (Agile Development).

Einfach ausgedrückt: Man kann nicht zu einem echten DevOps-Modell und einer echten DevOps-Kultur übergehen, ohne agile Praktiken zu fördern. Sie können so viele DevOps-Tools einsetzen, wie Sie möchten – ohne agile Methoden werden Sie lediglich an der Art und Weise tüfteln, wie Sie die verschiedenen Stacks Ihrer Anwendungen aufbauen. Sie werden jede Schicht mit mehr Automatisierung auf dem Weg zum nächsten Kontrollpunkt aufbauen. Ohne jedoch diese Kontrollpunkte vollständig zu eliminieren, werden Ihre Kunden (und Ihre Entwickler) letztendlich kaum einen Unterschied merken.

Wie die agile Entwicklung Innovationen vorantreibt

Der traditionelle Ansatz zur Innovation ist ein langer und investitionsintensiver Prozess. Produktgruppen schlagen die Ideen vor, an denen sie im nächsten Jahr arbeiten wollen, und erhalten dann ein paar Millionen Euro, um genau dies zu tun. Eventuell führen Sie regelmäßige Reviews durch, um einzelne Aspekte des Plans neu zu bewerten. Allerdings ist es unwahrscheinlich, dass sich das Ziel in bedeutendem Ausmaß ändern wird. In der Folge wird mit Millionenbeträgen kalkuliert, ohne zu wissen, wie die Ergebnisse aussehen könnten. Und das macht die Kosten eines Scheiterns extrem hoch.

Bei der Lieferung von Hardware macht dies durchaus Sinn – eine teilweise gebaute Bohrinsel oder ein Flugzeugträger nützen nicht viel. Bei Software macht dies jedoch keinen Sinn, weil hier Produktfunktionen hinzugefügt und verfeinert werden können, während die Lösung bereits auf dem Markt ist.

Die agile Entwicklung spiegelt dies wider, indem sie die Bereitstellung nützlicher Lösungen in kürzerer Zeit und mit geringeren Investitionen ermöglicht. Anstatt Millionen-Euro-Wetten mit einem Zeitrahmen von 18 Monaten zu platzieren, können Sie mit der agilen Entwicklung Wetten im Wert von 200.000 Euro auf „Minimum Viable Products“ (MVPs) platzieren, die in drei bis sechs Monaten geliefert werden können. Auf diese Weise sind die Kosten für die Erkenntnis, dass es keinen Markt für Ihre Funktionen gibt, viel geringer. In einem solchen Fall können Ihre Teams schnell dorthin umschwenken, wo tatsächlich eine Nachfrage besteht.

All dies basiert auf der Orchestrierung von Menschen, Prozessen und Technologien, um den Kunden schnell funktionierende Funktionen mit Mehrwert zu liefern, ihr Feedback einzuholen und dann auf der Grundlage dieses Feedbacks Prioritäten für die Entwicklung zu setzen.

Und das ist der Punkt, an dem Organisationen, die mit DevOps zu kämpfen haben, eher zu kurz kommen.

Ineffektive Betriebsmodelle untergraben das Leistungspotenzial der Mitarbeiter

Ohne ein agiles Betriebsmodell ist es schwierig, Architektur, Prozesse und Engineering-Gruppen aufeinander abzustimmen. Ihre widersprüchlichen Priorisierungen werden die Bemühungen einer schnellen Bereitstellung von Code schnell zunichte machen. Aufgestellt als getrennte Gruppen, werden diese Teams immer ihr eigenes Ding in ihrer eigenen Zeit machen und nach dem Wasserfall-Prinzip jede Ebene erst dann übergeben, wenn sie bereit ist.

Stattdessen bringen die vertikal aufgeteilten Teams im Agile-Ansatz die Mitglieder jeder Organisation in eigenständigen und selbstgesteuerten Gruppen zusammen, die spezifische Merkmale viel schneller bereitstellen können.

Eine uneinheitliche Annahme von Agile führt zu unausgereiften Prozessen

Wir sehen durchaus, dass viele Organisationen einige agile Verfahren und einen Großteil der Sprache übernehmen. Allerdings bleiben viel weniger den wahren Prinzipien treu. Indem sie einigen Bestandteilen folgen, aber die Absicht verfehlen, wenden sie die Prozesse nicht konsequent an oder unterstützen sie nicht mit adäquaten Messungen oder Kennzahlen.

Das Ergebnis ist, dass mehr Wegpunkte in den Wertstrom (die Anzahl der Schritte zwischen einer Idee und der Bereitstellung einer Funktion für den Kunden) eingefügt werden. Und das bedeutet, dass die Veröffentlichung von Versionen oft länger dauert als zuvor. Wenn das passiert, schwindet das Vertrauen des Teams in den Agile-Ansatz, die Moral sinkt und die Kunden stehen mit leeren Händen da.

Unzureichende Technologie und Tools

Technologie und Tools stellen eine doppelte Herausforderung dar, um eine agile Grundlage für den Erfolg von DevOps zu schaffen. Erstens muss die Codebasis für Ihre Anwendungen um Container und Microservices herum neu strukturiert werden, um die Bereitstellung auf einer Feature-by-Feature-Basis zu ermöglichen. Ohne dies können Ihre Teams ihre „Anwenderstories“ (eine informelle Erklärung des Ziels einer Funktion, die aus der Perspektive des Benutzers erzählt wird) nicht vertikal aufschlüsseln, was ein Schlüsselmerkmal von DevOps ist.

Wenn es um die Tools geht, sehen wir auf der Codeseite typischerweise, dass veraltete Tools für das Konfigurationsmanagement unweigerlich zu insgesamt veralteten Prozessen in diesem Bereich führen. Und wenn Sie veraltete Projektmanagement-Tools verwenden, haben Sie definitiv die falsche Toolbox.

Die sechs kritischen Erfolgsfaktoren für eine auf Agilität gestützte DevOps-Reife

Um diese Herausforderungen zu überwinden und Ihre DevOps-Strategie mit agilen Prozessen als Kernstück neu aufzusetzen, empfehlen wir Technologieführern, sich auf die folgenden kritischen Erfolgsfaktoren zu konzentrieren.

1.     Versuchen Sie nicht, alles auf einmal zu erreichen. Identifizieren Sie stattdessen zunächst ein bestimmtes Produkt und bilden Sie dann ein Team, um es zu transformieren, während Sie gleichzeitig an agilen Prozessen arbeiten.

2.     Machen Sie den Schritt und ermöglichen Sie die Agilität von oben herab, indem Sie sich die Zeit nehmen, Agilität zu verstehen und zu fördern. Nur mit dem Commitment der Leitungsebene kann die Stimme des Kunden in die strategische Vision des Unternehmens einfließen. Der Schlüssel dazu ist es, den technischen Teams die Möglichkeit zu geben, die Kadenz für die Veröffentlichung von Funktionen festzulegen. Dies wird erreicht, indem man sich von erhofften Release-Terminen verabschiedet, um das Niveau des MVP zu definieren, das in der vorgegebenen Zeit möglich ist. (Dies wird zudem dafür sorgen, dass sich Entwickler stärker in ihrer Arbeit engagieren, und insgesamt auf die Verbesserung der Unternehmenskultur einzahlen.)

3.     Führen Sie eine Wertstromanalyse durch, um zu verstehen, wie viele Schritte derzeit erforderlich sind, um eine Idee vom Brainstorming bis zum Kunden zu bringen. Nutzen Sie dann das vertikal segmentierte Betriebsmodell von Agile, um diese zu reduzieren.

4.     Schließen Sie Ihre Feedback-Schleifen, indem Sie in regelmäßigen Abständen die Stimme des Kunden einbeziehen. Das Timing ist wichtig, da sich die Kunden nicht gehört fühlen, wenn Ihre Zeitvorgaben zu lang sind. (Mithilfe der Wertstromanalyse werden Sie auch erkennen können, wo und wann diese Feedbackschleife stattfindet – oder ob sie unterbrochen ist).

5.     Bewerten Sie Ihre DevOps und agilen Methoden und vergleichen Sie sie mit Best Practices. Ermitteln Sie anschließend messbare Ergebnisse und Methoden zur Leistungsverfolgung anhand dieser Methoden.

6.     Behandeln Sie schließlich die Umwandlung in ein DevOps-Betriebsmodell als eine Agilitätsübung an sich, indem Sie der kontinuierlichen Verbesserung Vorrang einräumen. Das bedeutet, einen Plan zu erstellen, mit dem Teams aus ihrer Leistung lernen und den Prozess mit jeder neuen Version verbessern können.

Join the Conversation: Find Solve on Twitter and LinkedIn, or follow along via RSS.

Stay on top of what's next in technology

Learn about tech trends, innovations and how technologists are working today.