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

„Wir machen jetzt [auch​1] 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​2. 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-Infra­struk­tur-Abtei­lun­gen:

  • Projekt – Betrieb – SupportScrum ist ein Frame­work für die Pro­dukt­ent­wick­lung – „Scrum is a frame­work for deve­lo­ping, deli­vering, and sustai­ning com­plex pro­duc­ts.“​3 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 her­aus.

Scrum – Projekt und Betrieb im Konflikt

  • 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​4: Nicht nur, dass eine begrenz­te Ver­füg­bar­keit per se ein Impe­di­ment darstellt​5, 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 Teament­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“​6, 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.

Kanban – Projektarbeit und Betrieb (Support) mischen

Fuß­no­ten:

  1.  Das „auch“ kommt sicher­lich eher weni­ger von Ent­schei­dern denn von den Aus­füh­ren­den.
  2.  Mein (oft nur ver­meint­lich boden­stän­di­ger) Beritt, ich beschäf­ti­ge mich haupt­säch­lich mit der Imple­men­tie­rung der infra­struk­tu­rel­len Basis der IT.
  3.  Schwa­ber, Ken und Suther­land, Jeff: The Scrum Gui­de. The Defi­ni­ti­ve Gui­de to Scrum: The Rules of the Game. 2017. S. 3. Down­load unter <https://​www​.scr​um​gui​des​.org> (31.10.2019).
  4.  Wider­spricht aber übri­gens m. E. nicht unmit­tel­bar dem Scrum Gui­de.
  5.  Vgl. bspw. die Dis­kus­si­on unter <https://​www​.scrum​.org/​f​o​r​u​m​/​s​c​r​u​m​-​f​o​r​u​m​/​5​3​0​4​/​p​a​r​t​i​a​l​l​y​-​a​l​l​o​c​a​t​e​d​-​t​e​am-members> (31.10.2019), archi­viert am 31.10.2019 unter <https://web.archive.org/web/20191031161602if_/https://www.scrum.org/forum/scrum-forum/5304/partially-allocated-team-members>.
  6.  Dafür ist m. E. nicht per se eine defi­nier­te Metho­de not­wen­dig und womög­lich nicht ein­mal hin­rei­chend – wich­ti­ger dürf­te womög­lich das Schaf­fen eines ent­spre­chen­den Umfelds sein (vgl. hier).

2 Replies to “Warum mir Scrum im IT-Infrastruktur-Bereich oft als wenig sinnvoll erscheint”

    • Guten Abend,

      ich muss lei­der sagen: In der von Dir ver­link­ten stich­wort­ar­ti­gen Form kann ich die jewei­li­gen Grün­de bzw. Nach­tei­le größ­ten­teils gedank­lich nicht wirk­lich nach­voll­zie­hen, da fehlt mir zu viel Kon­text bzw. Argu­men­ta­ti­on oder Beleg. Im Fal­le von Kan­ban bin ich mir nicht sicher, ob Du nicht das klas­si­sche „Pro­duk­ti­ons-Kan­ban“ und das in der IT ver­brei­te­te „Soft­ware­ent­wick­lungs-Kan­ban“ durch­ein­an­der wirfst – aber auch das kann ich auf­grund der Stich­wort­ar­tig­keit lei­der nicht wirk­lich beur­tei­len. Ich ver­mu­te, mir fehlt da ein­fach die „Ton­spur“ zur Visua­li­sie­rung. Ich muss aller­dings an die­ser Stel­le auch anmer­ken, dass Mind­maps wirk­lich nicht mein liebs­tes Werk­zeug sind – vgl. „Mind­maps – trotz Kar­te im eige­nen Hirn ver­irrt?“.

      Vie­le Grü­ße aus dem ICE

      Tim

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*