Portfolio Kanban oder „An was arbeiten wir aktuell?“ – „Wie jetzt?“ – „Na, an was arbeiten wir als Firma?“ – „Du meinst welche Projekte?“ – „Genau, an welchen Projekten und Themen arbeiten die Teams?“ – „Meinst Du mit ‚arbeiten’, was in der Umsetzung ist?“ – „Nein, nicht nur. Konzepte ausarbeiten ist doch auch Arbeit.“ – „Na eigentlich schon, wir hatten das mal an einem Board hängen auf einem Zeitstrahl“ – „Wo ist das und wer pflegt das?“ – „Mmmhh, das stand da vorne, keine Ahnung, wo das hingekommen ist…“

So ähnlich war ein Gespräch mit einem Kollegen nach meinen ersten beiden Wochen in der neuen Firma. Ich konnte mir trotz vieler Gespräche nur mühsam einen Überblick verschaffen, mit welchen Projekten, in welcher Reihenfolge, Dauer und in welchem Status sich die vier Teams beschäftigten. Ganz zu schweigen von der jeweiligen Priorität für das Unternehmen.

WIP Limits nicht nur auf Team-Ebene

Bei der Einführung von agilen Methoden in der IT achten wir stark auf die Einhaltung der Kernpraktiken z.B. nach Kanban (siehe auch: Kanban in der IT, Klaus Leopold) – insbesondere:

• Visualisierung des Arbeitsflusses
• Limitierung des Work in Progress
• Steuerung und Messung des Arbeitsflusses

Wenn wir das agile Prinzip richtig verstanden haben, sollten wir auch den eigentlichen Zweck verstanden haben. Es geht primär um wirtschaftliche Aspekte: den höchstmöglichen Wert in möglichst kurzer Zeit für das Unternehmen zu schaffen bei gleichzeitiger Vermeidung von Verschwendung. Bei der Implementierung von Scrum oder Kanban betrachten Führungskräfte meist nur die „Produktions“-Prozesse der IT-Teams mit dem Ziel, die Produktivität zu steigern.

Wenn die IT nur schneller entwickelt, dann wären viele Probleme gelöst. Stimmt doch, oder…? Die Organisation als ganzes wird dabei außen vor gelassen. Es macht aber keinen Sinn, das Flow-Prinzip erst ab Team- und Story-Ebene anzuwenden, der Flow muss weiter gefasst werden. Das, was die Teams im Tagesgeschäft mit Hilfe von Artefakten wie Backlog und Team-Board steuern, muss auch auf Unternehmensebene passieren:

• Pull-Prinzip etablieren und WIP-Limit finden: Wie viele Projekte/Themen kann die Organisation bewältigen?
• Flexible und kontinuierliche Priorisierung: Was kommt als nächstes und warum? Ändern sich die Prioritäten durch geänderte Rahmenbedingungen oder neue Erkenntnisse?
• Engpässen und Abhängigkeiten identifizieren: Welche Ressourcen benötigen wir zu welchem Zeitpunkt und gibt es externe Abhängigkeiten, die wir auflösen müssen?

Selbst wenn das Einhalten des WIP-Limits im Team – also an wie vielen Aufgaben es parallel arbeitet – gut funktioniert, erleben wir immer wieder eine Überlastung der angrenzenden Abteilungen und deren Akteure. Insbesondere der Product Owner als Schnittstelle in die Organisation muss sich permanent mit einer viel zu großen Zahl an Konzepten, Ideen und Anfragen gleichzeitig beschäftigen. In diesem Zusammenhang stellt sich die Frage, warum ein Product Owner, im Gegensatz zu seinem Team, in der Praxis nicht auch ein WIP-Limit festlegen und einhalten kann.

Portfolio Kanban – Erste Schritte hin zum Flow

Nach dem Gespräch mit meinem Kollegen habe ich mich an eine ähnliche Situation als Product Owner bei einem früheren Arbeitgeber erinnert. Das war um 2007, bevor der Begriff Portfolio Kanban oder ganz allgemein „Kanban in der IT“ sich etabliert hatte. Das Projekt-„Portfolio“ war ein unüberschaubarer Gemischtwarenladen an Anforderungen, Bugs und Projekten. Die Entwickler arbeiteten ständig parallel an verschiedenen Themen. Die Produktmanager schleppten einen immer größeren Balast an Anfragen und damit Erwartungshaltungen mit sich herum.

Tools zur Administration suggerierten Struktur und Transparenz, erreichten aber das genaue Gegenteil. Die Projekt-Roadmap für die Business Units auf Jahresbasis mit Hilfe von Gantt-Charts sollte Planungssicherheit und Ressourcenverfügbarkeit garantieren, brach aber in der Regel innerhalb kürzester Zeit in sich zusammen. Priorisierungsrunden für neue Projekte fanden in viel zu langen Zyklen statt, so dass durch den „One-Shot-Effekt“ diese zu wahren Verkaufsveranstaltungen wurden.

Die Geschäftsführung führte daraufhin zwei Änderungen ein: Erstens ein wöchentlichen ‚Produktportfolio-Council‘ zur Priorisierung und Statusbetrachtung der Projekte. Teilnehmer waren die Geschäftsführung, die Leiter der Business Units, je ein Vertreter der Stakeholder Teams und die Product Owner. Zum zweiten eine veränderte Ansicht der Projektplanung, weg von der reinen Gantt-Chart Planung hin zu einer Status-Betrachtung (Idee – Konzept – In Umsetzung – usw.). Der Effekt war bemerkenswert. Durch das regelmäßige Betrachten und die damit verbundenen Diskussionen wurden die bis dato ‚gefühlten’ Schwächen in der Produktplanung offensichtlich:

• Zu viele parallele Themen und die Tendenz, alles auf einmal machen zu wollen
• Lange Verweildauer der Anforderungen und damit verzögerte Wertschöpfung
• Ein bis dato fehlender Mechanismus zur kontinuierlichen Priorisierung neuer Ideen
• Fehlende bzw. nicht klar kommunizierte Produkt- und implizit auch Unternehmensstrategie

Die Maßnahmen hatten zwar noch eklatante Schwächen (siehe letzten Abschnitt), bewirkten aber durch die geschaffene Transparenz ein verändertes Bewusstsein, welche Projekte in welcher Reihenfolge das Unternehmen leisten kann und muss.

Portfolio Kanban einfach mal ausprobieren

Zurück zur Ausgangssituation. Mit dieser Erfahrung im Hinterkopf machte ich der Geschäftsführung den Vorschlag, Portfolio Kanban auszuprobieren. Auch hier herrschte die Ansicht, dass doch jedem klar sein müsste, an was gerade gearbeitet wird. Zudem bestand die Befürchtung, dass weitere „Zeremonien“ die gefühlte Meeting-Dichte erhöhen. Das Gegenargument, dass wir damit wahrscheinlich eine Vielzahl von sog. „Jour Fixes“ und damit Meeting-Zeit einsparen können und dass es zunächst ein Experiment sein soll, überzeugte aber.

Portfolio Kanban – Schritt 1: Aus den Köpfen raus und ran ans Board

Im ersten Schritt lud ich die Vertreter der Stakeholder, die Geschäftsführung und die Product Owner zu einem Termin ein und stellte die Idee eines Projekt- bzw. Themen-Boards vor. Im Vorfeld hatte ich den ersten Wurf mit insgesamt vier Spalten für die verschiedenen Status vorbereitet (Grob-, Feinkonzept, In Bearbeitung, Erledigt). Moderationskarten, Stifte und Klebepunkte zum Notieren und Markieren lagen bereit mit der Bitte, alle Projekte auf Karten zu schreiben und in den entsprechenden Status zu hängen. Die Effekte und Diskussionen, die dabei entstanden, waren hochinteressant:

• Bei einigen – auch größeren – Projekten war selbst die Geschäftsführung überrascht, dass daran schon gearbeitet wurde…
• Die Größe des Boards reichte für die Themen der vier IT-Teams nicht aus. Pro Team hingen alleine im Status „In Bearbeitung“ im Schnitt drei bis vier Karten…
• Die Definition von „Projekt“ war vielen nicht klar, insbesondere die Unterscheidung zwischen dem sog. „White Noise“ (Bugs, Mini-Features, allgemeines „Grundrauschen“) und ausgewachsenen Projekten.
• Besonders interessant die Diskussion zur Frage, ob wir unter Projekt nur IT-Projekte verstehen oder auch reine Koordinationsaufgaben wie z.B. die Organisation einer Firmen-Weihnachtsfeier.

Am meisten irritierte mich aber der Wunsch nach einer farblichen Codierung nach Stakeholdern. Die Begründung legte die größte Schwäche im System offen: ein Paritätsprinzip mit dem Ziel einer höchstmöglichen Gleichberechtigung aller Stakeholder. Implizit standen damit die Ziele der einzelnen Abteilungen über den Zielen des gesamten Unternehmens – bzw. die Ziele des Unternehmens waren nicht klar und somit rückten die Abteilungsziele in den Vordergrund.

Portfolio Kanban – Schritt 2: Ein Forum schaffen

Ich beschloss, die Unzulänglichkeiten zunächst zu akzeptieren. Zumindest war der erste Schritt, nämlich Sichtbarkeit zu schaffen, gemacht. Wir vereinbarten ein wöchentliches Standup in gleicher Runde mit einer maximalen Dauer von 15 min. Der Einstieg erfolgte über drei Fragen:

• Was hat sich seit letzter Woche verändert?
• Wo besteht noch Gesprächsbedarf?
• Gibt es Hindernisse und Blockaden?

Nach den ersten Runden wurde jedem Beteiligten schnell klar, warum sich die Karten nur im Schneckentempo – wenn überhaupt – über das Board bewegten. Zum einen lagen zu viele Themen auf einmal bei den Teams. Zum anderen waren die Themen in ihrer Größe zu umfangreich und damit nicht mehr überschaubar. Die Frage, was als nächstes in Bearbeitung genommen wird und warum, wurde von der Gruppe unterschiedlich beantwortet.

Ein Teil konnte dazu keine Auskunft geben. Für andere ergab sich die Priorisierung aufgrund von freien IT-Kapazitäten und deren Spezialisierung…, für die dritte Fraktion war das oben beschriebene Paritätsprinzip die Grundlage – „Stakeholder X (grüne Farbe) ist am Board momentan unterrepräsentiert, die müssten jetzt auch mal wieder zum Zuge kommen…“. Darüber hinaus war der Moderationsaufwand am Anfang enorm hoch, die Gruppe war es bis dato nicht gewohnt, eigenständig mit dem Board zu arbeiten, ggf. Entscheidungen zu treffen, und ganz allgemein sich in einem Standup zu koordinieren.

Portfolio Kanban – Schritt 3: Inspektion und Feinjustierung

Während der nächsten Wochen wurde das Board und besonders die Statusbezeichnungen mehrfach angepasst. Ein zusätzlicher Status für die Nachbetrachtung und Analyse von neuen Features und eine Spalte für blockierte Projekte wurden eingeführt. Letzteres führte uns vor Augen, wie viele Themen aus unterschiedlichen Gründen ‚in der Luft hingen‘ und damit Kosten verursachten (Verschwendung durch Wartezeit).

Eine Retrospektive zum Thema Projekt-/Themenboard brachte auch noch mal das Prinzip der Priorisierung auf den Tisch. Den meisten war jetzt klar, dass die Rangfolge der Bearbeitung sich aus den Unternehmenszielen ableiten musste (siehe auch Die 7 Schritte zu einer guten Produktstrategie) Diese sollte noch stärker von der Geschäftsführung kommuniziert werden, um Silodenken innerhalb der Organisation zu vermeiden.

Mittlerweile hat sich auch der Moderationsbedarf während der wöchentlichen Standups spürbar verringert. Die Gruppe bearbeitet selbständig das Board, erstellt Karten für neue Projekte und Themen und klärt zusätzlichen Gesprächs- und Planungsbedarf. Durch eine Datumsmarkierung, sobald eine neue Karte auf dem Board landet, können ‚Dauerbrenner‘ besser identifiziert werden und die durchschnittliche Durchlaufzeit der Projekte ermittelt werden.

Blockaden wurden aufgelöst, teilweise durch die Entscheidung der Gruppe, Projekte zu „töten“ oder neu zu bewerten – aufgrund zu hoher Abhängigkeiten, Komplexität oder fehlender Relevanz. Das Board steht jetzt für alle sichtbar an einem zentralen Ort, das Standup ist offen für jeden, mindestens aber ein Vertreter der Stakeholder und Teams sollte anwesend sein.

Was hat’s gebracht?

Das Grundprinzip hinter Portfolio Kanban ist nicht neu, gewinnt aber durch den Flow-Gedanken eine andere Bedeutung. Das Sichtbarmachen, an was, in welcher Reihenfolge und mit welcher Dauer die Organisation arbeitet, lässt Rückschlüsse auf Schwachstellen im System und auch der Produktplanung zu. Der Blickwinkel verändert sich durch die Betrachtung der Arbeitsschritte. Die reine Planung in Zeiteinheiten, basierend auf Gantt-Charts, verliert zunehmend an Bedeutung. Folgende Effekte – durch Portfolio Kanban maßgeblich beeinflusst – konnten wir am konkreten Beispiel feststellen:

• Kleinere ‚Projekt-‚ bzw. Feature-Einheiten – größere Themen werden rechtzeitig ‚zerlegt‘ und am Board für alle sichtbar gemacht
• Damit einhergehend kürzere Durchlaufzeiten – auch bedingt durch weniger parallele Aufgaben pro Team und Arbeitsschritt
• Weniger ’schwergewichtige‘ Abstimmungsmeetings – Bedarf wird häufiger direkt im wöchentlichen Standup ermittelt und offene Punkte direkt im Anschluss diskutiert
• Höhere Planungssicherheit – durch die bessere Sichtbarkeit und die regelmäßige Kommunikation im Standup, was sich in welchem Status befindet, werden potentielle Abhängigkeiten von Stakeholdern und Engpässe früher erkannt

Auf was ist zu achten?

Wenn wir auf die Einhaltung der Grundprinzipien- und Praktiken nach Kanban achten, kann nichts schiefgehen. Die Vorgehensweise bei der Einführung von Portfolio-Kanban muss aber an die Rahmenbedingungen des Unternehmens angepasst werden wie etwa der Teilnehmerkreis oder die Arbeitsschritte und Statusbezeichnungen. Die wichtigsten Erkenntnisse und Praktiken:

• Regelmäßige Retrospektiven: hier geht es nicht primär um die Gestaltung des Boards und den Modus, sondern darum, welche Erkenntnisse die Gruppe durch Portfolio Kanban gewinnt.
• Analoges Board: Genauso wie bei den Teams sollte auch hier ein physisches Board wegen der besseren Haptik und Interaktion genutzt werden – Ausnahmen bestätigen die Regel (z.B. verschiedene Standorte)
• Sichtbarkeit: das Board muss immer für alle im Unternehmen gut sichtbar sein, es verfehlt den Sinn und Zweck, wenn das Projekt-Portfolio im Projektmanagement- oder gar Produktmanagement-Office ‚versteckt‘ wird.
• Regelmäßige Standups: Einmal pro Woche, max. 15 min. sind meist ausreichend. Wichtig ist die Regelmäßigkeit und der Teilnehmerkreis, damit die Diskussion über das Portfolio am Leben bleibt.
• Statusbetrachtung der Projekte und Entscheidungen über neue Konzepte und Ideen entkoppeln: Die Entscheidung, welches Konzept oder welche Idee ans Board kommt, benötigt einen völlig anderen Rahmen und ggf. auch einen anderen Teilnehmerkreis.

Portfolio Kanban ist kein Selbstzweck. Ähnlich wie eine User Story – aber auf anderer Ebene – muss es das Versprechen für eine Konversation einlösen können.

Literaturtipp

Klickt, kauft und macht uns reich – unser Literarturtipp zum Thema Kanban in der IT: