Warum mir Scrum im IT-Infrastruktur-Bereich oft als wenig sinnvoll erscheint

Tim Themann

vor 5 Jahren

„Wir machen jetzt [auch¹] Scrum.“ ist ein Satz, den (sicher nicht nur) ich in den letzten Jahren sehr häufig gehört habe – inzwischen auch außerhalb des Softwareentwicklungs-Bereichs im traditionell methodisch eher konservativen IT-Infrastruktur-Bereich². Praktisch erlebt man dabei Scrum häufig eher als MeToode (Antrieb: „Alle machen das!“) denn als Methode und oft gleichsam mutiert durch mehr oder minder massives „Methoden-Frankensteining“ (Ansatz: „Was nicht passt, wird passend gemacht!“). Letzteres hat m. E. einen sehr einfachen Grund: Scrum passt einfach häufig nicht zur Arbeitsweise der IT-Infrastruktur-Abteilungen:

Scrum ist ein Framework für die Produktentwicklung – „Scrum is a framework for developing, delivering, and sustaining complex products.“³ Nun könnte man einwenden, dass das genau das ist, was im IT-Infrastruktur-Bereich getan wird: (zumeist Fremd‑)Produkte zu einem neuen Produkt („Service“) kombinieren, dieses Produkt weiterzuentwickeln und zu erhalten. Auf einem entsprechend hohen Abstraktionsniveau ist das sicher nicht falsch – man verdrängt dabei jedoch, dass ein extrem großer Teil der täglichen Arbeit im IT-Infrastruktur-Bereich aus reaktivem Support besteht, der sich nicht in die Kadenz eines Scrum-Sprints pressen lässt: Das Sprint-Ziel ist nun einmal zu Beginn des Sprints fixiert und kann im laufenden Sprint nicht (auch nicht aufgrund eines „brennenden“ Support-Falls) modifiziert werden. Gerade in kleineren IT-Abteilungen ist die personelle Trennung von Betrieb und Projekt oft unmöglich – und selbst in großen Organisationen, in denen eine unmittelbare personelle Trennung möglich ist, verschwimmt diese spätestens im Eskalations-Fall. Stülpte man Scrum jetzt einfach über diese Realität, ein erheblicher Teil der eigentlichen Arbeit fiele aus dem Prozess heraus.

Nun könnte man auf die Idee kommen, diesen Konflikt zu lösen, indem man die zur Verfügung stehende Arbeitszeit einfach mehr oder minder klar aufteilt. „Teilzeit-Scrum“ i. S. von Scrum-Team-Mitgliedern, die beispielsweise nur die Hälfte des Arbeitstages oder nur an bestimmten Wochentagen im Team mitarbeiten und in der übrigen Zeit anderen Aufgaben (in diesem Fall: reaktivem Support) nachgehen, ist allerdings meist problematisch⁴: Nicht nur, dass eine begrenzte Verfügbarkeit per se ein Impediment darstellt⁵, für den Einzelnen und das Team ist auch der inhärente Widerspruch zu den Scrum-Werten focus und commitment nur schwer handhabbar – gerade, wenn der „Zweitjob“ aus dringenden Support-Tätigkeiten besteht, deren jeweiliger Zeitbedarf vorab meist unklar ist. Sind die für Scrum reservierten Zeitanteile der Team-Mitglieder nun womöglich auch noch sehr unterschiedlich, dürften zudem negative Implikationen für die Teamentwicklung zu erwarten sein. Der ewig schwelende Konflikt zwischen Betrieb und Projekt wird also auf diesem Weg meist nicht besser, sondern eher noch schmerzhafter. Kurz: Dieser Lösungsansatz scheint mir eher ein Fall von wenig hilfreichem Methoden-Frankensteining (vgl. hier) zu sein – frei nach dem Motto „Was nicht passt, wird passend gemacht.“

Der Wunsch, auch im IT-Infrastruktur-Bereich „agiler zu werden“ – gemeint ist hier vermutlich meist „schneller, adaptiver und reaktionsfähiger“ –, ist vollkommen nachvollziehbar: Die zunehmende Geschwindigkeit und ebenso zunehmende Beschleunigung der technischen Entwicklung und die sich ähnlich entwickelnde Änderungsgeschwindigkeit der Anforderungen zwingen geradezu dazu. Als IT-Infrastruktur-Abteilung quasi „am Ende der Nahrungskette“ den kontinuierlichen Strom von Produkten (und Updates) zunehmend agiler Softwarehersteller gleichsam zu „verdauen“, verlangt neue – vermutlich ebenso agile – Ansätze (vgl. hier). Das heißt aber nicht automatisch, dass man Scrum einführen muss – und schon gar nicht, „weil es alle machen“. Sucht man nun unbedingt die Methode, um „agiler zu werden“⁶, erscheint mir Kanban in diesem Umfeld deutlich geeigneter: Kanban ermöglicht nicht nur das Mischen von reaktiven Support-Tätigkeiten und Projektarbeit, sondern macht zudem den inhärenten Konflikt sicht- und damit handhabbar (vgl. hier und hier) – und das Kanban-Prinzip „Beginne mit dem, was Du gerade tust“ i. S. einer evolutionären Verbesserung dürfte der Realität einer ja häufig geradezu „getriebenen“ IT-Abteilung viel angemessener als das radikale „Überstülpen“ noch einer neuen MeToode.

Footnotes:

↑ Das „auch“ kommt sicherlich eher weniger von Entscheidern denn von den Ausführenden.
↑ Mein (oft nur vermeintlich bodenständiger) Beritt, ich beschäftige mich hauptsächlich mit der Implementierung der infrastrukturellen Basis der IT.
↑ Schwaber, Ken und Sutherland, Jeff: The Scrum Guide. The Definitive Guide to Scrum: The Rules of the Game. 2017. S. 3. Download unter <https://www.scrumguides.org> (31.10.2019).
↑ Widerspricht aber übrigens m. E. nicht unmittelbar dem Scrum Guide.
↑ Vgl. bspw. die Diskussion unter <https://www.scrum.org/forum/scrum-forum/5304/partially-allocated-team-members> (31.10.2019), archiviert am 31.10.2019 unter <https://web.archive.org/web/20191031161602if_/https://www.scrum.org/forum/scrum-forum/5304/partially-allocated-team-members>.
↑ Dafür ist m. E. nicht per se eine definierte Methode notwendig und womöglich nicht einmal hinreichend – wichtiger dürfte womöglich das Schaffen eines entsprechenden Umfelds sein (vgl. hier).