Regeln (nicht nur) im Kanban-Board explizit machen

Streit im Team darüber, ob eine Story in die Spalte "Release" wandern kann?

Ich glaube, das ist ein Szenario, das gar nicht so selten ist. Der Grund ist oft, dass Regeln nicht explizit sind. Ein Prinzip in Kanban, das einfach nur sehr viel Sinn ergibt.

Das Board

Wir alle arbeiten auf die eine oder andere Art mit einem Board. Oft mit Jira (darauf kommen wir später noch zu sprechen). Unsere Boards haben auch alle Spalten, die Prozess- oder Flow-Schritte repräsentieren. Wenn es gut läuft, dann hilft uns das Board unseren Flow zu managen.

Das Problem

Das Board und seine Spalten sind wahrscheinlich recht klar. Was nicht so klar ist, sind die Regeln, wann etwas von einer Spalte in die nächste wandern darf. Nehmen wir mal an, unser Board sieht so aus (wenn dich interessiert, warum ich genau diese Spalten vorschlage, schau mal in den No Bullshit Kanban Starter Guide).

Kannst Du sagen, wann eine Story von UpNext nach Concept oder von Development nach Release wandern kann?

Die Lösung

Wenn du die Frage nicht beantworten kannst, hast du mein vollstes Verständnis. 

Wir haben unser Board mit einem ganz bestimmten Gedanken gebaut. Die Trennung der Spalten hat einen Sinn. Was jetzt fehlt: Die Regeln müssen jedem klar sein. 

Nehmen wir die Frage von oben auf. Wann kann eine Story von UpNext nach Concept wandern?

Natürlich gibt es hier keine allgemeine Antwort, daher mache ich das mal beispielhaft. Wir nehmen mal folgendes an: In UpNext wartet Arbeit, die umgesetzt werden soll. Damit diese nicht gleich in der Development Spalte auf ONHOLD geht, existiert die Spalte Concept um die Architektur für die Umsetzung zu machen und offene Fragen früh im Umsetzungsprozess zu klären. So viel zur Vorrede. Wie kann nun die explizite Regel für den Übergang UpNext zu Concept aussehen?

Regeln UpNext ➡️ Concept

• Keine Arbeit mehr in Spalten weiter rechts
• Ein weiteres Teammitglied steht zur Verfügung
• Die Beschreibung der Story erscheint auf den ersten Blick vollständig

Von diesen Regeln kann es natürlich viel mehr geben, wir lassen es hier erstmal bei den drei.

Wenn wir solche Regeln an den Übergängen haben, haben wir zwei Dinge erreicht

1. Transparenz und damit Sicherheit
2. Einen weiteren Anker um unseren Flow zu verbessern

Die Regeln geben nicht nur Sicherheit, sie helfen uns auch, unseren Flow zu verbessern. Warum? Weil wir die Möglichkeit haben, regelmäßig (Retro anyone?) darüber zu sprechen, ob sie so noch Sinn ergeben und ob wir zu viele oder zu wenige Regeln haben!

Einschub: Jira

Alles wäre toll, wenn ich jetzt in Jira ein kleines Info Icon an den Spaltengrenzen hätte, das diese Regeln anzeigt. Geht aber nicht. Wie so oft zwingt mich Jira dazu, nicht agil zu sein.

Fazit

Es ist eigentlich nur eine Kleinigkeit, wenn ich so darüber nachdenke. Aber eine mit einem großen Potenzial. Regeln existieren auch bei Dir im Team, ganz sicher. Sie explizit zu machen, schadet bestimmt nicht!