Was bedeuten Scrum und Kanban für den IT Betrieb?

Was bedeuten Scrum und Kanban für den IT Betrieb?

In den letzten Tagen durfte ich meinen Trainerkollegen Jan Fischbach bei Workshops für den IT Betrieb begleiten. Da bis zu 30 Teilnehmer für die Tagesveranstaltungen geplant waren, hatten wir alle Hände voll zu tun, denn die Teilnehmer sollten Kanban und Scrum-Prozesse erfahren und erkennen, welche Mehrwert die Anwendung haben kann. Erfahren heißt nicht zuhören, sondern ausprobieren. Mit dem von Jan entwickelten Ubongo Flow Game – abgeleitet aus dem Lego Flow Game – lernten die Teilnehmer spielerisch die Vorteile und Chancen von Kanban-Systemen und agilem Arbeiten kennen.

Allerdings ging es uns nicht darum, die Menschen aus dem Betrieb davon zu überzeugen, dass agiles Vorgehen immer das beste ist – denn inwieweit dies funktioniert, hängt vom Umfeld ab, in dem man selbst arbeitet. Wenn es um besseren Durchfluss der zu bearbeitenden Aufgaben geht, sind Kanban für den Betrieb und Scrum für die Entwicklung die Ansätze, die diesen oft am besten unterstützen. Und besserer Durchfluss bedeutet, dass der Kunde schneller Lösungen bekommt, die er benötigt.

Generell hängt der Ansatz von agilen oder stärker vorab geplanten Vorgehensweisen von der Unsicherheit der Aufgabe ab. Für Projekte hilft der Diamond Approach von Shenhar/Dvir, die Unsicherheit festzustellen und zu entscheiden, wie viel Agilität ein Projekt benötigt und wann es sinnvoller ist, den Planungsprozess zu Beginn umfangreicher zu gestalten. Mit zunehmender Unsicherheit werden agile Ansätze wichtiger und wertvoller. Je klarer die Aufgabe für mich ist und je mehr Wissen in meiner Organisation vorliegt, umso weniger Effekt haben agile Vorgehensweisen.

Für den Betrieb kommt es sehr stark darauf an, wie die Change Prozesse gestaltet sind. Der noch junge Ansatz DevOps als Konzept zur besseren Zusammenarbeit zwischen Entwicklung Betrieb kümmert sich darum, wie die beiden Säulen der IT besser gemeinsam liefern und die oft vorhandenen Silos überwinden. Denn agile Ansätze benötigen schnelles Feedback und das funktioniert dann am besten, wenn das Einspielen von Changes in den Produktivbetrieb gut funktioniert. Dann wird für den Betrieb auch die Qualität der eingespielten Changes besser, so dass weniger Störungen auftreten. Continuous Delivery, unterhaltsam dargestellt im Buch „The Phoenix Project„, ist eine wichtige Säule, die sicherstellt, dass der Auslieferungsprozess zuverlässig und wiederholbar ist. Es geht darum, viele kleine Pakete einzuspielen und nicht ein umfangreiches Release mit vielen Komponenten. Roll-Back-Prozessen kommt dazu eine zentrale Bedeutung zu – wenn ich eingespielte Software schnell wieder zurückdrehen kann, sobald ich einen Fehler bemerke, erspare ich mir lange Root Cause Analysis und bin schneller wieder handlungsfähig, zudem erkenne ich die wiederkehrenden Fehler schneller und kann mich darauf konzentrieren, diese zu beseitigen. Erfolgreich funktionierende Rechenzentren arbeiten mit diesen Methoden. Um dorthin zu kommen, muss man viele Prozesse auf den Prüfstand stellen – die beste Quelle, diese Prozesse zu finden, die schnelle Auslieferung verhindern, sind wie so oft die Menschen, die mit diesen Prozessen arbeiten.

Unser Kunde hat bereits einige Arbeitsgruppen aufgesetzt, um genau diesen Change voranzutreiben. Und die Mitarbeiter einzubeziehen, die oft wissen, wo der Schuh drückt. Anstatt sich darauf zu verlassen, dass Führungskräfte dies erkennen und neue Wege vorschlagen. Für mich ist das der richtige Weg – die Führungskräfte werden dabei benötigt, um die Hindernisse aus dem Weg zu räumen bzw. Rahmenbedingungen zu schaffen, innerhalb derer die Mitarbeiter die Prozesse so gestalten können, dass sie helfen, um besser zu werden. Das Engagement und die Motivation der Menschen, die wir im Training erlebt haben, zeigt, dass sie auf dem richtigen Weg sind.