(Proto-)Kanban für „Admins“

Tim Themann

vor 8 Jahren

Kanban ist neben Scrum im Moment zumindest im Bereich der Softwareentwicklung in aller Munde – und agile Methoden revolutionieren seit einigen Jahren tatsächlich das Management von Softwareprojekten. Was liegt also näher, als diese Methode auch für den IT-Infrastrukturbereich zu adaptieren?

Ich neige ja dazu, viele m. E. im Übermaß propagierte Methoden eher skeptisch zu sehen – sehr schnell erscheint mir etwas unter Anwendung von Maslows Hammer quasi als Allheilmittel positioniert. Tendenziell wirke ich deswegen häufig, als sei ich grundsätzlich erst einmal „dagegen“. Dabei bin ich durchaus oft „dafür“ – insbesondere, wenn eine Methode nicht (wie der erwähnte Hammer) ihrer bloßen Existenz und Beherrschung wegen, sondern zielgerichtet und passend zum Problem ausgewählt wird. Kanban erscheint mir sehr passend zu der Art und Weise, wie IT-Infrastrukturprojekte und IT-Betrieb und ‑Support heutzutage gemanagt werden – und vor allem auch dazu, wie wir diese Bereiche m. E. in Zukunft managen müssen (vgl. hier):

Gerade die IT-Abteilungen von kleinen und mittelständischen Unternehmen leiden schon immer unter dem Konflikt von Projekt und Betrieb: Der Betrieb – Support, Incident Management (ITIL) – ist immer dringend und oft sogar (mindestens „gefühlt“) wichtig. Projekte sind in aller Regel mindestens wichtig (sonst wären sie kaum initiiert worden). Gerade in kleineren IT-Abteilungen muss beides in der Regel durch dieselben Personen bearbeitet werden. Spätestens, wenn ein Betriebsproblem hierarchisch höher angesiedelte Mitarbeiter betrifft, gewinnt die Dringlichkeit – und die Projektarbeit verzögert sich oder kommt (eine ausreichend große Anzahl Support-Tickets vorausgesetzt) praktisch zum Erliegen. Im schlimmsten Fall stoppt das Projekt, das eigentlich die Betriebsaufwände reduzieren soll, aufgrund der hohen Betriebsaufwände.

Viele IT-Abteilungen sind notorisch überlastet – transparent ist das häufig aber nicht: Incidents stapeln sich im Ticket-System, Projekte werden „irgendwie“ anders verwaltet. Der Übergang zwischen beidem ist inzwischen eher fließend (vgl. hier). Viele Projekte sind zudem eher „Projektchen“, die mangels Größe kaum oder gar nicht gemanagt werden und eine dementsprechend geringe Sichtbarkeit haben. Die in den beiden Bereichen anstehende Arbeit ist in ihrer Gesamtheit kaum erkennbar – die Folgen bemerkt man aber in der Anwenderzufriedenheit, dem Projekterfolg und am Ende am Krankstand. Egal, ob man den Fachkräftemangel, den Status der IT als „Costcenter“ (im Gegensatz zum „Profitcenter“), organisatorische Probleme oder fachliche Defizite dafür verantwortlich machen möchte: Ohne Transparenz ist an diesem Zustand wenig zu ändern.

Agile Methoden sind im IT-Infrastrukturbereich meiner Erfahrung nach eher unüblich – können aber mindestens teilweise für diesen Bereich adaptiert werden und hilfreich sein: Beide o. g. Probleme können beispielsweise durch den Einsatz von (Proto‑)Kanban¹ m. E. zumindest sichtbar und damit vor allem auch erst managebar gemacht werden:

Die Kanban-Praktik des Visualisierens des Flusses der Arbeit schafft die notwendige Transparenz, ermöglicht, den „Flow“ aktiv zu steuern. Verwendet man unterschiedlich gefärbte Karten für „Projekt“ und „Betrieb“, wird zudem auch der Konflikt zwischen den beiden Aufgabenbereichen klar sichtbar und damit überhaupt erst managebar.

Stockt der Fluss der projektorientierten Arbeit zu sehr, kann eingegriffen und priorisiert werden – idealerweise durch Führungskräfte, die ihre Prioritätsentscheidungen trotz des Stroms ungeplanter, mehr oder minder dringender Betriebsarbeit durchhalten und verteidigen. Gute Möglichkeiten für diese Priorisierungen sind z. B. …

… morgendliche „Standup-Meetings“² vor der Kanban-Tafel mit dem Team und der Führungskraft. Sind nicht alle Aufgaben auf der Tafel vertreten (s. u.), sollte beispielsweise das Ticket-System hinzugezogen werden, um ein vollständiges Bild zu erhalten. Sinnvollerweise übernimmt man für diese täglichen Meetings das „Timeboxing“ aus Scrum; 10 – 15 Minuten dürften in den meisten Fällen als „hartes“ Zeitlimit angemessen sein.

… Work-in-Progress-Limits – das Begrenzen der Menge der angefangenen Arbeit –, womöglich getrennt nach „Betrieb“ und „Projekt“, können zusätzlich dazu beitragen, das Verhältnis zwischen den beiden Aufgabenbereichen ausgewogen zu gestalten und Überlastung und häufige „Kontextwechsel“ zu vermeiden.

Nähert man sich nun vom Proto-Kanban weiter dem „echten“ Kanban, indem man beispielsweise Kaizen (改善) etabliert, wird die zunehmende, sich jetzt auf der Kanban-Tafel manifestierende Vermischung von „Projekt“ und „Betrieb“ gar zum Vorteil: Ein kontinuierlicher Verbesserungsprozess (KVP), der wirklich übergreifend und integrativ beide Tätigkeitsfelder abdeckt, ist m. E. extrem wertvoll.

Ansätze, IT-Betriebsprozesse mit Kanban zu steuern, gibt es häufiger³ und es existieren zahlreiche Beispiele für an ITIL orientierten Kanban-Tafeln⁴. Wirklich vielversprechend erscheint mir jedoch der Ansatz, die gesamte Arbeit (in kleineren IT-Abteilungen also sowohl Projekt- als auch Betriebsarbeiten) auf einer Kanban-Tafel zu visualisieren – nur so entsteht die ob der Vermischung dringend notwendige Transparenz!

Gibt es zu viele Incidents (i. S. von ITIL), um sinnvoll auf einer physischen Kanban-Tafel Platz zu finden, bietet es sich an, neben der Projektarbeit nur Problems (i. S. von ITIL) auf der Tafel zu visualisieren. Damit dennoch der Überblick über die gesamte Arbeit zumindest zeitweilig existiert, sollte dann beim täglichen „Standup“ ein Blick in das Ticket-System geworfen werden und vielleicht auch zumindest die Anzahl der Incidents auf der Kanban-Tafel vermerkt werden. Dieser gemeinsame Blick ins Ticket-System ist übrigens auch eine sehr gute Gelegenheit, Problems zu identifizieren – das meist interdisziplinäre Team kann das gemeinsam naturgemäß am besten.

Wie kann nun eine solches Board aussehen? Die „klassische“ Sequenz von „To Do“, [„Ready, “] „Doing“, „Done“ erscheint mir für die beiden hier relevanten Aufgabenbereiche ein wenig undifferenziert – eine gemeinsame Abfolge für „Betrieb“ und „Projekt“ zu finden, ist allerdings auch nicht trivial. Viele Phasen der beiden Aufgabenbereiche sind allerdings erstaunlich ähnlich – so müssen beispielsweise sowohl Arbeitspakete eines Projekts als auch Incident-Lösungen getestet, in irgendeiner Form abgenommen und schließlich dokumentiert werden. Möchte man die beiden Bereiche nicht auf zwei unterschiedliche, nebeneinander angeordnete Tafeln verteilen, bietet sich z. B. folgende Tafel an:

Das vollständige Visualisieren der um die Zeit der IT-Mitarbeiter konkurrierenden Arbeit schafft Transparenz und ermöglicht, auch in kleineren Teams den Ausgleich zwischen „Projekt“ und „Betrieb“ zu schaffen. Vor allem aber ermöglicht es flexibles Reagieren auf sich schnell verändernde Anforderungen – eine Agilität, die IT-Infrastrukturen m. E. künftig immer dringender brauchen werden.

Footnotes:

↑ Zu den verschiedenen Kanban-„Reifegraden“ bzw. „Kanban Flight Levels“ und zum Begriff des „Proto-Kanban“ vgl. <http://leankanban.com/patterns-of-kanban-maturity/> (06.03.2017), archiviert am 06.03.2017 unter <http://www.webcitation.org/6olYccq0y>.
↑ Ähnlich dem „Daily Scrum“.
↑ Vgl. z. B. <http://www.cio.de/a/neue-methode-aus-kanban-und-itil-wird-kanbil,2891953> (08.03.2016). Ein Kofferwort, das u. a. aus einem Akronym gebildet wurde, kann m. E. nur in der IT geboren worden sein.
↑ Vgl. z. B. <https://leankit.com/blog/2016/12/itsm-kanban-board-templates/> (08.03.2017).