(Proto-)Kanban für „Admins“

Kan­ban ist neben Scrum im Moment zumin­dest im Bereich der Soft­ware­ent­wick­lung in aller Munde – und agile Metho­den revo­lu­tio­nie­ren seit eini­gen Jah­ren tat­säch­lich das Manage­ment von Soft­ware­pro­jek­ten. Was liegt also näher, als diese Metho­de auch für den IT-Infra­struk­tur­be­reich zu adaptieren?

Ich neige ja dazu, viele m. E. im Über­maß pro­pa­gier­te Metho­den eher skep­tisch zu sehen – sehr schnell erscheint mir etwas unter Anwen­dung von Maslows Ham­mer quasi als All­heil­mit­tel posi­tio­niert. Ten­den­zi­ell wirke ich des­we­gen häu­fig, als sei ich grund­sätz­lich erst ein­mal „dage­gen“. Dabei bin ich durch­aus oft „dafür“ – ins­be­son­de­re, wenn eine Metho­de nicht (wie der erwähn­te Ham­mer) ihrer blo­ßen Exis­tenz und Beherr­schung wegen, son­dern ziel­ge­rich­tet und pas­send zum Pro­blem aus­ge­wählt wird. Kan­ban erscheint mir sehr pas­send zu der Art und Weise, wie IT-Infra­struk­tur­pro­jek­te und IT-Betrieb und -Sup­port heut­zu­ta­ge gema­nagt wer­den – und vor allem auch dazu, wie wir diese Berei­che m. E. in Zukunft mana­gen müs­sen (vgl. hier):

  • Gera­de die IT-Abtei­lun­gen von klei­nen und mit­tel­stän­di­schen Unter­neh­men lei­den schon immer unter dem Kon­flikt von Pro­jekt und Betrieb: Der Betrieb – Sup­port, Inci­dent Manage­ment (ITIL) – ist immer drin­gend und oft sogar (min­des­tens „gefühlt“) wich­tig. Pro­jek­te sind in aller Regel min­des­tens wich­tig (sonst wären sie kaum initi­iert wor­den). Gera­de in klei­ne­ren IT-Abtei­lun­gen muss bei­des in der Regel durch die­sel­ben Per­so­nen bear­bei­tet wer­den. Spä­tes­tens, wenn ein Betriebs­pro­blem hier­ar­chisch höher ange­sie­del­te Mit­ar­bei­ter betrifft, gewinnt die Dring­lich­keit – und die Pro­jekt­ar­beit ver­zö­gert sich oder kommt (eine aus­rei­chend große Anzahl Sup­port-Tickets vor­aus­ge­setzt) prak­tisch zum Erlie­gen. Im schlimms­ten Fall stoppt das Pro­jekt, das eigent­lich die Betriebs­auf­wän­de redu­zie­ren soll, auf­grund der hohen Betriebsaufwände.
  • Viele IT-Abtei­lun­gen sind noto­risch über­las­tet – trans­pa­rent ist das häu­fig aber nicht: Inci­dents sta­peln sich im Ticket-Sys­tem, Pro­jek­te wer­den „irgend­wie“ anders ver­wal­tet. Der Über­gang zwi­schen bei­dem ist inzwi­schen eher flie­ßend (vgl. hier). Viele Pro­jek­te sind zudem eher „Pro­jekt­chen“, die man­gels Größe kaum oder gar nicht gema­nagt wer­den und eine dem­entspre­chend gerin­ge Sicht­bar­keit haben. Die in den bei­den Berei­chen anste­hen­de Arbeit ist in ihrer Gesamt­heit kaum erkenn­bar – die Fol­gen bemerkt man aber in der Anwen­der­zu­frie­den­heit, dem Pro­jekt­er­folg und am Ende am Krank­stand. Egal, ob man den Fach­kräf­te­man­gel, den Sta­tus der IT als „Cost­cen­ter“ (im Gegen­satz zum „Pro­fit­cen­ter“), orga­ni­sa­to­ri­sche Pro­ble­me oder fach­li­che Defi­zi­te dafür ver­ant­wort­lich machen möch­te: Ohne Trans­pa­renz ist an die­sem Zustand wenig zu ändern.

Kanban-Karte IT-InfrastrukturAgile Metho­den sind im IT-Infra­struk­tur­be­reich mei­ner Erfah­rung nach eher unüb­lich – kön­nen aber min­des­tens teil­wei­se für die­sen Bereich adap­tiert wer­den und hilf­reich sein: Beide o. g. Pro­ble­me kön­nen bei­spiels­wei­se durch den Ein­satz von (Proto‑)​Kanban​1 m. E. zumin­dest sicht­bar und damit vor allem auch erst mana­ge­bar gemacht werden:

  • Die Kan­ban-Prak­tik des Visua­li­sie­rens des Flus­ses der Arbeit schafft die not­wen­di­ge Trans­pa­renz, ermög­licht, den „Flow“ aktiv zu steu­ern. Ver­wen­det man unter­schied­lich gefärb­te Kar­ten für „Pro­jekt“ und „Betrieb“, wird zudem auch der Kon­flikt zwi­schen den bei­den Auf­ga­ben­be­rei­chen klar sicht­bar und damit über­haupt erst mana­ge­bar.

Stockt der Fluss der pro­jekt­ori­en­tier­ten Arbeit zu sehr, kann ein­ge­grif­fen und prio­ri­siert wer­den – idea­ler­wei­se durch Füh­rungs­kräf­te, die ihre Prio­ri­täts­ent­schei­dun­gen trotz des Stroms unge­plan­ter, mehr oder min­der drin­gen­der Betriebs­ar­beit durch­hal­ten und ver­tei­di­gen. Gute Mög­lich­kei­ten für diese Prio­ri­sie­run­gen sind z. B. …

  • mor­gend­li­che „Stan­dup-Mee­tings“2 vor der Kan­ban-Tafel mit dem Team und der Füh­rungs­kraft. Sind nicht alle Auf­ga­ben auf der Tafel ver­tre­ten (s. u.), soll­te bei­spiels­wei­se das Ticket-Sys­tem hin­zu­ge­zo­gen wer­den, um ein voll­stän­di­ges Bild zu erhal­ten. Sinn­vol­ler­wei­se über­nimmt man für diese täg­li­chen Mee­tings das „Time­bo­xing“ aus Scrum; 10 – 15 Minu­ten dürf­ten in den meis­ten Fäl­len als „har­tes“ Zeit­li­mit ange­mes­sen sein.
  • … Work-in-Pro­gress-Limits – das Begren­zen der Menge der ange­fan­ge­nen Arbeit –, womög­lich getrennt nach „Betrieb“ und „Pro­jekt“, kön­nen zusätz­lich dazu bei­tra­gen, das Ver­hält­nis zwi­schen den bei­den Auf­ga­ben­be­rei­chen aus­ge­wo­gen zu gestal­ten und Über­las­tung und häu­fi­ge „Kon­text­wech­sel“ zu vermeiden.

Nähert man sich nun vom Proto-Kan­ban wei­ter dem „ech­ten“ Kan­ban, indem man bei­spiels­wei­se Kai­zen (改善) eta­bliert, wird die zuneh­men­de, sich jetzt auf der Kan­ban-Tafel mani­fes­tie­ren­de Ver­mi­schung von „Pro­jekt“ und „Betrieb“ gar zum Vor­teil: Ein kon­ti­nu­ier­li­cher Ver­bes­se­rungs­pro­zess (KVP), der wirk­lich über­grei­fend und inte­gra­tiv beide Tätig­keits­fel­der abdeckt, ist m. E. extrem wertvoll.

Ansät­ze, IT-Betriebs­pro­zes­se mit Kan­ban zu steu­ern, gibt es häufiger​3 und es exis­tie­ren zahl­rei­che Bei­spie­le für an ITIL ori­en­tier­ten Kan­ban-Tafeln​4. Wirk­lich viel­ver­spre­chend erscheint mir jedoch der Ansatz, die gesam­te Arbeit (in klei­ne­ren IT-Abtei­lun­gen also sowohl Pro­jekt- als auch Betriebs­ar­bei­ten) auf einer Kan­ban-Tafel zu visua­li­sie­ren – nur so ent­steht die ob der Ver­mi­schung drin­gend not­wen­di­ge Transparenz!

Gibt es zu viele Inci­dents (i. S. von ITIL), um sinn­voll auf einer phy­si­schen Kan­ban-Tafel Platz zu fin­den, bie­tet es sich an, neben der Pro­jekt­ar­beit nur Pro­blems (i. S. von ITIL) auf der Tafel zu visua­li­sie­ren. Damit den­noch der Über­blick über die gesam­te Arbeit zumin­dest zeit­wei­lig exis­tiert, soll­te dann beim täg­li­chen „Stan­dup“ ein Blick in das Ticket-Sys­tem gewor­fen wer­den und viel­leicht auch zumin­dest die Anzahl der Inci­dents auf der Kan­ban-Tafel ver­merkt wer­den. Die­ser gemein­sa­me Blick ins Ticket-Sys­tem ist übri­gens auch eine sehr gute Gele­gen­heit, Pro­blems zu iden­ti­fi­zie­ren – das meist inter­dis­zi­pli­nä­re Team kann das gemein­sam natur­ge­mäß am besten.

Wie kann nun eine sol­ches Board aus­se­hen? Die „klas­si­sche“ Sequenz von „To Do“, [„Ready, “] „Doing“, „Done“ erscheint mir für die bei­den hier rele­van­ten Auf­ga­ben­be­rei­che ein wenig undif­fe­ren­ziert – eine gemein­sa­me Abfol­ge für „Betrieb“ und „Pro­jekt“ zu fin­den, ist aller­dings auch nicht tri­vi­al. Viele Pha­sen der bei­den Auf­ga­ben­be­rei­che sind aller­dings erstaun­lich ähn­lich – so müs­sen bei­spiels­wei­se sowohl Arbeits­pa­ke­te eines Pro­jekts als auch Inci­dent-Lösun­gen getes­tet, in irgend­ei­ner Form abge­nom­men und schließ­lich doku­men­tiert wer­den. Möch­te man die bei­den Berei­che nicht auf zwei unter­schied­li­che, neben­ein­an­der ange­ord­ne­te Tafeln ver­tei­len, bie­tet sich z. B. fol­gen­de Tafel an:

IT-Infrastruktur-Kanban – Betrieb – Support – Projekt

Das voll­stän­di­ge Visua­li­sie­ren der um die Zeit der IT-Mit­ar­bei­ter kon­kur­rie­ren­den Arbeit schafft Trans­pa­renz und ermög­licht, auch in klei­ne­ren Teams den Aus­gleich zwi­schen „Pro­jekt“ und „Betrieb“ zu schaf­fen. Vor allem aber ermög­licht es fle­xi­bles Reagie­ren auf sich schnell ver­än­dern­de Anfor­de­run­gen – eine Agi­li­tät, die IT-Infra­struk­tu­ren m. E. künf­tig immer drin­gen­der brau­chen werden.

One Reply to “(Proto-)Kanban für „Admins“”

  1. Inter­es­san­ter Arti­kel. Mit oder teil­wei­se nach ITIL arbei­ten ja auch schon so man­che klei­ne­re IT Abtei­lung. Eine Kan­ban Tafel habe ich dort aber noch nie im Ein­satz gese­hen. Span­nen­der Ansatz!

Schreibe einen Kommentar

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

*