Viele gerade kleinere IT-Abteilungen haben meiner Erfahrung nach große Schwierigkeiten, die (meist knappe) zur Verfügung stehende Zeit zwischen zwei Arten von Arbeit aufzuteilen: reaktivem Support und (gleichsam proaktiver) Projektarbeit – Betrieb und Projekt. Eine klare personelle Trennung zwischen diesen Bereichen ist meist spätestens im Falle von Eskalationen in den 2nd Level kaum möglich – dafür steht in mittelständischen IT-Abteilungen in aller Regel schlicht nicht genügend ausreichend qualifiziertes Personal zur Verfügung. Die Menschen müssen sich bzw. ihre Zeit also zwangsläufig aufteilen und fast immer gewinnt dann (vermeintliche oder echte) Dringlichkeit gegenüber Wichtigkeit – meist also Betrieb (bzw. Störung) gegenüber Projektarbeit.
Ich empfehle IT-Infrastruktur-Abteilungen inzwischen oft und gern die Einführung von (zumindest Proto‑)Kanban (vgl. hier) – vor allem, weil genau dieser Konflikt am Kanban-Board sicht- und damit managebar wird: Die Kanban-Praktik, durch Visualisieren alle Arbeit (in diesem Fall also: sowohl „Tickets“ aus dem Betrieb als auch Arbeitspakete aus den Projekten) sichtbar zu machen, fördert das Dilemma zutage, führt vor Augen, wie sehr sich die IT-Mitarbeiter in der täglichen Arbeit zerreißen müssen – und zeigt in aller Regel auch, an welchen Punkten klare Entscheidungen und ebenso klare Zusagen fehlen. Die hohe Sichtbarkeit aller Arbeit sorgt also nicht nur dafür, dass den Ausführenden „nichts durchrutscht“, sondern auch dafür, dass die zuständigen Führungskräfte sehen können, wo beispielsweise Entscheidungen gefragt sind. Management by Exception setzt nun einmal voraus, dass die Exception auch erkannt wird – und genau dafür erscheint mir ein für alle sichtbares Kanban-Board als sehr effektiv.
So weit, so gut – bis hierher folgen mir in aller Regel die meisten Menschen, mit denen ich darüber spreche. Im weiteren Verlauf beobachte ich allerdings häufig zwei Gedankenschritte, die sehr geeignet sind, den m. E. guten Ansatz nachhaltig zu torpedieren:
- ITler implementieren gern IT-Systeme – sonst wären sie nicht in der IT gelandet. Ein physisches Kanban-Board mit Zetteln in den Flur zu hängen, widerstrebt gerade IT-Infrastruktur-Spezialisten (anders als offenbar Softwareentwicklern) meiner Erfahrung nach extrem. Nun gibt es sicherlich gut einsetzbare Software-Lösungen, mit denen sich die Funktionalität eines Kanban-Boards abbilden lässt – die unbequeme Omnipräsenz eines physischen Boards1 erreicht man so jedoch nicht2. Anders formuliert: Ein in Software „gegossenes“ Board kann man viel einfacher ignorieren – das klappt mit dem jeweils eingesetzten Ticket-Tool meist ja schon ganz gut.
- Ist erst einmal die Entscheidung gefallen, das Board in Form einer Software-Lösung umzusetzen, ist der nächste m. E. fatale Gedankenschritt nicht weit: In praktisch jeder etwas größeren IT-Organisation existiert ja bereits ein System, das „Tickets“3 managt. Was liegt also näher, als dieses System zweckzuentfremden – vor allem, weil die eine Hälfte der gesamten Arbeit in diesem System ja bereits enthalten ist? Projektarbeit wird also auf einmal mühsam in ein System gepresst, dessen Workflow und dessen weitere Funktionalitäten extrem spezifisch zugeschnitten sind auf eine völlig andere Form von Arbeit – Betrieb, i. d. R. Incidents und Requests. Nun sind weder User Interface noch die Reporting-Möglichkeiten typischer Helpdesk-Lösungen geeignet, Projektarbeit zu verwalten; in aller Regel gibt es auch keine sinnvolle Möglichkeit, die gesamte Arbeit auf einmal sichtbar darzustellen – von der Implementierung von WIP-Limits (vgl. hier und hier) ganz zu schweigen. Von dem löblichen Ansatz, wirklich alle Arbeit und damit den andauernden Konflikt zwischen Betriebs- und Projektarbeit ans Licht zu zerren, ist so kaum noch etwas übrig – und in einen klassischen Support-Workflow gezwungen gerät die („nur“ wichtige) Projektarbeit ob der (eigentlich immer dringlichen) betrieblichen Probleme meist endgültig ins Hintertreffen.
Von Intranets sagt man ja oft scherzhaft (und erfreulich häufig unberechtigt), sie seien der Ort, an den Informationen zum Sterben gehen. Stopft man Projektarbeit mehr oder minder brutal in ein zweckentfremdetes Ticket-System, kann man sich m. E. fast sicher sein: Eben dieses Ticket-System ist genau der Ort, an den die Arbeitspakete zum Sterben gehen!
Fußnoten:
- ↑ Gesetzt den Fall, man hat es nicht mit einem verteilten Team zu tun.
- ↑ Mehr zu den Vorteilen eines „haptischen“ Boards findet sich bspw. in Florian Eisenbergs Blog unter <https://www.kanbwana.de/2018/06/26/warum-haptische-boards-so-cool-sind/> (21.10.2019).
- ↑ Und nicht anders werden die Arbeitseinheiten in einem Kanban-System ja oft (m. E. inhaltlich verfälschend) genannt.
Schöner Artikel, allerdings steht und fällt die Lösung, mit dem Kanban ALLE Arbeiten sichtbar zu machen, mit der Akribie, dieses permanent auf aktuellen Stand zu halten. Gerade die (wichtigsten)Geschehnisse und daraus resultierende Einfluss-Faktoren des täglichen Incidents Managements auf das Kanban zu bringen bedarf eines nicht unerheblichen Aufwandes. Und hier kann meist man nicht nur 1 Person für definieren, sondern es ist ein „common approach“ aller in der IT Abteilung arbeitenden. Zudem bekommt man durch eine SW-Lösung des Boards die bessere Möglichkeit, Veränderungen automatisiert mitzubekommen, wer sie veranlasst hat und vllt sogar warum. Ganz zu schweigen bei dem (nachvollziehbar) steigenden Wunsch der Mitarbeiter nach Tagen im HomeOffice. Bei physikalischem Einsatz des Boards ist das m.E. schwer realisierbar.
In der Tat: Ein physisches Board findet seine Grenzen, sobald das Team in größerem Umfang aus der Ferne arbeitet – Home Office und dislozierte Teams sind m. E. hier die wohl validesten Gründe für den Einsatz von Softwarelösungen. Die Problematik der notwendigen „Akribie“ wird häufig gelöst, indem (explizierte!) Regeln dafür geschaffen werden, was nicht auf dem Board landet – z. B. Passwort-Rücksetzungen, Entsperren von Accounts o. ä. Wichtig dabei ist aber sicherlich, die Menge dieser (dann ja meist nur noch „pauschal“ visualisierten) Arbeiten dennoch einigermaßen quantifizieren zu können. Im Falle von Software-Lösungen kann man übrigens nötigenfalls auch das Ticket-System mit der Board-Software synchronisieren – und spätestens im Ticket-System wäre die „Akribie“ ja sowieso zumindest wünschenswert wenn nicht gar notwendig!