Agiles Entwickeln

DevOps krempelt Hierarchien um

31.12.2015 von Christoph Lixenfeld
Forrester sagt, wer DevOps beherrscht, braucht keine IT der zwei Geschwindigkeiten. Organisation und Strukturen werden sich mit Einführung der Methode ändern.
  • DevOps steht für hierarchiearme Entwicklungsprozesse.
  • Nach Ansicht von Forrester verändern sich dadurch auch hierarchische Strukturen.
  • Die Analysten haben 40 Unternehmen zu dem Thema interviewt.

Die Digitalisierung fast sämtlicher Kundenbeziehungen bietet Unternehmen große Chancen und verursacht zugleich Probleme. Nie war es leichter, neue Kunden zu gewinnen oder vorhandene zu verlieren.

Etablierte Unternehmen fürchten sich vor Startups mit neuen Ideen und innovativen Softwarelösungen, während sie selbst sich mit ihren jahrzehntealten Systemen herumschlagen müssen, die sich nicht in wenigen Wochen oder Monaten erneuern lassen.

In seinem Report: "Forget Two-Speed IT. DevOps enables faster delivery across the board" beschreibt Forrester die Vorteile von DevOps als Entwicklungs- und Implementierungsmethode auch und gerade in historisch gewachsenen Anwendungsumgebungen.

Eine Definition von DevOps

DevOps und Scrum werden oft als Alternative zur klassischen Wasserfall-Entwicklung gepriesen. Dabei geht es um mehr als nur um eine geänderte Art der Softwareentwicklung.
Foto: Marvellousworld - Fotolia.com

DevOps ist ein Kunstwort, das sich aus den ersten Silben von ‚Development‘ und ‚Operations‘ zusammensetzt, also aus Entwicklung und Betrieb.

Der Ansatz ähnelt dem der agilen Softwareentwicklung, nur dass es bei DevOps zusätzlich darum geht, Abteilungsgrenzen aufzulösen. Das macht es schwieriger, solche Ansätze in der Praxis zu etablieren.

Gelingen kann das nur, wenn bei allen Beteiligten Anreize für das sich Einlassen auf das Verfahren bestehen.

Es geht um die Frage, wie sich die ursprüngliche Idee einer Software schnell und stabil zum Kunden bringen lässt. Eine Entscheidung für neue Methoden wie DevOps fällt dabei natürlich nur dann, wenn damit aus Sicht der Unternehmensleitung ein quantitativ messbarer Vorteil gegenüber anderen Vorgehensweisen verbunden ist.

Methodisch lautet das Ziel, eine bessere Zusammenarbeit zwischen Entwicklungsteam, Service und Management zu etablieren, als das in traditionellen, hierarchischen Strukturen normalerweise der Fall ist.

Abteilungsgrenzen und Hierarchien abschaffen

Abteilungsgrenzen und Hierarchien sollen so weit wie möglich ausgeschaltet werden, das heißt Entwickler, Fachabteilungen und Management müssen willens und in der Lage sein, auf Augenhöhe zusammenzuarbeiten. Idealerweise arbeiten dabei so viele Beteiligte wie möglich temporär in denselben Räumen.

Das Vorgehen bei der Entwicklung wird oft mit Hilfe solcher Schaubilder beschrieben. Wer sie versteht, hat die größte Hürde bereits genommen.
Foto: MicroTool

Scrum dient zur Steuerung

Zur Steuerung der abteilungsübergreifenden 'Operations' kommt meistens das Scrum-Verfahrenzum Einsatz. Grundannahme dahinter: ModerneSoftwareentwicklung ist zu komplex, um von vorne bis hinten planbar zu sein. Scrum reduziert die Komplexität erstens durch mehrere Feedbackschleifen, zweitens werden gewünschte Funktionen ständig überprüft und wenn nötig nachgeschärft.

Das Verfahren ist rollenbasiert, die beiden wichtigsten Rollen sind die des Product Owners und des Scrum Masters. Der Product Owner ist für den Erfolg verantwortlich, muss sicherstellen, dass das entwickelte Produkt sauber definiert ist und am Ende das kann, was es können soll. Der Scrum Master moderiert den ganzen Prozess.

Feedback und Retrospektive in Scrum-Projekten
Retrospektive und Feedback in Scrum-Projekten
Scrum Manager haben die Möglichkeit, den Projekterfolg durch die Analyse des Sprints zu verbessern. Zielführend sind dabei die Retrospektive und das Feedback der Teammitglieder - ein Vorgang, den der Scrum Manager mit Diplomatie moderieren muss. Folgende Methodik mit Arbeitsblättern hat sich bewährt.
Feedback - Schritt 1
Für die Retrospektive erhält jedes Teammitglied ein vorbereitetes Blatt mit seinem Namen und zwei Fragen: "Was kann man von mir erwarten?" und "Was erwarte ich vom Team?"
Feedback - Schritt 2
Der Feedback-Bogen wird um zwei Bereiche ergänzt: "Was ich an Deiner Arbeit schätze ..." und "Was ich Dir wünsche, das Dir besser gelingt ..."
Feedback -Schritt 3
Der Feedback-Bogen wird an den Tischnachbarn weitergegeben, von diesem ausgefüllt und so lange weitergegeben, bis jeder Teilnehmer wieder sein persönliches Blatt vor sich liegen hat – jetzt mit dem schriftlichen Feedback aller beteiligten Teammitglieder.
Selbstreflexion
Zwei weitere Bereiche kommen hinzu – sie dienen der eigenen Reflexion des erhaltenen Feedbacks: "Darauf bin ich stolz ..." und "Das nehme ich mit ..."
Vorgehensmuster
Nach diesem Grundmuster lassen sich Retrospektiven zu einem späteren Zeitpunkt erneut wiederholen.

Forrester argumentiert nun in seinem Report, dass Entwicklungsabteilungen, die diese Klaviatur beherrschen, sie mit Erfolg in sämtlichen Softwareprojekten anwenden können und so ihre Chance deutlich erhöhen, im Rennen um die besten digitalen Plattformen und Lösungen zu den Gewinnern zu gehören.

Immer den Kunden im Blick

Existenziell ist das vor allem deshalb, sagt Forrester, weil Erlebnisse und Erfahrungen von Kunden in Zusammenhang mit Internetplattformen und mobilen Lösungen darüber entscheiden, ob diese Kunden gehen oder bleiben.

Deshalb sei es so wichtig, Lösungen schnell in höchster Qualität zur Verfügung stellen zu können, und zwar absolut jede Art von Softwarelösung.

So wenige Abhängigkeiten wie möglich

Diese Ansprüche an Schnelligkeit und Nutzerfreundlichkeit lassen sich allerdings nur erfüllen, wenn außer dem Frontend auch das Datenmanagement im Backend den heutigen Anforderungen an Schnelligkeit und Benutzerfreundlichkeit genügt.

Hilfreich sei es dabei, unterschiedliche Anwendungsszenarien softwareseitig in parallel nebeneinander arbeitenden Lösungen abzubilden, das heißt diese Lösungen sollten so wenige gegenseitige Abhängigkeiten wie möglich aufweisen.

Mit agilen Verfahren verbindet sich regelmäßig die Hoffnung, dass sie traditionell hierarchische Strukturen in Unternehmen aufbrechen.
Foto: Bloomua - shutterstock.com

Nur so lassen sich unterschiedliche Kundenansprüche und unterschiedliche Releasezyklen adressieren. Und nur so können Unternehmen bei jeder anstehenden neuen Aufgabe, für die sie eine Lösung suchen, entscheiden, ob sie selbst entwickeln oder zukaufen wollen.

Nie aus den Augen verlieren dürfen Unternehmen dabei die Chance, jede Kundentransaktion zur Gewinnung von Daten zu nutzen. Und diese Daten sollten immer auch dazu dienen, die Performance der eigenen Lösungen zu verbessern.

Unternehmen in der digitalen Transformation
Digitaler Vorreiter IT
Im Vergleich zu anderen Fachbereiche wie Finance und vor allem Forschung & Entwicklung ist die Digitalisierungspriorität in der IT hoch. Der Kostendruck erscheint zudem weniger ausgeprägt.
Druck zur Anpassung
Gerade auch in der IT herrscht hoher Anpassungsdruck an neue Anforderungen. Auch der Innovationsdruck ist hoch.
Es hapert an Durchlässigkeit
Mehr Flexibilität, Agilität, Durchlässigkeit und Vernetzung predigen die Studienautoren. Die Ergebnisse ihrer Untersuchung zeigen, dass die Umsetzung offenbar noch Zeit braucht.
Silodenken und Akzeptanzmangel
Die Übersicht zeigt, woran die Umsetzung der für die Digitalisierung wichtigen Maßnahmen scheitert. Auch fehlende Unterstützung der Unternehmensspitze zählt zu den Hürden.
Projektmodus an
Laut Studie werden immer Arbeiten innerhalb von Projekten erledigt. Bei der Implementierung von Lösungen und Prozessen ist Projektarbeit in besonderem Maße zum Standard geworden.
Planungen oft unrealistisch
In der Studie gibt es auch Antworten auf die Dauerbrennerfrage, woran Projekte eigentlich scheitern. Am häufigsten genannt: Planungsversagen.
Know-how von außen
Hays und PAC diagnostizieren, dass die Abteilungen immer öfter auf externe Mitarbeiter und Dienstleister zurückgreifen. Die Grafik zeigt, dass auch hier die IT Vorreiter ist.

Als Netzwerk organisierte Entwicklungsarchitektur

Wichtig ist - aus Sicht von Forrester - dass absolut sämtliche Anwendungen, mit denen der Kunde in Berührung kommt, intuitiv und ohne jede Art von Training nutzbar sind.

Ein zentraler Vorteil dieses Vorgehens ist, dass sich mit der unterschiedlichen Art, Software zu entwickeln, auch die Organisations- und Hierarchiestrukturen des entwickelnden Unternehmens verändert. Der Zusammenhang kann, wenn Unternehmen das wollen, ein ganz praktischer sein: Eine eher lose, als Netzwerk organisierte Entwicklungsarchitektur verschafft den Teams mehr Flexibilität und Freiheit.

Wenn große Organisationen sich darauf einlassen, verändern sich auch solche Strukturen, die mit dem eigentlichen Entwicklungsprozess gar nichts zu tun haben. Diese Chance sollten Unternehmen unbedingt nutzen, so Forrester.