Hunderte Aufgaben, elf mögliche Zustände, elf beteiligte Mitarbeiter, dazu noch verschiedene Auftraggeber … Wie soll man da den Überblick behalten? Und wie soll man das alles strukturiert und für alle zufriedenstellend abarbeiten? Die Antwort klingt wie ein ritueller Tanz: Kanban.
Was ist Kanban?
Nein, Kanban ist kein ritueller Tanz. Übersetzt heißt Kanban ganz einfach „Karte“. Und wenn man sich ein Kanban-Board ansieht, weiß man auch, warum.
Kanban ist eine Methode, die den agilen Software-Entwicklungsprozess unterstützt. Der große Vorteil liegt dabei in der sehr einfach gehaltenen Visualisierung des Arbeitsfortschrittes über alle Entwicklungen in einem Team hinweg. Kanban hilft somit, den Überblick zu behalten und ist ein tolles Mittel, innerhalb eines Teams und auch darüber hinaus über die geleistete und die geplante Arbeit zu diskutieren.
Ein kurzer Blick in die Geschichte
Über die Entstehung von Kanban gibt es mehrere Geschichten. Allen gemeinsam ist, dass sein Ursprung in Japan liegt.
Die für mich schönste Entstehungsgeschichte, die auch Dr. Klaus Leopold, quasi der österreichische „Vater“ von Kanban, immer wieder gerne erzählt, ist die vom japanischen Garten. Die Betreiber des Gartens standen vor der Frage, wie sie sicherstellen konnten, dass der schöne Garten nicht von tausenden Besucher*innen überrannt wird. Die Lösung war ganz einfach: Man legte im Eingangsbereich eine begrenzte Anzahl von farbigen Karten auf. Jede*r Besucher*in nahm sich eine Karte, bevor er*sie den Garten betrat. War keine Karte mehr vorhanden, musste man warten, bis ein*e Besucher*in den Garten wieder verließ und einem eine Karte in die Hand gab. Verließ man selber den Garten, gab man diese entweder einer*m wartenden Besucher*in oder legte sie zurück in die Schachtel beim Eingang. Dieses ganz einfache „Zutrittssystem“ gewährleistete schon lange vor Erfindung des Computers, dass der Garten nie mehr Besucher*innen hatte, als die Betreiber für gut hielten.
Der Unterschied zwischen Kanban und Scrum
Beschäftigt man sich mit Kanban, stolpert man sehr rasch auch über den Begriff „Scrum“. Scrum heißt übersetzt so viel wie „Gedränge“ und ist wie Kanban ein Vorgehensmodell für agile Software-Entwicklung. Im Gegensatz zu Kanban gibt es bei Scrum fixe Rollen und (wenige) fixe Regeln. Die Basis von Scrum sind sogenannte Sprints, das sind vorgegebene Zeiträume, in denen lauffähige Software-Versionen entwickelt werden.
Grundsätzlich eignet sich Scrum ausgezeichnet für neue Entwicklungen. Sehr gerne wird es verwendet, wenn Projekte auf die Beine gestellt werden, bei denen man in enger Zusammenarbeit mit dem Auftraggeber das Software-Produkt entwickelt. Kanban ist dagegen besser geeignet, wenn man ein bereits fertiges Software-Produkt hat und dieses nach und nach weiterentwickelt.
Ein weiterer Grund, warum wir im SAP-Team Kanban und nicht Scrum eingeführt haben, liegt darin begründet, dass Kanban es im Gegensatz zu Scrum ermöglicht, mit dem aktuellen Stand des eigenen Software-Entwicklungsprozesses einzusteigen und dann nach und nach Veränderungen vorzunehmen.
Grundprinzipien von Kanban
Kanban kennt vier Entitäten:
- Mitarbeiter*in
- Aufgabe (in unserem Fall ein Requirement)
- Zustand, in dem eine Aufgabe sein kann
- Kanban-Board
Mitarbeiter*in
Am Kanban-Board ist jede*r Mitarbeiter*in, die*der Aufgaben bearbeitet, mit einem ca. 2×2 cm großen Magnetplättchen repräsentiert. Die Magnetplättchen sind farblich unterschiedlich und tragen die Kürzel des*der entsprechenden Mitarbeiter*in. Mit den Magnetplättchen lässt sich eine Verbindung zwischen Mitarbeiter*in und Aufgabe herstellen. Wird ein Magnetplättchen einer*s Mitarbeiter*in auf eine Aufgabe platziert, bedeutet dies, dass diese*r Mitarbeiter*in die entsprechende Aufgabe bearbeitet.
Aufgabe
Eine Aufgabe stellt eine Entwicklung dar, die verschiedene Entwicklungsschritte oder Status durchlaufen kann. Eine Aufgabe wird durch eine Karte repräsentiert, die abhängig vom Status am Kanban-Board platziert wird. Die Karte enthält die grundsätzlichen Informationen, die notwendig sind, um sich einen kurzen Überblick über die Aufgabe zu verschaffen. In unserem Fall besonders wichtig ist dabei die Priorität. Karten können direkt aus der Requirement-Datenbank heraus gedruckt werden. Damit Karten leicht verschoben werden können, wird auf der Rückseite ein Klebemagnet befestigt.
Zustand
Die Zustände, die eine Aufgabe annehmen kann, sind eindeutig definiert und durch einen Workflow in der Requirement-Datenbank vorgegeben. Solange eine Aufgabe im Beschreibungszustand ist (solange also noch nichts entwickelt wird), sprechen wir von einem Requirement; wenn die Entwicklung gestartet wird, sprechen wir von einem Development.
Kanban-Board
Das Kanban-Board ist in mehrere Spalten eingeteilt. Jede Spalte repräsentiert einen Status, den die Aufgaben annehmen können. Am Kanban-Board werden die Aufgaben in Abhängigkeit ihres Status in der passenden Spalte platziert. Ändert sich der Status einer Aufgabe, wird die Karte entsprechend verschoben. Wir haben es uns zum Prinzip gemacht, dass Karten nur während Kanban-Besprechungen verschoben werden.
Wofür wir Kanban verwenden
„Wir“ heißt in diesem Fall das Team „SAP Engineering/Cons Finance & Reporting“. Wir sind verantwortlich für die Weiterentwicklung und Wartung von SAP FI/CO für die Porsche Holding Salzburg (PHS).
Unsere Tätigkeiten bestehen im Wesentlichen aus den folgenden drei Aufgaben:
- Abwicklung von Projekten (z. B. Ländereinführung)
- Bearbeiten von Tickets (Fehlermeldungen)
- Weiterentwicklung von SAP
Projekte sind meist relativ lang laufende Aufgaben und eignen sich somit für die Visualisierung am Kanban-Board eher schlecht. Tickets haben dagegen ein sehr kurzes Leben – oft von nur wenigen Stunden. Somit eignen sich auch Tickets nicht, am Kanban-Board abgebildet zu werden. Wir verwenden Kanban daher ausschließlich für die Weiterentwicklung. Das Kanban-Board spiegelt also nicht die ganze Wahrheit bezüglich unserer Tätigkeiten wider! Dies immer wieder zu betonen, ist sehr wichtig, da ansonsten ein völlig falscher Eindruck entstehen könnte, wenn „mal nichts weiter geht“.
Warum wir Kanban eingeführt haben
In unserem Team arbeiten elf Kollegen (kaum zu glauben, aber *innen haben wir in diesem Fall leider nicht). Jeder dieser Kollegen hat zeitgleich ein bis acht Requirements in Bearbeitung. Es ergibt sich somit eine Gesamtzahl von etwa 40 bis 50 Aufgaben, die zeitgleich bearbeitet werden. Hinzu kommen noch etliche Requirements-„Leichen“, die oft ein halbfertiges Produkt darstellen, weil sie einem Prioritätenwechsel zum Opfer gefallen sind. Auch langjährigen Mitarbeitern, die in praktisch alle Bereiche Einblick haben, ist es unmöglich, einen Überblick über diese Anzahl von Entwicklungen zu haben – von jüngeren Mitarbeitern ganz zu schweigen.
Dazu kommt, dass es immer wieder Staus in bestimmten Phasen der Entwicklung gab, die zwar jeder spürte, aber keiner „greifen“ konnte. Und zu guter Letzt waren Gespräche mit der Fachabteilung über den Fortschritt unserer Entwicklung schwierig, da es keine Möglichkeit gab, mit einfachen Mitteln einen Gesamtblick auf den Status der einzelnen Entwicklungen zu werfen. Für diesen Zweck haben wir mit Kanban genau das richtige Werkzeug gefunden.
In etlichen Abteilungen der Porsche Informatik wurde Kanban als Mittel für den agilen Softwareentwicklungs-Prozess gewählt – und immer mit Erfolg. Ein Beispiel wurde wie unseres bereits dokumentiert, was ihr in diesem Blogartikel nachlesen könnt: https://www.porscheinformatik.com/das-taegliche-chaos-beherrschen-kann-man-mit-kanban/
Interessant ist, dass man in unseren Gängen und offenen Bereichen etliche Kanban-Boards findet – aber keines gleicht dem anderen, alle sind verschieden. Und das, obwohl viele sehr ähnlich begonnen haben, ganz einfach aus dem Grund, dass wir natürlich abteilungsübergreifend Erfahrungen austauschen und so viel Wissen praktisch „zwischen Tür und Angel“ weitergegeben wird.
Die Bedeutung des Boards
Das Kanban-Board stellt das Zentrum des Softwareentwicklungs-Prozesses dar und bildet diesen für alle sichtbar ab. Mit einem Blick bekommt man einen Überblick über den aktuellen Zustand der Requirements, die gerade aktiv bearbeitet werden.
Wie wir Kanban eingeführt haben
Unser Grundprinzip bei der Einführung war, dass wir die Ist-Situation abbilden. Das heißt, für die Einführung von Kanban waren keine Prozess-Änderungen notwendig. Uns war klar, dass wir durch Kanban Schwächen oder gar Widersprüche in unseren Prozessen erkennen würden, sodass nach und nach Veränderungen und Verbesserungen durchgeführt werden würden.
Circa einen Monat vor der Einführung gab es eine interne Informationsveranstaltung vom „Mr. Kanban“ der Porsche Informatik, Anton Spitzer, der alle Mitarbeiter auf eine sehr positive Art und Weise abgeholt hat. Dabei wurde das Thema Kanban allen nahegebracht. Diese gemeinsame Sicht auf das Thema hat die etwa einen Monat später gestartete Einführung um vieles einfacher gestaltet. Natürlich gab es auch kritische Stimmen. Diese zielten vor allem in die Richtung, dass Kanban nicht die gesamte Wirklichkeit abbilden könne – was völlig korrekt ist. Am Ende der Veranstaltung war aber jedem klar, dass es besser ist, zumindest bei einem beträchtlichen Teil der Tätigkeiten Transparenz und sehr gut abgestimmtes Vorgehen zu haben als nirgends.
Welche Aufgaben kommen ans Board?
Etwa sechs Wochen vor der Einführung von Kanban wurde begonnen, mit dem Fachbereich 14-tägige Priorisierungsbesprechungen durchzuführen. Ergebnis dieser Abstimmungen sind 20 priorisierte Aufgaben. Diese Prioritäten entsprechen den Prioritäten auf den Karten. Nach zwei Wochen sind im Regelfall einige dieser Aufgaben abgearbeitet, und es erfolgt eine neue Priorisierung, bei der neue Aufgaben hinzu kommen. Zusätzlich wurde ein Backlog geschaffen, der Aufgaben beinhaltet, die nicht priorisiert sind.
Das Kanban-Meeting
Zweimal wöchentlich findet ein Kanban-Meeting vor dem Kanban-Board statt, an dem alle Mitarbeiter teilnehmen. Jeder Mitarbeiter gibt einen kurzen(!) Kommentar zu seinen Karten ab und verschiebt die, bei denen sich der Status geändert hat. Sind fachliche Fragen zu klären, wird dies NICHT im Kanban-Meeting durchgeführt.
Nachträgliche Änderungen an Board und Karten
Ein großer Vorteil von Kanban ist, dass man, wenn man Schwächen im Prozess erkannt hat, Kanban nach und nach an den geänderten Prozess anpassen kann. Und so haben auch wir schon in den ersten beiden Monaten eine Reihe von Änderungen in unserem Prozess und somit in der Darstellung am Board umgesetzt:
Mehrere Mitarbeiter arbeiten an einer Aufgabe
Schon beim ersten Kanban-Meeting stellte sich heraus, dass es relativ häufig vorkommt, dass mehrere Mitarbeiter an einer Aufgabe arbeiten. Dies abzubilden ist relativ einfach: Es werden mittels Magnetplättchen alle beteiligten Mitarbeiter auf der Karte platziert.
Externe Mitarbeiter
Es gibt Aufgaben, in die auch externe Mitarbeiter (z.B. direkt von SAP) involviert sind. Es war allgemeiner Wunsch, dass dies sichtbar gemacht wird. Dafür wurden eigene Magnetplättchen mit dem Vermerk „EXT“ erstellt, die genauso gehandhabt werden wie interne Mitarbeiter.
Einsatz-Datum
Gibt es für ein Requirement ein fix geplantes Einsatzdatum (z. B. aufgrund einer gesetzlichen Änderung), soll dieses auf der Karte abgedruckt werden.
Aufgaben des Basis-Teams
Einige Aufgaben des Basis-Teams – das vor allem für das Bereitstellen der SAP-Infrastruktur zuständig ist – sind für unser Team relevant (insbesondere das Einrichten von Berechtigungen). Deshalb werden nun auch für diese Aufgaben Karten gedruckt und am Board platziert.
Undefinierte Zustände
Es hat sich herausgestellt, dass es Prozess-Zustände gibt, die nicht abbildbar sind. Ein Beispiel dafür ist, dass eine Aufgabe bereits als durch den Fachbereich erfolgreich getestet markiert ist, sich dann aber herausstellt, dass noch Änderungen notwendig sind. In diesem Fall muss die Karte in einen früheren Status gesetzt werden, was seitens der Requirement-Datenbank nicht möglich ist. Wir kennzeichnen solche Aufgaben mit einem roten „!“-Magnetplättchen.
Doku erstellt
Mit einer Markierung auf der Karte (z. B. gelber Strich mit Leuchtstift) wird nun dokumentiert, dass für dieses Requirement eine Dokumentation erstellt wurde. Somit sieht man sehr rasch, wo noch Dokus notwendig sind.
Review durchgeführt
Mit einer Markierung auf der Karte (z. B. roter Strich mit Leuchtstift oder einfach Kürzel des betreffenden Mitarbeiters) wird nun dokumentiert, dass für dieses Requirement ein Review durch einen anderen Kollegen durchgeführt wurde.
Projekte
Projekte durchlaufen grundsätzlich andere Status als Requirements – deshalb haben wir sie am Board nicht abgebildet. Das war für viele Mitarbeiter unbefriedigend, da Projekte einen nicht unbeträchtlichen Teil der Arbeitszeit beanspruchen.
Aus diesem Grunde haben wir das Board um eine Lane (Zeile) „Projekte“ erweitert. Der Projektname wird nun am linken Rand mittels Post-it befestigt. Die zugehörigen Arbeitspakete werden – auch wenn sie nicht die exakt gleichen Status wie Requirements durchlaufen – am Board an den am besten passenden Status-Spalten ebenfalls mittels Post-it positioniert. Die Darstellung ist nicht 100% korrekt und bringt eine leichte Unschärfe mit, hilft aber, einen besseren Überblick über die Gesamtsituation zu erlangen – zumindest versprechen wir uns das.
Da diese Änderung erst vor Kurzem durchgeführt wurde, fehlt uns noch die Erfahrung, um hier Erkenntnisse gewinnen zu können.
Im Zusammenhang mit der Einführung einer eigenen Lane für Projekte wurde auch eine eigene Lane für priorisierte und nicht priorisierte Projekte geschaffen. Das Board hat somit ein grundlegend anderes Erscheinungsbild bekommen:
Was hat Kanban bewirkt?
Transparenz in alle Richtungen
Dadurch, dass alle Requirements, die wir aktiv in Bearbeitung haben, auf einem Board platziert sind, ist diese Gesamtheit der Aufgaben (natürlich ohne Projekte und ohne Tickets) auf einen Blick sichtbar. Man sieht sofort, in welchem Stadium wichtige (= hoch priorisierte) Aufgaben sich befinden. Man sieht auch sofort, wenn Tätigkeiten durch unterschiedlichste Gründe blockiert sind. Aber genau das ist ja die Basis für Verbesserungen.
Aufzeigen von Prozess-Schwächen
Bisher war uns nicht bewusst, dass es Prozess-Zustände gibt, die eigentlich nicht möglich sind. Noch haben wir für diese Situation keine Lösung – aber wir kennen jetzt das Problem und haben die Möglichkeit, daran zu arbeiten.
Aufzeigen von Engpässen
Im Softwareentwicklungs-Leben kommt es immer wieder vor, dass es irgendwo eng wird. Das Problem dabei ist, dass diese Engpässe oft zu wenig greifbar sind. Mit Kanban können wir sehr schnell sehen, wo es eng wird – und oft auch, warum.
Aufzeigen von Parallelitäten bei Mitarbeitern
Mitarbeiter klagen (zu Recht!) immer wieder darüber, dass sie zu viele Aufgaben parallel zu bearbeiten haben – und bleiben oft ungehört. Ein Blick aufs Board zeigt die Situation sehr schnell und eindrucksvoll.
Aufzeigen von Parallelitäten in Status
Zehn Aufgaben müssen parallel getestet werden? Kann nicht funktionieren und wird nicht funktionieren. Bei jeder Kanban-Besprechung sehen wir sehr schnell, bei welchen Tätigkeiten es eng zugeht und vor allem, welche Tätigkeiten in Zukunft Gefahr laufen, ein „Flaschenhals“ zu werden.
Aufzeigen von Prioritätenwechsel
Alle zwei Wochen werden die Prioritäten gemeinsam mit dem Fachbereich neu definiert. Im Idealfall sind viele Aufgaben, die im letzten Meeting priorisiert wurden, bereits fertig und fallen somit raus. Bleiben aber Aufgaben am Board, müsste eigentlich die Priorität höher sein als beim letzten Mal. Da wir die Priorität auf der Karte vermerken, bei einem Prioritätenwechsel die alte Priorität durchstreichen und daneben die neue dazuschreiben, sieht man sofort, ob die Reihe kontinuierlich absteigend ist (das müsste sie eigentlich sein) oder nicht. Ist das nicht der Fall, ist gemeinsam mit dem Fachbereich zu klären, warum die Aufgabe an Wichtigkeit verloren hat.
Die Schattenseiten
Ja, es gibt bei Kanban auch Schattenseiten! Grundsätzlich kann Kanban Probleme nur aufzeigen, gelöst werden sie dadurch aber noch nicht.
In unserem Fall gibt es zwei diskussionswürdige Punkte:
- Nicht alles ist am Board
- Große und kleine Aufgaben
Nicht alles ist am Board
Drei große Bereiche blieben anfangs ausgespart und waren am Board nicht abgebildet:
- Projekte (wie Ländereinführungen)
- Tickets (Fehlerbehebungen)
- Requirements vom privaten Einzelhandel
Das Board spiegelte somit nur einen Teil der Arbeitswirklichkeit im Team wider. Zumindest für die Projekte und den privaten Einzelhandel haben wir eine Lösung gefunden. Da Tickets so kurzlebig sind, werden wir diese wohl auf Dauer nicht am Board haben.
Große und kleine Aufgaben
Die Größenordnung der Requirements schwankt zwischen wenigen Stunden und über hundert Stunden. Auf den Karten ist das zwar durch die Angabe „Aufwand“ sichtbar – somit aber erst, wenn man ins Detail geht. Wir haben die Sache dahingehend gelöst, dass wir Aufgaben ab der Größe „bis 80 h“ mit einem Leuchtstift markieren.
Ausblick – weitere mögliche Schritte
Es gibt eine Reihe von Möglichkeiten, um aus unserem Software-Entwicklungsprozess noch mehr herauszuholen. Im Folgenden einige Vorschläge, die noch nicht beschlossen sind, aber von einigen Kollegen schon genannt wurden:
Auswertungen
Durch die Transparenz von Kanban ist man in der Lage, eine Reihe von Kennzahlen zu ermitteln, die einen Vergleich mit der Vergangenheit ermöglichen.
Solche Kennzahlen könnten sein:
- Durchschnittliche Durchlaufzeit einer Karte
- Durchschnittliche Wartezeiten auf bestimmte Reaktionen (Freigaben oder Tests)
- Durchschnittliche Verweilzeiten in einem bestimmten Status
- Durchschnittliche Anzahl von Karten in bestimmten Status
Limits
Ein Grundprinzip von Kanban ist, dass pro Status (also pro Spalte) eine Maximalzahl an Karten existiert, die nicht überschritten werden darf. Das hat überraschenderweise eine deutliche Verbesserung der Durchlaufzeit von Karten zur Folge. Noch haben wir keine Limits definiert, dies wird aber in der nächsten Zeit kommen. Um die Höhe der Limits festzulegen, fehlt uns noch die Erfahrung.
Gegenseitige Unterstützung
Mit der Einführung von Limits wird es bei einzelnen Mitarbeitern zu Freiräumen kommen. Diese können und sollen dazu genutzt werden, um Kollegen zu helfen, ihre Karten weiterzubringen. Das hat nicht nur eine Beschleunigung der Durchlaufzeit zur Folge, so wird auch automatisch das Wissen in die Breite gebracht.
Fazit
Vor der Einführung von Kanban gab es durchaus kritische Stimmen. Diese betrafen vor allem die Tatsache, dass am Board nur die Requirements (und jetzt auch Projekte), nicht aber Tickets abgebildet werden. Die Alternative wäre aber, auch im Requirement-Bereich auf Transparenz und die anderen Vorteile von Kanban zu verzichten.
Nach drei Monaten Kanban kann man durchaus sagen, dass alle Kritiker verstummt sind und dass die Erwartungen an Kanban nicht nur erfüllt, sondern übertroffen wurden. Nichtsdestotrotz ist die Reise noch nicht zu Ende – und wird wohl auch nie zu Ende sein. Ganz einfach deshalb, weil unser Softwareentwicklungs-Prozess im ständigen Wandel ist und somit immer wieder aufs Neue angepasst werden muss.
