• IT-Karriere:
  • Services:

Wie DevOps gelingt

"Wir haben sehr gute Erfahrungen mit DevOps gemacht", habe ich bei einem meiner letzten Projekte gehört. Das hat mich gefreut, doch wie kann man zu diesem Punkt kommen? Selten startet die Wandlung im oberen Management; meist sind es Produkt- oder Projektverantwortliche oder Techniker, die erkennen, wie sie von anderen Arbeitsweisen, Technologien und Mentalitäten profitieren können. Wie so oft gilt, dass man erst einmal beweisen muss, dass etwas Neues funktionieren kann, bevor andere dem folgen.

Klein anfangen

Stellenmarkt
  1. Dürr IT Service GmbH, Bietigheim-Bissingen
  2. IT-Systemhaus der Bundesagentur für Arbeit, Nürnberg

Es gibt sicher viele Strategien, um DevOps, agiles Arbeiten und Co. in Organisationen zu bringen. Eine häufig erfolgreiche Variante ist die Einführung unter dem Radar "von ganz oben". Es ist unrealistisch, von Topführungskräften zu erwarten, dass sie Strukturen ändern, wenn man nicht klar genug aufzeigt, wo die Schwächen des aktuellen Systems liegen und wie konkret man anders, und vor allem erfolgreicher, vorgehen kann.

Schon häufig habe ich daher die Herangehensweise beobachtet, dass eher kleine Teams die Köpfe zusammenstecken und für ein isoliertes Thema sowohl DevOps als auch agile Methoden einführen. Manchmal sind beides Folgethemen, da Technik-Enthusiasten eigentlich ihre Anwendungen auf Container umstellen wollen, aber damit nur erfolgreich sein können, wenn IT anders gedacht wird.

Wenn wir beim Szenario der selbstgeschriebenen Software bleiben, kann es eigentlich egal sein, ob eine Einführung von DevOps und Co. anhand einer neuen oder bestehenden Anwendung erfolgt, so lange alle an Bord sind.

Wichtig ist, dass die Beteiligten ein gleiches Verständnis dafür entwickeln, was für sie DevOps und agiles Arbeiten bedeutet. Auf dieser Grundlage lässt sich Schritt für Schritt ein Wandel einleiten:

1. Um nicht zu viel Widerstand zu erzeugen, sollte in diesem frühen Stadium nicht an Abteilungen, Zuständigkeiten und Organisationsstrukturen gerüttelt werden. Stattdessen ergänzen die Beteiligten das Bestehende um eine neue Ebene.

2. Aus den beteiligten Abteilungen heraus werden motivierte Kollegen "entsendet", ein virtuelles Team bildet sich.

3. Dieses virtuelle Team lebt und arbeitet nach agilen Methoden und wendet DevOps an, wo es vorteilhaft und sinnvoll ist. Die Mitglieder des virtuellen Teams erhalten von ihren Abteilungsleitern genug Zeit für ihr neues Vorhaben.

4. Beteiligte Führungskräfte, zum Beispiel Projektleiter, entwerfen grobe Ziele oder gerne auch Visionen, was als Erstes in Angriff genommen werden sollte. Das kann beispielsweise ein neues Produkt oder eine neue Version einer bestehenden Anwendung sein.

5. Ein Kick-off-Meeting mit allen Beteiligten stimmt auf die Ziele ein, gibt einen groben zeitlichen Horizont vor, zum Beispiel ein halbes oder ein ganzes Jahr, und legitimiert die neuen Arbeitsweisen. Alle verpflichten sich für "die Sache". Product Owner und Scrum Master werden festgelegt und verkündet.

6. Sprint-Wechsel, Standups, Reviews und Retros werden regelmäßig abgehalten.

Schon nach dem ersten oder wenigen Sprint-Wechseln sollte ein Ergebnis sichtbar sein, das man vorzeigen oder benutzen kann. Jeder weitere Sprint-Wechsel baut auf dem vorherigen auf, Stück für Stück wächst der Fortschritt zum gewünschten Endergebnis heran.

Mit dieser Erfolgsgeschichte können die Beteiligten an höhere Management-Ebenen herantreten. In offenen und ehrlichen Gesprächen werden die gelernten Lektionen offengelegt, womit Vor- und Nachteile der Thematik deutlich werden. Je nach Organisation kann es sinnvoll sein, Handlungsempfehlungen auszusprechen: Wie lässt sich dieser Erfolg nun im größeren Maßstab wiederholen?

DevOps zur Chefsache machen

Spätestens zu diesem Zeitpunkt müssen sich die höheren Führungsebenen intensiver mit der Thematik DevOps und agiles Arbeiten beschäftigen. Es muss bewusst werden, dass eine konsequente Einführung nichts weniger als eine Transformation der Organisation herbeiführen muss, da diese Themen alle möglichen Ebenen berühren. Die Transformation wird mehrere Jahre in Anspruch nehmen und sicher nicht geradlinig verlaufen.

Um in großen Organisationen den Überblick zu behalten und alles irgendwie einzuordnen, ist es sinnvoll, sich für agile Arbeitsweisen ein bewährtes Modell anzueignen und dieses auf die eigene Struktur anzuwenden. Schon mehrfach bin ich dabei auf das SAFeFramework gestoßen, das einen guten roten Faden für die Strukturen bietet. Warum alles neu erfinden, wenn sich solche Modelle bereits bei großen Organisationen bewährt haben? Als Framework stellt SAFe Vorgaben für die Organisation und Rollen bereit, die sich gut in der Praxis anwenden lassen.

Sehr wichtig sind dabei Mitarbeiter, die die Umstellung gegenüber ihren Kollegen mit Begeisterung vertreten.

Bitte aktivieren Sie Javascript.
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
  • ohne Werbung
  • mit ausgeschaltetem Javascript
  • mit RSS-Volltext-Feed
 Woran DevOps scheitern kannBotschafter für den Wandel finden 
  1.  
  2. 1
  3. 2
  4. 3
  5. 4
  6. 5
  7. 6
  8.  


Anzeige
Hardware-Angebote
  1. täglich neue Deals bei Alternate.de
  2. (reduzierte Überstände, Restposten & Co.)

eechauch 09. Mär 2020

Was für ein Blödsinn. Ich kann dir garantieren, dass wir im Sicherheitsbereich seit...

konsolent 06. Mär 2020

Der (durchaus lesenswerte) Beitrag beginnt mit diesem erstaunlichen Satz: "Konzerne...

dermamuschka 06. Mär 2020

Jo, verstehe auch nicht, für mich ist das offensichtliche Akquise. Euer Großkonzern ist...

VigarLunaris 05. Mär 2020

Aber auch wenn Abteilungen auch schon ohne DevOps und dem ganzen Agile gerede zusammen...

demonkoryu 05. Mär 2020

Hat mir sehr geholfen mein Verständnis zu erweitern und präzisieren. Danke!


Folgen Sie uns
       


    •  /