10 Kanban-Board-Beispiele

1. Kopieren Sie mit Bedacht. Die Kanban-Board-Beispiele aus der Liste wurden für die Bedürfnisse bestimmter Teams entwickelt. Wir möchten Ihnen keinen „Spickzettel“ liefern, sondern Inspiration, damit Sie ein Kanban-Board erstellen können, das dem einzigartigen Prozess Ihres Teams entspricht.
2. Denken Sie außerhalb der Teamgrenzen. Diese Kanban-Board-Beispiele sind auf bestimmte Teams und Arten von Arbeit zugeschnitten, jedoch nicht ausschließlich für diese Zwecke gedacht. Wenn Sie also in einem Entwicklungsteam sind, aber auf einem der Boards des IT-Operations-Teams etwas sehen, das Ihnen gefällt, sollten Sie es ausprobieren (und umgekehrt). Viele Kanban-Best-Practices sind von einem Teamtyp auf einen anderen übertragbar und können auch auf verschiedenen Ebenen im Unternehmen (nicht nur in Teams) angewendet werden.
3. Beginnen Sie mit den Grundlagen (oder kehren Sie zu ihnen zurück). Ganz gleich, ob es sich um Ihr erstes oder Ihr 100. Board handelt, kann es hilfreich sein, mit einem sauberen, neuen Board zu beginnen, damit es die Realität Ihrer aktuellen Praktiken widerspiegelt.

Softwareentwicklungsteams gehörten zu den frühesten Anwendern der Kanban-Methode. Hier sehen Sie drei Beispiele dafür, wie Entwicklungsteams Kanban-Boards verwenden können, um parallele Prozesse zu verwalten, ein Pull-Systems mit „Bereit“-Warteschlangen durchzusetzen und WIP-Limits zu implementieren.

Parallele Prozesse visualisieren

In jedem Team können mehrere Prozesse parallel ablaufen, die zwar eng miteinander verbunden, aber dennoch so unterschiedlich sind, dass sie eigene Workflows erfordern. Etwa muss ein Entwicklungsteam vielleicht die Entwicklung und das Testen von Funktionen verfolgen, wie in diesem Beispiel dargestellt.

Anstatt die Prozessschritte zu stark zu vereinfachen, um die Anforderungen beider Prozesse mit einem einzigen Workflow zu erfüllen, können Teams ihre Boards so gestalten, dass sie beide Prozesse anhand von horizontalen Bahnen parallel verfolgen können.

Wenn Teams ihre Kanban-Boards auf diese Weise aufbauen, können sie parallele Prozesse unter den Entwicklern berücksichtigen, ohne den Überblick über die Arbeit des Teams insgesamt zu verlieren.

Pull-System mit „Bereit“-Warteschlangen durchsetzen

Bei der Implementierung eines Pull-Systems, eines wichtigen Teils einer ausgereiften Kanban Praxis, müssen Teammitglieder zusammenarbeiten, um zu gewährleisten, dass Arbeit nur bewegt wird, wenn tatsächlich jemand bereit ist, sie anzugehen.

Probleme entstehen häufig, wenn die Arbeit von einer Person an eine andere übergeben werden muss: wenn etwa die Teammitglieder, die für den Schritt „Entwickeln“ verantwortlich sind, nicht die sind, die für den Schritt „Testen“ verantwortlich sind. Ist der Schritt „Entwickeln“ für ein Arbeitselement abgeschlossen, besteht die natürliche Neigung, es zum nächsten Schritt im Prozess zu verschieben. Hat der Tester jedoch nicht die Kapazität, um mit der Arbeit an diesem Arbeitselement zu beginnen, spiegelt das Board eine falsche Realität wider: dass das Testen in Arbeit sei, obwohl es das nicht ist.

Das Integrieren von „Bereit“-Warteschlangen ins Board-Design, wie in diesem Beispiel gezeigt, kann Teams helfen, sich ein genaueres Bild darüber zu machen, wo im Prozess sich die Arbeit befindet. Durch Hinzufügen der Unterbahnen „In Arbeit“ und „Erledigt“ innerhalb des Schritts „Entwickeln“ kann das Team sehen, an welchen Elementen aktiv gearbeitet wird, welche „entwickelt“ wurden, ohne dass sie bereits getestet wurden, und welche Elemente sich tatsächlich in der Testphase befinden.

Anstatt das Arbeitselement in die „Test“-Bahn zu schieben, kann der Entwickler es in einer „Bereit“-Warteschlange ablegen, sodass der Tester es in die entsprechende Bahn ziehen kann, wenn er wirklich bereit ist, mit dem Testen zu beginnen.

WIP-Limits implementieren

Work-in-Process- oder WIP-Grenzen sind ein weiteres zentrales Kanban Konzept, das allen Teams, einschließlich Entwicklungsteams, helfen kann, den Arbeitsfluss durch ihr System aktiv zu verwalten. Bei diesem Kanban-Board-Beispiel verwendet das Team WIP-Limits, um die Zahl der Arbeitselemente zu begrenzen, die in einem beliebigen Schritt zu einem beliebigen Zeitpunkt vorhanden sein können.

Dieses Entwicklungsteam verwendet WIP-Limits, um die Zahl der Aufgaben in bestimmten Bahnen zu begrenzen. Sie werden bemerken, dass nicht in alle Bahnen WIP-Limits integriert sind (visualisiert durch Zahlen oben rechts in der Bahnbezeichnung). Hierbei handelt es sich wahrscheinlich um die Schritte, für die das Team das größte Risiko einer Systemüberlastung ermittelt hat, entweder weil die Kapazität des Teams zur Durchführung dieser Schritte begrenzt ist oder weil die Aufgaben selbst grundsätzlich komplex sind (oder eine Kombination beider Faktoren).

Die Visualisierung von WIP-Limits auf passive Weise kann hilfreich sein, aber nur, wenn diese Limits eingehalten werden. Die Verwendung eines Online Kanban-Boards, das die Limits durchsetzt, wie in diesem Beispiel gezeigt, kann die Wahrscheinlichkeit erhöhen, dass Ihr Team bemerkt, wenn WIP-Limits erreicht oder überschritten werden.

Die Art der Arbeit von IT-Operations-Teams führt häufig zu Prioritätskonflikten: Projektorientierte Arbeit und Routinewartung werden neu priorisiert, wenn dringendere Fehlerbehebungsarbeiten erforderlich sind.

Mit Kanban-Boards zur Visualisierung ihrer Arbeit können Teams Prioritätskonflikte kommunizieren, sich auf deren Lösung konzentrieren und dazu beitragen, dass die Arbeit wieder in Gang kommt. Diese Kanban-Board-Beispiele für IT-Operations-Teams zeigen, wie Teams verschiedene Bedarfsarten bewältigen, wechselnde Prioritäten visualisieren und die Fachgebiete der Teammitglieder widerspiegeln können, während alle auf einem Nenner bleiben.

Verschiedene Bedarfsarten verwalten

Horizontale Swimlanes zeigen unterschiedliche Bedarfsarten eindeutiger an. Das macht transparenter, woran gearbeitet wird, und beleuchtet Engpässe, die das Team bremsen können. Die Einteilung nach Bedarfsarten kann auch für bessere Einblicke bei der Überprüfung von Board-Berichten sorgen. Wenn etwa Ihr Cumulative Flow Diagram längere Zykluszeiten für ungeplante Arbeit als für Produktionsprobleme zeigt, wissen Sie, wo Verbesserungen nötig sind.

Sich ändernde Prioritäten visualisieren

Jedes Team kann ein Kanban-Board verwenden, um den Überblick über sich ändernde Arbeitsprioritäten zu behalten. Im obigen IT-Operations-Beispiel befindet sich die Bahn „Ruht“ unterhalb der Bahn „In Arbeit“, um explizit anzugeben, wenn ein Arbeitselement feststeckt oder nicht weiter bearbeitet werden kann. Visuelle Symbole werden ebenso verwendet, um kritische Arbeit, Arbeit, die andere Arbeit ersetzt hat, und blockierte Arbeit anzuzeigen.

Beachten Sie, dass dieses Team ganz links eine „Legende“-Bahn verwendet, um Symbole und Richtlinien zu erläutern, damit das Team weiß, wofür die visuellen Hinweise stehen.

Manche Teams finden die Aufteilung laufender Arbeiten nach Subteams bzw. Fachgebieten hilfreicher als die nach Bedarfsarten. Dieses Kanban-Board-Beispiel für IT-Operations veranschaulicht, wie horizontale Bahnen verwendet werden können, um die Arbeit von Subteams zu verfolgen und zu verwalten, während das Team koordiniert bleibt.

Sie müssen kein Kanban praktizieren, um ein Kanban-Board zu verwenden. Viele Teams nutzen Kanban-Boards zur Visualisierung der Arbeit, die durch ihren Scrum-, Scrumban-, Wasserfall- oder sonstigen Hybrid-Prozess fließt.

Scrum-Sprintverfolgung mit einem Kanban-Board

Scrum-Teams können die Arbeitselemente, die für den aktuellen Sprint priorisiert sind, mithilfe des Abschnitts „Laufende Entwicklung“ auf dem Board visualisieren und verfolgen. Das Team zieht Storys aus dem Bereich „Aktueller Sprint-Backlog“ und verwaltet Aufgabendetails in der entsprechenden horizontalen Feature-Bahn, um den Sprintstatus schnell zu erkennen.

Das Framework für Agile-Skalierung (SAFe®) liefert ein Rezept für die unternehmensweite Anwendung von Lean-Agile-Praktiken. Kanban-Boards können verwendet werden, um die SAFe-Akzeptanz auf Portfolio-, Programm- und Teamebene zu verwalten.

Dieses Board-Layout erleichtert die Unterscheidung zwischen Geschäfts- und Architektur-Epics und ermöglicht Ihnen, Ihre Initiativen bis zur Implementierung zu verfolgen. Die Verwendung eines Kanban-Boards auf Portfolio-Ebene hilft Ihnen, die programmübergreifenden Initiativen Ihres Unternehmens zu visualisieren, und erleichtert strategische Entscheidungen.

Dieses Board-Beispiel wurde entwickelt, um die Arbeit mehrerer Teams zu koordinieren. So können Sie ein einzelnes Programm-Backlog für jeden Agile Release Train erstellen und Epics in Features aufteilen, die in Program Increments nach Prioritäten geordnet bereitgestellt werden.

SAFe-Kanban-Board auf ART-Ebene

Dieses Kanban-Board-Beispiel zeigt, wie Sie verschiedene Workflows auf demselben Board darstellen können, sodass Teams die Flexibilität haben, jede gewünschte Methodik zu nutzen oder zu ihr zu wechseln. Teams nutzen das Agile-Release-Train-Board, um Features in User Storys aufzuteilen und sie bis zur Implementierung zu verwalten.

Manchmal ist es einfacher, ein eigenes Board-Layout zu erstellen oder zu verbessern, nachdem Sie Beispiele für Kanban-Boards gesehen haben, die von Teams wie Ihrem verwendet werden. Andere Board-Layouts können Sie inspirieren, wie Sie Ihre Arbeit visualisieren und wie Sie innerhalb Ihres Teams zusammenarbeiten. Wenn Sie Ideen für Board-Layouts übernehmen, sollten Sie daran denken, die Arbeitsweise Ihres Teams so weit wie möglich zu berücksichtigen.

In diesem Artikel haben wir Beispiele für Kanban-Boards von Entwicklungsteams, IT-Operations-Teams und Teams vorgestellt, die Scrum und SAFe praktizieren. Obwohl sich alle diese Beispiele auf die Entwicklung oder Wartung von Softwareprodukten beziehen, können die präsentierten Kanban-Konzepte auf praktisch jeden Teamtyp angewendet werden.

Kanban-Boards können auch von Teams verwendet werden, die nicht nach der Kanban-Methode arbeiten, aber ihre Workflows visualisieren müssen, etwa Teams, die Scrum-, Wasserfall- oder Hybridmethoden praktizieren, ebenso wie SAFe.

Wenn Ihr Team neu mit Kanban anfängt, kann es hilfreich sein, mit den Grundlagen zu beginnen, bevor Sie sich die ausgereifteren Kanban Konzepte ansehen, die wir in diesem Artikel vorgestellt haben. Wie bei jeder Geschäftsmethodik ist es wichtig, sich auf das „Warum“ auszurichten, bevor Sie versuchen, das „Was“ oder „Wie“ zu implementieren.

Stellen Sie zunächst sicher, dass Ihr Team ein gutes Verständnis der Kanban-Prinzipien hat: Respektierung der Menschen und kontinuierliche Optimierung. Helfen Sie ihm dann, die Elemente eines Kanban-Boards zu verstehen und zu erkennen, wie es Aufgabenverwaltung und Arbeitsleben verbessern kann. Etwa können Work-in-Progress-(WIP-)Limits dafür sorgen, dass Teammitglieder sich nicht übernehmen und überfordert fühlen.

Weitere Schritte zur Vorbereitung des Teams auf die Verwendung von Kanban-Boards sind:

• Start- und Endpunkte für Ihr Team identifizieren, um Anfang und Ende seines Workflows kenntlich zu machen
• derzeitige Prozesse, Rollen und Verantwortlichkeiten überprüfen
• sicherstellen, dass das Team kontinuierliche Optimierung versteht und sich dafür engagiert
• Führungsqualitäten auf jeder Unternehmensebene fördern

Um dem Kanban-Board zur Akzeptanz zu verhelfen, müssen möglicherweise einige kulturelle Veränderungen im Team erfolgen. So könnte es Teammitglieder beunruhigen, dass Kanban-Boards Schwachstellen im Prozess des Teams wirksam aufzeigen. Wenn sie jedoch wissen, dass das Ziel kontinuierliche Optimierung lautet, kann das ihr Unbehagen verringern.

Sobald mit dem Team eine Grundlage erarbeitet wurde, können die oben gezeigten Kanban-Board-Beispiele zu Diskussionen anregen. Im Laufe der Zeit wird das gesamte Team maßgeblich an Kritik und Verfeinerung des Prozesses beteiligt sein.