Fangen wir mit ein wenig Geschichte an: es gab eine wundervolle Zeit, da war man als Softwareentwicklungsteam aus dem Schneider, wenn das liebevoll hergestellte Stück Software auf eine CD gebrannt und bei irgendeinem anonymen Kunden über den Zaun geworfen war.
Betrieb? Nicht mein Problem.
Das müssen schöne Zeiten gewesen sein. Dann kam das Internet und irgendwie hatten Kunden plötzlich Anspruch auf zeitnahe und idealerweise automatische Aktualisierung ihrer Produkte.
Dann wurde alles irgendwie Cloud und es hat auch so ziemlich jeder verstanden, dass man mit dem Betrieb von Software deutlich mehr Geld verdienen kann, als wenn man dem Kunden nur eine CD verkauft und dann noch ständig kostenlos Patches hinterherwerfen muss.
Das stellt nun aber immer mehr Software-Entwicklungsteams vor die Herausforderung, dass Störungen aus dem Betrieb nicht an irgendeiner Support-Abteilung hängenbleiben und bis zum nächsten „Patchday“ in drei Monaten gefixed sein müssen, sondern das Team jetzt die Verantwortung für die möglichst unmittelbare Beseitigung einer solchen Störung hat.
Anders gesagt: das Team beeinflusst jetzt viel unmittelbarer die Wertschöpfungskette, da ändern sich auch die Prioritäten ein wenig.
Und sobald das passiert wird aus unserem Entwicklungsteam ein DevOps-Team. Ob wir das nun wollen oder nicht.
Diese Verantwortung ist aber auch eine ständige Bedrohung für unseren, per heiligem Dekret geschützten Sprint. Manchmal ist das Risiko sicher überschaubar aber manchmal endet das auch so, dass zweimal die Woche alle mit hochrotem Kopf im Kreis rennen und sich gegenseitig anschreien.
Warum?
Betrieb erfordert andere Prioritäten. In der Entwicklung mit Scrum erwarten wir funktionsfähige und auf Herz und Nieren getestete Inkremente. Umfang und Priorisierung sind fix und das Team bekommt die Zeit die es braucht.
In der anderen Ecke: Störungen aus dem Betrieb. Die klingen dagegen eher so: „… und wenn mit Panzerband und Blumendraht, Hauptsache das läuft erstmal wieder. Bis wann? Gestern wäre gut.“
In so einer Situation werden wir mit Scrum, Refinement, geschütztem Sprint und 2-3 Wochen Iterationen niemanden glücklich machen. Da stehen die Dorfbewohner direkt mit Fackeln und Mistgabeln in der Tür – zu recht, wie man zugeben muss.
Lösungsvorschlag: wenn die Anforderungen an den Entwicklungs- und Betriebsprozess so unterschiedlich sind, wäre es doch naheliegend auch zwei Prozesse dafür zu definieren und für diese beiden Prozesse auch dediziert Ressourcen bereitzustellen.
Oder einfacher gesagt: es braucht einen Betriebsprozess und dedizierte Ressourcen dafür. Dann klappts auch wieder mit dem geschützten Sprint.