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

„Wir machen jetzt [auch​¹] Scrum.“ ist ein Satz, den (sicher nicht nur) ich in den letz­ten Jah­ren sehr häu­fig gehört habe – inzwi­schen auch außer­halb des Soft­ware­ent­wick­lungs-Bereichs im tra­di­tio­nell metho­disch eher kon­ser­va­ti­ven IT-Infra­struk­tur-Bereich​². Prak­tisch erlebt man dabei Scrum häu­fig eher als MeToode (Antrieb: „Alle machen das!“) denn als Metho­de und oft gleich­sam mutiert durch mehr oder min­der mas­si­ves „Metho­den-Fran­ken­stei­ning“ (Ansatz: „Was nicht passt, wird pas­send gemacht!“). Letz­te­res hat m. E. einen sehr ein­fa­chen Grund: Scrum passt ein­fach häu­fig nicht zur Arbeits­wei­se der IT-Infrastruktur-Abteilungen:

• Scrum ist ein Frame­work für die Pro­dukt­ent­wick­lung – „Scrum is a frame­work for deve­lo­ping, deli­ve­ring, and sus­tai­ning com­plex pro­ducts.“​³ Nun könn­te man ein­wen­den, dass das genau das ist, was im IT-Infra­struk­tur-Bereich getan wird: (zumeist Fremd‑)​Produkte zu einem neu­en Pro­dukt („Ser­vice“) kom­bi­nie­ren, die­ses Pro­dukt wei­ter­zu­ent­wi­ckeln und zu erhal­ten. Auf einem ent­spre­chend hohen Abs­trak­ti­ons­ni­veau ist das sicher nicht falsch – man ver­drängt dabei jedoch, dass ein extrem gro­ßer Teil der täg­li­chen Arbeit im IT-Infra­struk­tur-Bereich aus reak­ti­vem Sup­port besteht, der sich nicht in die Kadenz eines Scrum-Sprints pres­sen lässt: Das Sprint-Ziel ist nun ein­mal zu Beginn des Sprints fixiert und kann im lau­fen­den Sprint nicht (auch nicht auf­grund eines „bren­nen­den“ Sup­port-Falls) modi­fi­ziert wer­den. Gera­de in klei­ne­ren IT-Abtei­lun­gen ist die per­so­nel­le Tren­nung von Betrieb und Pro­jekt oft unmög­lich – und selbst in gro­ßen Orga­ni­sa­tio­nen, in denen eine unmit­tel­ba­re per­so­nel­le Tren­nung mög­lich ist, ver­schwimmt die­se spä­tes­tens im Eska­la­ti­ons-Fall. Stülp­te man Scrum jetzt ein­fach über die­se Rea­li­tät, ein erheb­li­cher Teil der eigent­li­chen Arbeit fie­le aus dem Pro­zess heraus.

• Nun könn­te man auf die Idee kom­men, die­sen Kon­flikt zu lösen, indem man die zur Ver­fü­gung ste­hen­de Arbeits­zeit ein­fach mehr oder min­der klar auf­teilt. „Teil­zeit-Scrum“ i. S. von Scrum-Team-Mit­glie­dern, die bei­spiels­wei­se nur die Hälf­te des Arbeits­ta­ges oder nur an bestimm­ten Wochen­ta­gen im Team mit­ar­bei­ten und in der übri­gen Zeit ande­ren Auf­ga­ben (in die­sem Fall: reak­ti­vem Sup­port) nach­ge­hen, ist aller­dings meist problematisch​⁴: Nicht nur, dass eine begrenz­te Ver­füg­bar­keit per se ein Impe­di­ment darstellt​⁵, für den Ein­zel­nen und das Team ist auch der inhä­ren­te Wider­spruch zu den Scrum-Wer­ten focus und com­mit­ment nur schwer hand­hab­bar – gera­de, wenn der „Zweit­job“ aus drin­gen­den Sup­port-Tätig­kei­ten besteht, deren jewei­li­ger Zeit­be­darf vor­ab meist unklar ist. Sind die für Scrum reser­vier­ten Zeit­an­tei­le der Team-Mit­glie­der nun womög­lich auch noch sehr unter­schied­lich, dürf­ten zudem nega­ti­ve Impli­ka­tio­nen für die Team­ent­wick­lung zu erwar­ten sein. Der ewig schwe­len­de Kon­flikt zwi­schen Betrieb und Pro­jekt wird also auf die­sem Weg meist nicht bes­ser, son­dern eher noch schmerz­haf­ter. Kurz: Die­ser Lösungs­an­satz scheint mir eher ein Fall von wenig hilf­rei­chem Metho­den-Fran­ken­stei­ning (vgl. hier) zu sein – frei nach dem Mot­to „Was nicht passt, wird pas­send gemacht.“

Der Wunsch, auch im IT-Infra­struk­tur-Bereich „agi­ler zu wer­den“ – gemeint ist hier ver­mut­lich meist „schnel­ler, adap­ti­ver und reak­ti­ons­fä­hi­ger“ –, ist voll­kom­men nach­voll­zieh­bar: Die zuneh­men­de Geschwin­dig­keit und eben­so zuneh­men­de Beschleu­ni­gung der tech­ni­schen Ent­wick­lung und die sich ähn­lich ent­wi­ckeln­de Ände­rungs­ge­schwin­dig­keit der Anfor­de­run­gen zwin­gen gera­de­zu dazu. Als IT-Infra­struk­tur-Abtei­lung qua­si „am Ende der Nah­rungs­ket­te“ den kon­ti­nu­ier­li­chen Strom von Pro­duk­ten (und Updates) zuneh­mend agi­ler Soft­ware­her­stel­ler gleich­sam zu „ver­dau­en“, ver­langt neue – ver­mut­lich eben­so agi­le – Ansät­ze (vgl. hier). Das heißt aber nicht auto­ma­tisch, dass man Scrum ein­füh­ren muss – und schon gar nicht, „weil es alle machen“. Sucht man nun unbe­dingt die Metho­de, um „agi­ler zu wer­den“​⁶, erscheint mir Kan­ban in die­sem Umfeld deut­lich geeig­ne­ter: Kan­ban ermög­licht nicht nur das Mischen von reak­ti­ven Sup­port-Tätig­kei­ten und Pro­jekt­ar­beit, son­dern macht zudem den inhä­ren­ten Kon­flikt sicht- und damit hand­hab­bar (vgl. hier und hier) – und das Kan­ban-Prin­zip „Begin­ne mit dem, was Du gera­de tust“ i. S. einer evo­lu­tio­nä­ren Ver­bes­se­rung dürf­te der Rea­li­tät einer ja häu­fig gera­de­zu „getrie­be­nen“ IT-Abtei­lung viel ange­mes­se­ner als das radi­ka­le „Über­stül­pen“ noch einer neu­en MeToode.