Die 7 häufigsten Kanban-Fehler vermeiden, die eure Softwareentwicklung beeinträchtigen

Das ist ideal, wenn euer Team Aufgaben erledigt, bei denen schnelle Reaktionen wichtig sind, etwa im Kundensupport oder bei der Bearbeitung von Wartungsanfragen.

Kanban kann einfacher wirken als Scrum, weil ihr nicht der strengen, vorgeschriebenen Disziplin der Scrum-Zeremonien folgen müsst. Diese Freiheit macht es aber auch schwieriger, Kanban wirklich gut umzusetzen. Wenn ihr denkt, dass Kanban weniger Disziplin erfordert, liegt ihr falsch – ihr braucht mehr Disziplin.

Damit ihr Kanban richtig umsetzt und die Freiheit nicht in Ineffizienz mündet, teile ich nun einige wichtige Tipps, die euch Ressourcen und Nerven sparen.

Die Prinzipien von gutem Kanban

Wenn euer Team zunächst diese allgemeinen Prinzipien befolgt, könnt ihr bei Kanban nicht viel falsch machen.

1. Legt WIP-Limits für die einzelnen Prozessschritte fest und haltet sie ein

2. Schiebt keine Arbeit in nachgelagerte Prozessschritte, wenn dort nicht genügend Kapazität vorhanden ist – also wenn die WIP-Limits erreicht sind.

3. Definiert, was erforderlich ist, um Arbeit von einer Prozessspalte in die nächste zu verschieben

4. Denkt daran, auch Refinement, grobe Planung und Lernen in eure Arbeitsweise zu integrieren

Die häufigsten Probleme – und wie ihr sie vermeidet

Meine Kollegen und ich beraten Unternehmen seit vielen Jahren zu Agile und haben schon alles gesehen. Deshalb möchten wir die sieben häufigsten Kanban-Probleme und ihre Lösungen mit euch teilen. Lest weiter und vermeidet die Fallstricke.

1. Ihr hortet Tickets

Kanban ist eine Methode zur Visualisierung des Workflows. Sie funktioniert, indem sie die laufende Arbeit begrenzt. Kanban stammt aus dem Toyota Production System und der Automobilproduktion. In einer Autofabrik könnt ihr keine Autos vom Fließband nehmen und neben eurem Arbeitsplatz lagern. Ihr würdet nichts erledigen, wenn euer Arbeitsplatz wie der Parkplatz eines Supermarkts aussähe.

Warum glauben Softwareteams dann, dass sie anders arbeiten können? Warum sieht man so häufig Kanban-Boards voller Tickets?

Tatsächlich gehört das WIP-Limit pro Prozessschritt zu den Kanban-Regeln, die am häufigsten gebrochen werden. Die meisten Kanban-Teams haben nicht einmal ein WIP-Limit, und diejenigen, die eines haben, halten es selten konsequent ein.

Was ihr stattdessen tun solltet

• Ein striktes WIP-Limit einzuhalten, ist schwierig. Auch wenn ihr das Gefühl habt, ein Limit nicht einhalten zu können, sollte das Team zumindest anerkennen, dass weniger WIP besser ist.

• Stellt sicher, dass Teammitglieder jeweils nur an einer Sache arbeiten. Bevor ihr etwas Neues beginnt, prüft, wie der nachgelagerte Prozess aussieht. Ist dort bereits alles überlastet? Statt die Überlastung zu verstärken, solltet ihr prüfen, wie ihr helfen könnt.

Ein striktes WIP-Limit einzuhalten, ist schwierig. Auch wenn ihr das Gefühl habt, ein Limit nicht einhalten zu können, sollte das Team zumindest anerkennen, dass weniger WIP besser ist.

Stellt sicher, dass Teammitglieder jeweils nur an einer Sache arbeiten. Bevor ihr etwas Neues beginnt, prüft, wie der nachgelagerte Prozess aussieht. Ist dort bereits alles überlastet? Statt die Überlastung zu verstärken, solltet ihr prüfen, wie ihr helfen könnt.

2. Es gibt kein Refinement

In einem Scrum-Team sind regelmäßige Zeremonien die Regel. Regelmäßige wöchentliche Refinement-Sessions bilden da keine Ausnahme. Bei Kanban sind die Zeremonien nicht mehr vorgegeben. Die Routine verschwindet.

Da Kanban mit einem Ticket-Flow arbeitet, ist es allzu leicht, mit der Arbeit an einem nicht verfeinerten Ticket zu beginnen.

Das führt zu:

• Beginn der Arbeit an zu großen Tickets

• Verschwendung – die Aufgabe wird in die Spalte „In Bearbeitung“ verschoben, und das Team vertraut darauf, dass ein einzelner Entwickler das Ticket verfeinert, während er bereits mit der Umsetzung beginnt.

Mit der Arbeit an zu großen Tickets beginnen

Verschwendung – die Aufgabe wird in die Spalte „In Bearbeitung“ verschoben, und das Team vertraut darauf, dass ein einzelner Entwickler das Ticket verfeinert, während er bereits mit der Umsetzung beginnt.

Was ihr stattdessen tun solltet

• Plant regelmäßige Backlog-Refinement-Sessions ein – auch für Kanban-Teams.

• Sorgt für eine konsequente „Definition of Ready“.

• Nutzt ein Kanban-Board für Refinements oder fügt dem Arbeitsboard eine Refinement-Spalte hinzu, um sichtbar zu machen, wann Tickets verfeinert werden.

• Führt Aufwandsschätzungen und Größenlimits ein, bevor neue Tickets gestartet werden.

Plant regelmäßige Backlog-Refinement-Sessions ein – auch für Kanban-Teams.

Sorgt für eine konsequente „Definition of Ready“.

Nutzt ein Kanban-Board für Refinements oder fügt dem Arbeitsboard eine Refinement-Spalte hinzu, um sichtbar zu machen, wann Tickets verfeinert werden.

Führt Aufwandsschätzungen und Größenlimits ein, bevor neue Tickets gestartet werden.

3. Ihr konzentriert euch zu sehr auf die Entwicklung

Kanban-Teams konzentrieren sich typischerweise zu stark auf die Spalten für Entwicklung und Tests. Sie vergessen oft, Demos durchzuführen oder Feedback von Nutzern und anderen Stakeholdern einzuholen.

In Scrum sorgt das Sprint Review dafür, dass das Team die Ergebnisse betrachtet und darüber nachdenkt, wie sich der Abschluss einer Aufgabe auf das Backlog und die zukünftige Planung auswirkt. Der Demo-Teil des Reviews lädt außerdem aktiv zu Feedback ein. Diese Disziplin fehlt bei Kanban und muss wieder im Kalender des Teams verankert werden.

Macht stattdessen Folgendes

• Plant regelmäßige Demo-Sessions ein – auch für Kanban-Teams.

• Erwägt, eurem Kanban-Board eine Spalte „Feedback erforderlich“ hinzuzufügen.

• Achtet darauf, ob sich das Team zu sehr auf die Umsetzung und zu wenig auf Feedback konzentriert.

Plant regelmäßige Demo-Sessions ein – auch für Kanban-Teams.

Erwägt, eurem Kanban-Board eine Spalte „Feedback erforderlich“ hinzuzufügen.

Achtet darauf, ob sich das Team zu sehr auf die Umsetzung und zu wenig auf Feedback konzentriert.

4. Ihr verwendet den Standard-Workflow von Jira

Der Standard-Workflow von Jira „To do“ – „In progress“ – „Done“ sollte verboten werden. Er hat mehrere schwerwiegende Probleme, zum Beispiel:

• Ihr könnt nicht erkennen, welche Tickets neu sind und welche vom Product Owner für das Backlog freigegeben wurden. Product Owner müssen die Kontrolle über die Freigabe des Backlogs haben. Sie müssen entscheiden, was aufgenommen wird und was nicht, und die Elemente zudem in der richtigen Prioritätenreihenfolge anordnen.

• Ihr könnt nicht kennzeichnen, ob ein Element verfeinert werden muss oder bereits verfeinert wurde und zur Bearbeitung bereit ist (es erfüllt den Filter „Definition of Ready“). Wenn ihr für das gesamte Backlog einfach „Todo“ als Status verwendet, lässt sich die Verfeinerung nicht steuern. Daher wird die Arbeit häufig an nicht verfeinerten Tickets begonnen.

• Wird ein Element nach „Done“ verschoben, gehen die Beteiligten davon aus, dass die Arbeit abgeschlossen ist. Ihr könnt jedoch nicht sehen, ob das Element präsentiert wurde, ob ihr auf Kundenfeedback wartet und welche Elemente veröffentlicht wurden oder auf ein Release warten. Und was ist mit Code Reviews oder Design Reviews?

Ihr könnt nicht erkennen, welche Tickets neu sind und welche vom Product Owner für das Backlog freigegeben wurden. Product Owners müssen die Kontrolle über die Freigabe des Backlogs haben. Sie müssen die Ja-/Nein-Entscheidung treffen und die Elemente außerdem in der richtigen Prioritätenreihenfolge einordnen.

Ihr könnt nicht kennzeichnen, ob ein Element verfeinert werden muss oder bereits verfeinert wurde und zur Bearbeitung bereit ist (es erfüllt den Filter „Definition of Ready“). Wenn ihr für das gesamte Backlog einfach „Todo“ als Status verwendet, lässt sich die Verfeinerung nicht steuern. Daher wird die Arbeit häufig an nicht verfeinerten Tickets begonnen.

Wird ein Element nach „Done“ verschoben, gehen die Beteiligten davon aus, dass die Arbeit abgeschlossen ist. Ihr könnt jedoch nicht sehen, ob das Element präsentiert wurde, ob ihr auf Kundenfeedback wartet und welche Elemente veröffentlicht wurden oder auf ein Release warten. Und was ist mit Code Reviews oder Design Reviews?

Macht stattdessen Folgendes

• Nutzt die folgenden Prozessschritte als Spalten auf eurem Kanban-Board: Neu, Verfeinerung erforderlich, Bereit für die Umsetzung, Review, Feedback erforderlich, Warten auf Demo.

• Sorgt dafür, dass euer Kanban-Board euren tatsächlichen Prozess abbildet – genau darum geht es bei Kanban!

Nutzt die folgenden Prozessschritte als Spalten auf eurem Kanban-Board: Neu, Verfeinerung erforderlich, Bereit für die Umsetzung, Review, Feedback erforderlich, Warten auf Demo.

Sorgt dafür, dass euer Kanban-Board euren tatsächlichen Prozess abbildet – genau darum geht es bei Kanban!

5. Ihr habt keine Regeln dafür, Tickets in die nächste Phase zu übergeben

Gute Agile-Teams haben zwei Qualitätskriterien: die Definition of Ready (DoR) für den Arbeitsbeginn und die Definition of Done (DoD) für den Abschluss. Darüber hinaus besprechen und definieren fortgeschrittene Kanban-Teams Regeln dafür, wie Elemente von einer Kanban-Spalte in die nächste verschoben werden.

Berücksichtigt die Mini-DoD

In meinem letzten Team, das Kanban nutzte, stellte der Entwickler beispielsweise beim Verschieben eines Tickets von der Spalte „Development“ in die Spalte „Testing“ Folgendes sicher:

• Die Funktionalität arbeitet wie gewünscht und ist in den Akzeptanzkriterien definiert.

• Die eigenen Tests des Entwicklers sind erfolgreich, und es gibt keine bekannten Bugs.

• Der Code kompiliert ohne Warnungen.

• Unit Tests wurden durchgeführt und sind erfolgreich.

• Die Design-Dokumentation ist in Confluence aktualisiert.

• Testanweisungen für den Testingenieur liegen vor.

• Entwickler und Tester führen ein Übergabegespräch.

Die Funktionalität arbeitet wie gewünscht und ist in den Akzeptanzkriterien definiert.

Die eigenen Tests des Entwicklers sind erfolgreich, und es gibt keine bekannten Bugs.

Der Code kompiliert ohne Warnungen.

Unit Tests wurden durchgeführt und sind erfolgreich.

Die Designdokumentation wird in Confluence aktualisiert

Der Testingenieur erhält Testanweisungen

Entwickler und Tester führen ein Übergabegespräch

Mit dieser Vereinbarung (Mini-DoD) haben wir viele Abstimmungsschleifen zwischen Tester und Entwickler reduziert und den Workflow im Teamprozess vereinfacht.

Denkt noch einmal an die Autofabrik: Jeder nachgelagerte Arbeitsplatz muss darauf vertrauen können, dass die Mitarbeiter an den vorherigen Stationen die Arbeit stets auf dieselbe Weise erledigen.

Macht stattdessen Folgendes

• Definiert Mini-DoDs für jeden Übergang zwischen den Kanban-Spalten

6. Ihr leidet unter Ticket-Blindheit

In Kanban passiert es leicht, dass ihr euch zu sehr auf einzelne Tickets konzentriert und dabei das große Ganze aus den Augen verliert. In den täglichen Team-Meetings erzählen sich die Teammitglieder zum Beispiel, woran sie arbeiten. Wenn später eine Situation entsteht, in der Teammitglieder wissen sollten, woran andere arbeiten, wird deutlich, dass sie nicht zugehört haben.

Ticket-Blindheit führt dazu, dass sich jedes Teammitglied nur auf die eigenen Aufgaben konzentriert.

Gemeinsam an einem Problem zu arbeiten, ist ein wirkungsvoller Weg, schwierige Probleme zu lösen. Wenn sich Menschen zu sehr auf ihre eigenen Tickets konzentrieren, übersehen sie manchmal Situationen, in denen das Team ein Problem gemeinsam angehen sollte.

Ticket-Blindheit ist besonders gefährlich, wenn das Team überwiegend remote arbeitet.

Kanban kann zu Silos führen, die nur von einer Person abhängen

In Scrum ist das Risiko, die Arbeit anderer aus den Augen zu verlieren, geringer: Das Team muss über den Sprint und darüber nachdenken, was es gemeinsam im Sprint erreichen kann. Die Sprint-Ziele richten das Team außerdem auf die Zusammenarbeit aus.

Macht stattdessen Folgendes

• Achtet auf Probleme, die nur gemeinsam im Team gelöst werden können

• Stellt sicher, dass euer Product Owner dem Team das große Ganze und die anstehende Arbeit vermittelt (hier helfen Backlog Refinement sowie die Methoden „Scan and Plan“)

• Plant regelmäßige Planungssitzungen mit dem Kanban-Team, damit alle auf ein übergeordnetes Ziel ausgerichtet bleiben

• Stellt sicher, dass alle in den täglichen Meetings zuhören, statt vor sich hinzuträumen

• Erwägt, monatliche Ziele oder andere Zwischenziele festzulegen, damit sich das Team besser orientieren kann

• Achtet in vollständig remote arbeitenden Teams besonders darauf, Silos zu vermeiden, die nur von einer Person abhängen

Achtet auf Probleme, die nur gemeinsam im Team gelöst werden können

Stellt sicher, dass euer Product Owner dem Team das große Ganze und die anstehende Arbeit vermittelt (hier helfen Backlog Refinement sowie die Methoden „Scan and Plan“)

Plant regelmäßige Planungssitzungen mit dem Kanban-Team, damit alle auf ein übergeordnetes Ziel ausgerichtet bleiben

Stellt sicher, dass alle in den täglichen Meetings zuhören, statt vor sich hinzuträumen

Erwägt, monatliche Ziele oder andere Zwischenziele festzulegen, damit das Team den Kurs halten kann

Achtet in vollständig remote arbeitenden Teams besonders darauf, Wissenssilos bei Einzelpersonen zu vermeiden

7. Ihr führt keine Retrospektiven durch – also lernt ihr nicht dazu

In Scrum gibt es für Retrospektiven in der Regel einen festen Rhythmus. Der offizielle Scrum Guide empfiehlt, die Retro im letzten Meeting des Sprints abzuhalten – doch nichts hindert euch daran, zusätzliche Retros zu anderen Zeitpunkten durchzuführen. Probiert es aus und findet heraus, was für euer Team funktioniert.

Ohne diesen Rhythmus können Kanban-Teams leicht vergessen, Retrospektiven durchzuführen.

Macht stattdessen Folgendes

• Plant regelmäßige Retrospektiven für die kommenden sechs Monate im Voraus

• Führt sie mindestens einmal im Monat durch, wenn nicht sogar häufiger

• Gebt den Retro-Meetings den nötigen Stellenwert und lasst sie nicht ausfallen

Plant regelmäßige Retrospektiven für die kommenden sechs Monate im Voraus

Führt sie mindestens einmal im Monat durch, wenn nicht sogar häufiger

Gebt den Retro-Meetings den nötigen Stellenwert und lasst sie nicht ausfallen

Kanban, das wirklich funktioniert

Kanban kann für Teams, die in einem sehr dynamischen Umfeld arbeiten, mehr Spaß machen und motivierender sein. Doch auch wenn Kanban einfach erscheinen mag, solltet ihr das nicht als selbstverständlich ansehen. Gutes Kanban erfordert mehr Disziplin als Scrum. Ein guter Scrum Master hilft dem Kanban-Team, sich kontinuierlich weiterzuentwickeln.

Wir hoffen, dass diese Liste mit sieben Dingen, die ihr vermeiden solltet, eurem Kanban-Team hilft, besser zu werden.