Scrum im Betrieb von Standardsystemen. Tipps aus der Praxis.
In den letzten Jahren durfte ich verschiedene Teams auf dem Weg zu einer agileren Arbeitsweise coachen. Die Teammitglieder waren meist keine Softwareentwickler, sondern Engineers, die sich in den IT-Abteilungen von Grosskonzernen um den Betrieb und die Konfiguration von Standardsystemen kümmern.
Die Ausgangslage präsentierte sich meist ähnlich: Systeme veralten, Änderungen dauern sehr lange, Entscheidungen werden hinausgezögert, die Betriebsstabilität ist abnehmend, die Kosten steigend.
Scrum geht diese Probleme an und verspricht Besserung durch schnellere Durchlaufzeiten, sofortiges Feedback, kontinuierliche Verbesserung, mehr Kundenfokus, etc. Entsprechend kommt Scrum meist zum Einsatz. Oft in einer erweiterten skalierten Form, wie zum Beispiel beim SAFe.
Innerhalb der Teams, in denen ich Tätig war, fand Scrum zu Beginn wenig Anklang. Mir wurde oft erklärt, die primäre Pflicht des Teams sei die Sicherstellung des Betriebs und diese Aufgabe sei nicht planbar. Zudem könne man kein Commitment für einen Sprint abgeben, da es zu viele Abhängigkeiten im ganzen Unternehmen gebe, die nicht abschätzbar seien. Scrum sei doch nur für Softwareentwickler geeignet.
Der Scrum Guide sagt dazu:
We are humbled to see Scrum being adopted in many domains holding essentially complex work, beyond software product development where Scrum has its roots. As Scrum’s use spreads, developers, researchers, analysts, scientists, and other specialists do the work. We use the word “developers” in Scrum not to exclude, but to simplify. If you get value from Scrum, consider yourself included. (The Scrum Guide, Link )
Scrum habe also seinen Ursprung in der Softwareentwicklung, komme aber heute auch in vielen anderen Bereichen zum Einsatz. Leider werden die Beispiele nicht genauer ausgeführt und es finden sich in der Literatur wenig konkrete Hilfestellungen, auf was bei der Verwendung von Scrum ausserhalb der Softwareentwicklung zu achten ist.
In meinen Mandaten durfte ich feststellen, dass Scrum in der oben geschilderten Ausgangslage durchaus einen grossen Mehrwert bringen kann, wenn es richtig auf die Situation adaptiert wird. Die folgenden Punkte waren dabei sehr hilfreich:
Der Begriff «Entwicklung» in Scrum lässt sich durch den Begriff «planbare Arbeit» ersetzen. So wird auch für Nicht-Entwickler klarer, was in einem Sprint geliefert wird.
Ein Team soll herausfinden, wieviel Nettokapazität übrigbleibt, wenn alle unverzichtbaren Adhoc-Aufgaben erledigt sind. Innerhalb dieser Kapazitäten können dann Arbeitspakete geplant und umgesetzt werden.
Für übrigbleibende unplanbare Betriebsaufgaben können Buffer eingeplant werden. Hier soll das Ziel sein, diese von Sprint zu Sprint zu verkleinern.
Arbeitspakete müssen nicht Softwarecode beinhalten, sondern können alle Artefakte sein, welche dem Kunden einen Mehrwert bringen. Insbesondere sind auch Ergebnisse interessant, welche die Adhoc-Aufgaben, die das Team an der Planung hindern, reduzieren.
Betriebsstabilität ist ein sehr wichtiger Mehrwert für alle Kunden.
Mit der Einführung von Scrum gilt es alte Prozesse anzupassen und Unklarheiten auszuräumen. Agile Teams dürfen auf keinen Fall als Parallelwelt zu klassischen IT-Strukturen etabliert werden. Es bringt nichts, Scrum einzuführen und gleichzeitig ein starres Changemanagement zu betreiben oder Entscheidungen in strengen Hierarchien zu treffen.
Wie siehst Du das? Konntest Du mit Scrum im klassischen IT-Betrieb Erfolge erzielen? Hast Du weitere Tipps für eine erfolgreiche Adaption?
