Ich hatte vor kurzem ein sehr einprägsames Kundenerlebnis, über das ich gerne näher erzählen möchte.
Der Aufbau einer sicheren und zuverlässigen Infrastruktur ist eine besondere Herausforderung! Noch spannender wird es aber, wenn bei Softwareentwicklungen sowohl die Qualität, die Geschwindigkeit der Entwicklung als auch die Auslieferung (Time-to-Market) verbessert werden soll. Laut Lehrbuch soll dabei DevOps mit einer Reihe von Tätigkeiten und Methoden aus der Softwareentwicklung für Agilität in Unternehmensabläufen und Prozessen sorgen.
Letztens sollten wir bei einem Kunden mehr Flexibilität in der Auslieferung von einzelnen Softwaremodulen schaffen. Meine erste Reaktion: „Was heißt das? Wieviel Flexibilität? Wo genau? Und welche Art von Flexibilität?“ Mein Versuch, das gewünschte Ziel genauer zu spezifizieren, scheiterte. Ich erhielt keine Antwort auf meine Fragen.
Genau so und nicht anders sehen Anfragen unserer Kunden zum Thema DevOps aus.
Obwohl sich ITdesign schon seit mehreren Jahren mit dem Thema DevOps beschäftigt, bin ich selbst bis dato nur sehr oberflächlich damit in Berührung gekommen. Warum und weshalb? Na klar, wegen der unklaren Zielvorgaben!! Denen bin ich bisher, so gut wie möglich, aus dem Weg gegangen.
Sie lösen in mir das Gefühl aus, das Ziel (welches genau?) sowieso nie erreichen zu können. Das Projekt wird nie fertig und ist monetär ein Fass ohne Boden. Diese Aussicht muss ja auch für den Kunden der blanke Wahnsinn sein. Das musste ich erst mal verdauen.
Ein Auftrag, aber kein (klares) Ziel?
Natürlich gab ich so einfach nicht auf und mein doch sehr intensives Nachhaken bezüglich einer Definition der Zielvorgaben ging weiter. Aber sowohl der Kunde als auch mein Spezialist meinten, die finale Struktur selbst nicht zu kennen und nur mit Annahmen zu arbeiten. Auch gewisse Leerkilometer waren ihnen bewusst und diesen wollten sie mit kurzen Projektzyklen begegnen. Agile Entwicklung also!
Hm, also an sich ist mir diese agile Herangehensweise bekannt und wir haben auch bereits einige Projekte in der Software-Entwicklung nach diesem Modell umgesetzt. Der große Unterschied war bisher aber, dass ich an einem Produkt, das an die Erfordernisse des Marktes angepasst werden sollte, gearbeitet habe.
Bei DevOps geht es aber nicht nur um die Entwicklung des Produkts, denn letztendlich sind die gesamten Entwickler- und Operations-Teams betroffen. Das heißt, es geht um Menschen, die ihre bisherigen Abläufe aufgeben und diese durch neue ersetzen. Aus meiner Sicht sollten solch gravierende Veränderungen gut geplant und nicht mit agilen Methoden nach dem Prinzip „Try & Error“ zurechtgerückt werden. Meine große Sorge dabei war, Kolleg:innen am Weg zu verlieren.
Da ich selbst noch keine Erfahrung mit derartigen Projekten hatte, habe ich sowohl den Kunden als auch meinen Spezi über meine Bedenken informiert.
Man lernt nie aus
Mittlerweile habe ich gelernt, dass eine DevOps-Kultur die beteiligten Menschen, also die Entwickler- und Operations-Teams, enger zusammenwachsen lässt. Warum ist das so? Durch die Kombination der beiden Arbeitsprozesse und der damit einhergehenden Übernahme von Verantwortung bzw. dem Teilen von Verantwortung entsteht ein unglaublich großer Teamspirit, der für eine starke Bindung sorgt. Diese Erkenntnis hat mir die Sorge genommen, am Weg Kolleg:innen zu verlieren.
Das Feedback eines anderen Kunden lehrte mich, dass ausgerechnet die Diversität zwischen den ursprünglichen Fachbereich-Teams (Entwicklung und Operation) und den neuen gemischten Teams für mehr Qualität und Produktivität sorgt. Fast scheint es so, als würde genau dieser Teamspirit teilweise auch Ineffizienz beseitigen bzw. kompensieren.
Was mir aber alle Kunden, die bisher eine DevOps-Kultur etabliert haben, bestätigten, ist, dass sie intensiv an ihrer Kommunikationskultur arbeiten mussten. Genau diese Kommunikationskultur ist, meiner Meinung nach, hauptverantwortlich für die erfolgreiche Optimierung der Produktivität der Entwickler und der Steigerung von Zuverlässigkeit betrieblicher Abläufe in solchen Projekten.
Eine spannende Erkenntnis: Der Knackpunkt ist also nicht die Agilität dieser Projektart, sondern die Kommunikationskultur!! Ich weiß, dass sich viele Unternehmen beim agilen Teil Unterstützung von Externen holen. Aber warum nicht beim wichtigsten Teil? Warum verzichtet man bei der Kommunikationskultur auf externe Beratung? Kann mir das irgendjemand erklären? Würde mich freuen!