Das Starter-Kit: Dein erstes Kanban-System in vier Schritten
Kapitel 321.553 Wörter8 min
Du willst Kanban einsetzen, ohne dich erst durch dicke Fachbücher zu wühlen? Dann ist dieses Kapitel dein Startpunkt. Wir bauen jetzt gemeinsam dein erstes, funktionierendes Kanban-System. Es basiert auf vier einfachen, aber fundamentalen Schritten, die den Fokus sofort vom Abarbeiten einer To-Do-Liste auf das Schaffen eines reibungslosen Arbeitsflusses verlagern. Der zentrale Leitgedanke dabei lautet: Hört auf, neue Arbeit anzufangen, und fangt an, angefangene Arbeit fertigzustellen.
Dieses Kapitel gibt dir alles an die Hand, was du für den Start brauchst. Für eine noch tiefere Ausführung habe ich auch einen detaillierten Kanban Starter Guide1 geschrieben, den du als Begleitung nutzen kannst.
Schritt 1: Visualisiere deine Arbeit (Das Board)
Ein Kanban-Board ist nichts anderes als eine ehrliche Landkarte deiner Arbeit. Bevor du etwas optimieren kannst, musst du es sehen. Jede Spalte auf dem Board repräsentiert einen klaren Zustand, den eine Aufgabe auf ihrem Weg von der Idee bis zur Fertigstellung durchläuft. Das Board macht Engpässe und den Arbeitsfluss für alle unmissverständlich sichtbar. Wichtig ist: Das Board bildet deinen Flow ab, nicht andersherum. Das Tool muss sich deinem Prozess anpassen, nicht du dich dem Tool.
Als Startpunkt hat sich ein einfaches, aber in der Praxis bewährtes Spalten-Layout etabliert. Es ist wichtig zu betonen, dass dies ein Vorschlag ist; dein erstes Board sollte deinen tatsächlichen Prozess abbilden. Aber dieser Aufbau ist ein exzellenter Ausgangspunkt.
Backlog: Das ist das große Sammelbecken für alle rohen Ideen, Wünsche und Anforderungen. Hier herrscht noch Unordnung. Es ist der Hafen, in dem die Schiffe mit vagen Ideen ankommen.
Up Next: Hier landen die Aufgaben aus dem Backlog, die als Nächstes wichtig werden. In dieser Spalte sorgt der Service Request Manager (mehr zu den Rollen in den folgenden Kapiteln) dafür, dass die Aufgaben in der richtigen Reihenfolge gehalten werden. Diese Reihenfolge ist entscheidend, denn sie repräsentiert die aktuell wertvollste Arbeit aus Kundensicht. Die Priorisierung kann hier mehrmals täglich angepasst werden. Diese Spalte ist der Übergabepunkt an das Team.
Concept: Das Team zieht sich eine Aufgabe aus „Up Next“. In dieser Phase wird die Arbeit de-riskiert. Das Team klärt die fachlichen und technischen Details, zerlegt das Vorhaben und stellt sicher, dass alle Fragen beantwortet sind. Ziel ist es, die Aufgabe so vorzubereiten, dass sie später ohne Unterbrechung entwickelt werden kann. Die Konzeption wird bewusst vom Development getrennt, um den späteren Arbeitsfluss zu schützen.
Ready for Development: Dies ist eine kritische Warteschlange. Aufgaben, deren Konzept klar und abgeschlossen ist, warten hier darauf, dass im nächsten Schritt Kapazität frei wird. Sie sind klein, eindeutig und bereit zur Umsetzung.
Development: Hier findet die eigentliche Wertschöpfung statt – Programmieren, Testen, Dokumentieren, internes Feedback einholen. Diese Spalte kann bei Bedarf weiter unterteilt werden (z. B. in „In Progress“, „Testing“, „Review“), aber für den Start genügt eine einzige Spalte, um die Komplexität gering zu halten.
Release: Die Aufgabe ist technisch fertig und wartet auf die Bereitstellung für den Kunden. Je nach Prozess kann das die Vorbereitung für ein Deployment oder das eigentliche Live-Stellen sein.
Done: Die Aufgabe ist beim Kunden angekommen, schafft Wert und die Reise ist beendet. „Done“ bedeutet nicht „Code ist fertig“, sondern „Nutzen ist geliefert“.
Dein erster Schritt: Zeichne genau diese Spalten auf ein Whiteboard oder erstelle sie in einem digitalen Tool. Sei dabei ehrlich. Wenn es bei euch einen obligatorischen Review-Schritt durch eine andere Abteilung gibt, füge eine entsprechende Spalte hinzu. Das Board muss deinen Prozess abbilden, nicht einen idealisierten.
Schritt 2: Limitiere die angefangene Arbeit (WiP-Limits)
Das ist der wichtigste, wirkungsvollste und gleichzeitig am meisten missverstandene Hebel in Kanban. Ein Work-in-Progress-Limit (WiP-Limit) ist eine künstliche Obergrenze für die Anzahl der Aufgaben, die sich gleichzeitig in einer oder mehreren Spalten befinden dürfen.
Warum um alles in der Welt solltest du die Menge der Arbeit künstlich begrenzen? Weil wir in der virtuellen Welt keine natürlichen physikalischen Grenzen haben wie an einem Fließband. Ohne Limits führt das unweigerlich zu Überlastung. Die Folgen sind fatal:
- Massive Kontextwechsel: Multitasking ist ein Mythos. Ständige Wechsel zwischen Aufgaben können die Produktivität um bis zu 40 % senken und führen zu enormen Reibungsverlusten.
- Sinkende Qualität: Wer viele Bälle gleichzeitig in der Luft hält, macht alles nur so ein bisschen. Fehler schleichen sich ein, die später teuer zu beheben sind.
- Verdeckte Engpässe: Wenn alle “beschäftigt” sind und viele Aufgaben in Arbeit sind, erkennt niemand, wo der Prozess wirklich stockt.
- Verlängerte Durchlaufzeiten: Hier greift ein mathematisches Prinzip namens Little’s Law (ein mathematisches Gesetz, das vereinfacht besagt: Je mehr Dinge gleichzeitig in Arbeit sind, desto länger dauert es, bis ein einzelnes davon fertig wird):2 Je mehr Dinge du gleichzeitig anfängst, desto länger dauert es, bis irgendetwas davon fertig wird.
WiP-Limits sind der Mechanismus, der ein echtes Pull-System erzwingt. Neue Arbeit wird erst dann “gezogen”, wenn Kapazität frei wird. Sie zwingen das Team zu Fokus, Kollaboration und dem Abschluss angefangener Arbeit.
Dein zweiter Schritt: Setze ein erstes, einfaches WiP-Limit. Eine gute Faustregel für den Anfang:
- Für die Spalte Development gilt: Anzahl der Teammitglieder mal 1,5. Ein Team mit fünf Personen startet also mit einem WiP-Limit von 7 oder 8. Der Puffer ist wichtig, da es immer Rüst- und Wartezeiten gibt.
- Schreibe diese Zahl gut sichtbar über die Spalte. Die Regel ist einfach: Ist das Limit erreicht, darf keine neue Aufgabe in diese Spalte gezogen werden. Die einzige Priorität des Teams ist es nun, gemeinsam eine der laufenden Aufgaben fertigzustellen, um wieder Platz zu schaffen.
Die Angst vor Leerlauf ist unbegründet. Die entstehende “Slack Time” ist wertvoll für Weiterbildung, Prozessverbesserung oder um Kollegen zu helfen – alles Aktivitäten, die das Gesamtsystem stärken.
Schritt 3: Manage den Fluss (Das Daily mit „Walk the Board“)
Das Daily in Kanban ist kein persönlicher Statusreport für einen Manager. Es ist ein täglicher Gesundheits-Check für euren Arbeitsfluss, mit dem Ziel, gute Software schnell zu liefern. Das traditionelle Vorgehen mit den drei Fragen (“Was habe ich gestern getan?…”) führt oft zu einer reinen Reporting-Veranstaltung, bei der sich Inseln bilden und der Fokus auf Personen statt auf der Arbeit liegt.
Das beste Format, um dies zu durchbrechen, ist das „Walk the Board“.
Dein dritter Schritt: Stell dich mit deinem Team vor das Board und geht die Spalten von rechts nach links durch.
- Startet ganz rechts (Release): Schaut auf die Karten, die kurz vor der Fertigstellung sind. Die wichtigste Frage lautet: „Was hindert diese Aufgabe daran, jetzt sofort live zu gehen? Was können wir als Team tun, um sie über die Ziellinie zu bringen?“ Der Fokus liegt auf dem, was fast fertig ist, weil es am schnellsten Wert liefert.
- Geht nach links (Development): Welche Aufgabe ist am weitesten fortgeschritten? Was braucht sie, um in die nächste Spalte zu wandern? Gibt es Blocker, die den Fortschritt verhindern? Hier entsteht der Dialog: “Kann ich dir beim Testen helfen?”, “Fehlt noch Dokumentation, die ich schon anfangen kann?”.
- Endet bei Up Next: Erst wenn durch das Fertigstellen von Aufgaben in den rechten Spalten ein Platz frei geworden ist (das WiP-Limit also unterschritten wird), zieht das Team die oberste Karte aus Ready for Development.
Dieses Vorgehen hat enorme Effekte:
- Fokus auf die Arbeit, nicht die Menschen: Ihr managt den Fluss der Arbeit, nicht die Auslastung einzelner Personen.
- Fördert Kollaboration: Das Team übernimmt gemeinsam die Verantwortung für eine Story. Es wird klar, wo Hilfe benötigt wird und wer einspringen kann. Die Story wird zur Team-Story.
- Macht Blocker sofort sichtbar: Probleme werden im Kontext der Arbeit besprochen und können sofort adressiert werden.
- Erhöht den Durchsatz: Indem ihr euch auf das Fertigstellen konzentriert, fließen Aufgaben messbar schneller durch das System.
- Verbreitet Wissen: Im Dialog über die Aufgaben findet ein natürlicher Austausch über technische und fachliche Details statt, was Missverständnisse reduziert und das gesamte Team schlauer macht.
Schritt 4: Verbessere kontinuierlich (Kaizen)
Ein Kanban-System ist niemals „fertig“. Die ersten drei Schritte schaffen ein System, das euch hilft, Probleme und Engpässe sichtbar zu machen. Kaizen ist die japanische Philosophie der kontinuierlichen Verbesserung – die Verpflichtung, diese Erkenntnisse zu nutzen und sich ständig zu verbessern.
Dein vierter Schritt: Etabliere zwei einfache Feedback-Schleifen:
- Das Refinement: Dies ist keine starre Zeremonie, sondern ein bedarfsgesteuerter Prozess. Sobald es nötig ist, setzt sich das Team (oder Teile davon) kurz zusammen, um Aufgaben aus dem Backlog zu prüfen, sie zu verfeinern (z.B. mit Methoden wie dem Dimensional Planning), und für „Up Next“ vorzubereiten. Das kann täglich für wenige Minuten oder einmal pro Woche in einem festen Slot geschehen – so, wie es für euren Rhythmus passt.
- Die Retrospektive: Ein regelmäßiges Treffen (z.B. alle 2-4 Wochen), in dem ihr auf euren Prozess und die Zusammenarbeit schaut. Funktionieren unsere WiP-Limits? Ist unser Board-Design noch passend? Welche kleinen Experimente wollen wir als Nächstes ausprobieren, um unseren Fluss zu verbessern? Hier werden die Regeln und das System selbst angepasst.
Fazit: Dein System steht
Glückwunsch! Mit diesen vier Schritten hast du ein voll funktionsfähiges Kanban-System aufgesetzt. Du hast deine Arbeit visualisiert, den Fokus durch WiP-Limits geschärft, einen Mechanismus zur täglichen Steuerung des Flusses etabliert und Schleifen für die kontinuierliche Verbesserung geschaffen.
Das ist der Kern von „No Bullshit Kanban“. Es ist kein dickes Regelwerk, sondern ein schlanker, anpassungsfähiger Rahmen, der dich und dein Team dabei unterstützt, den Arbeitsfluss zu optimieren und kontinuierlich Wert zu liefern. Im nächsten Kapitel schauen wir uns an, wie wir dieses Grundsystem mit klaren Spielregeln wie Rollen und Serviceklassen weiter stabilisieren.
Quellen
„No Bullshit Kanban Starter Guide“. In No Bullshit Agile - Agiles Arbeiten in der Praxis. 2025. https://no-bullshit-agile.de/no-bullshit-kanban-guide.html.↩︎
„Little’s law“. In Wikipedia. 2025. https://en.wikipedia.org/w/index.php?title=Little%27s_law&oldid=1315807023.↩︎
Bleibt nur in diesem Browser. Kein Konto, kein Server, keine Auswertung.