Kanban für kleine Teams

Wenn das Werkzeug größer wird als die Methode

Das Muster wiederholt sich in vielen kleinen Unternehmen: Ein Team von vier, fünf Leuten beschließt, seine Arbeit endlich strukturiert zu organisieren. Jemand hat von Kanban gehört, es wird ein bekanntes Projektmanagement-Werkzeug eingeführt, zwei Wochenenden werden in die Einrichtung investiert. Drei Monate später hängen die eigentlichen Absprachen wieder am Whiteboard, die Wahrheit liegt in einer Tabellenkalkulation und das Werkzeug ist ein Friedhof veralteter Karten. Die naheliegende Diagnose lautet: „Kanban funktioniert bei uns nicht.“

Diese Diagnose ist fast immer falsch. Gescheitert ist nicht die Methode. Gescheitert ist die Übersetzung einer sehr kleinen Methode in ein sehr großes Werkzeug.

Wie klein Kanban eigentlich ist

Es lohnt sich, kurz daran zu erinnern, was Kanban im Kern verlangt:

• Machen Sie Arbeit sichtbar.
• Begrenzen Sie, wie viel gleichzeitig in Bearbeitung ist.
• Sorgen Sie dafür, dass Arbeit fließt, statt liegenzubleiben.

Das ist im Wesentlichen alles. Kanban schreibt keine Rollen vor, keine Zeremonien, keine Schätzverfahren, keine Berichtsformate. Es ist eine der wenigen Methoden, die ausdrücklich bei dem beginnt, was Sie heute schon tun, und von dort aus in kleinen Schritten verbessert.

Eine Methode mit drei Kernprinzipien müsste für ein Fünf-Personen-Team eigentlich die leichteste Übung der Welt sein. Warum also scheitert die Einführung so oft?

Werkzeuge lösen Koordinationsprobleme, die kleine Teams nicht haben

Die großen Projektmanagement-Plattformen sind für einen bestimmten Schmerz gebaut: viele Teams, viele Abhängigkeiten, viele Stakeholder, verteilte Verantwortung. Daraus folgen ihre Baupläne – Rollenmodelle und Berechtigungskonzepte, konfigurierbare Workflows mit Freigabestufen, Pflichtfelder, Automatisierungsregeln, Portfolio-Ansichten, Integrations-Marktplätze.

Jede dieser Funktionen ist für irgendeine Organisation sinnvoll. Für ein kleines Team ist jede davon zunächst einmal eine Frage, die beantwortet werden will: Welche Felder brauchen wir? Welche Workflows bilden wir ab? Wer darf was? Kleine Teams beantworten solche Fragen gewissenhaft, denn man will das neue Werkzeug ja richtig benutzen. Aus einem Nachmittag Einrichtung werden zwei Wochenenden. Aus drei Spalten werden neun, weil das Vorlagen-Board neun hatte. Aus „Karte anlegen“ wird ein Formular mit sieben Feldern, von denen fünf niemand je auswertet.

Das Ergebnis nenne ich Konfigurationsschulden: Das Team hat Strukturen gebaut, die es nun pflegen muss, obwohl sie keinen einzigen Handgriff der eigentlichen Arbeit erleichtern. In großen Organisationen gibt es Menschen, deren Aufgabe genau diese Pflege ist. In einem Fünf-Personen-Betrieb ist es ein Abend pro Woche, den niemand bezahlt – und deshalb unterbleibt die Pflege, deshalb veraltet das Board und deshalb wandert die Wahrheit zurück ins Whiteboard.

Der zweite Bruch: Arbeit endet in kleinen Unternehmen nicht bei „Fertig“

Es gibt einen zweiten, seltener benannten Grund, warum Projektwerkzeuge in kleinen Unternehmen entgleisen: In der Welt, für die diese Werkzeuge gebaut wurden, endet der Arbeitsfluss bei „Fertig“ oder „Done“. Irgendjemand anderes kümmert sich um das, was danach kommt.

In einem kleinen Unternehmen gibt es diesen Jemand nicht. Dieselbe Person, die die Arbeit erledigt, hat sie vorher verkauft und muss sie hinterher abrechnen. Betriebswirtschaftlich ist eine Aufgabe nicht fertig, wenn sie erledigt ist – sie ist fertig, wenn sie abgerechnet ist. Wenn das Projektwerkzeug von Kundenstamm und Rechnungsstellung nichts weiß, entsteht an der Spalte „Fertig“ eine Lücke, in der bares Geld liegenbleibt. Jeder, der einmal Ende des Monats mühsam rekonstruiert hat, welche erledigten Arbeiten eigentlich noch nie in Rechnung gestellt wurden, kennt diese Lücke persönlich.

Das ist kein Argument gegen Kanban. Es ist ein Argument dafür, die letzte Spalte des Boards ernster zu nehmen, als Methodenliteratur es üblicherweise tut, und sie mit der kaufmännischen Realität zu verbinden und sei es zunächst nur durch eine Verabredung: Eine Karte verlässt das Board erst, wenn geklärt ist, was aus ihr kaufmännisch wird.

Was übrig bleibt, wenn man Kanban auf das Nötige reduziert

Aus mehreren Jahren Arbeit mit und in Kleinstteams hat sich für mich ein Minimalbestand herausgeschält, der trägt:

Drei bis fünf Spalten, nicht mehr. „Geplant“, „In Arbeit“, „Wartet“, „Fertig“ reichen erstaunlich lange. Jede weitere Spalte muss sich die Frage gefallen lassen, welche Entscheidung sie verbessert.

Das WIP-Limit ist eine Verabredung, keine Softwarefunktion. Ob das Werkzeug Limits erzwingen kann, ist zweitrangig. Entscheidend ist der Satz, den das Team sich gegenseitig sagt: Wir fangen nichts Neues an, solange die Spalte „In Arbeit“ voll ist. Ein Team, das diesen Satz nicht lebt, wird von keiner Validierungsregel gerettet.

Blockaden sind die wichtigste Information auf dem Board. Eine Karte, die wartet, weil eine Rückmeldung des Kunden fehlt, ist wichtiger als zehn Karten, die planmäßig laufen. Eine simple Markierung genügt, aber sie muss beim wöchentlichen Blick aufs Board die erste Frage sein.

Alter schlägt Auswertung. Kleine Teams brauchen keine kumulativen Flussdiagramme. Die eine Kennzahl, die den Aufwand lohnt: Wie lange hängt die älteste Karte schon in „In Arbeit“? Diese eine Frage, wöchentlich gestellt, ersetzt ein ganzes Reporting-Modul.

Keine Story Points, keine Velocity. Schätz-Zeremonien sind Koordinationsinstrumente für Situationen, in denen viele Beteiligte ein gemeinsames Bild brauchen. Fünf Menschen, die täglich miteinander sprechen, haben dieses Bild bereits.

Abbildung: Kanban – Was wirklich nötig ist und was oft nur Werkzeuglast erzeugt

Leitplanken für die Einführung

Wenn Sie Kanban in einem kleinen Team einführen wollen, haben sich ein paar einfache Regeln bewährt:

1. Die Einführung dauert einen Nachmittag, nicht zwei Wochenenden. Wenn sie länger dauert, richten Sie gerade ein Werkzeug ein statt eine Arbeitsweise.
2. Jedes Feld, das beim Anlegen einer Karte länger als ein paar Sekunden kostet, fliegt raus. Was niemand ausfüllt, wird auch niemand auswerten.
3. Ein Board. Nicht eines pro Projekt, nicht eines pro Person. Die Kraft der Visualisierung liegt darin, dass alle auf dasselbe Bild schauen.
4. Karten sprechen die Sprache des Kunden, nicht die Sprache der Technik. „Angebot für Dachsanierung Meier nachfassen“ ist eine gute Karte. „Follow-up Task #217“ ist keine.
5. Wechseln Sie das Werkzeug erst, wenn das Team die Methode lebt. Ein Team, das mit Haftnotizen an der Wand diszipliniert arbeitet, wird mit fast jeder Software zurechtkommen. Ein Team, das die Verabredungen nicht lebt, wird von keiner Software geheilt.

Diese Leitplanken halten die Einführung bewusst einfach und helfen dabei, Kanban als gemeinsame Arbeitsweise zu etablieren, statt ein weiteres System zu schaffen, das gepflegt werden muss.

Fazit: Die Vorteile von Kanban für kleine Teams im Blick

Kanban ist eine kleine Methode. Gerade darin liegt ihre Stärke für kleine Teams. Sie braucht keine komplexen Workflows, umfangreichen Rollenmodelle oder aufwendige Konfigurationen, sondern vor allem ein gemeinsames Bild der Arbeit.

Probleme entstehen meist dann, wenn das Werkzeug größer wird als die Methode. Zusätzliche Felder, Regeln und Auswertungen schaffen schnell mehr Pflegeaufwand als Nutzen. Für kleine Unternehmen kommt hinzu, dass Arbeit nicht immer mit „Fertig“ endet. Häufig ist sie erst dann wirklich abgeschlossen, wenn auch die kaufmännische Seite geklärt ist.

Entscheidend ist deshalb nicht, möglichst viele Funktionen abzubilden, sondern nur das sichtbar zu machen, was für gute Entscheidungen wirklich notwendig ist. Wer Kanban bewusst einfach hält, erhält mit wenig Aufwand genau das, was kleine Teams brauchen: Transparenz über Arbeit, Blockaden und echten Fortschritt.

Hinweise:

Jonas Kutavicius unterstützt Unternehmen unabhängig von ihrer Größe als IT-Dienstleister. Über einen Besuch auf der Website seines Unternehmens Cryon oder eine Kontaktaufnahme freut er sich sehr

Hier finden Sie weitere Informationen zu den Prinzipien und Praktiken von Kanban.

Wollen Sie Jonas Kutavicius unterstützen und über Kanban für kleine Teams diskutieren? Dann teilen Sie diesen Beitrag in Ihrem Netzwerk oder in Ihrem Unternehmen.