Upstream Kanban Teil 2 – Triage, Bedenken und Beispiele

Schon einmal etwas von Upstream Kanban gehört? Dies ist der zweite Teil eines Artikels dazu. Im Vorherigen ging es um die Grundlagen und der Cliffhanger war die Triage. Hier zeige ich euch nun ein Beispiel für eine Triage, zeige euch drei Upstream Boards und lasse mich auf eine fiktive Konversation mit einem/r Bedenkenträger:in ein.

Wenn ihr euch diese Frage stellt, seid ihr hier erst mal falsch, solltet zuerst den ersten Teil dieses Artikels lesen (denn das sind die Grundlagen) und dann wieder hier her kommen 😉. Dort ging es um die Triage an und für sich, also den Trichter der Optionen. Falls das ein Fremdwort für euch ist, solltet ihr daher zuerst den ersten Teil lesen, denn in diesem Artikel geht es dann weiter mit Beispielen.

Wenn für euch Upstream und Triage keine Fremdwörter sind, geht’s jetzt los.

Hier also ein Beispiel für ein Upstream-Triage-Board mit WIP-Limits, die mit einem Farbcode veranschaulicht werden. Wichtig ist bei der Upstream Triage, dass dies ein fortlaufender Prozess ist, er also in jeder Spalte immer wieder angewandt wird. Das geht sogar „automatisch“, wenn in jeder Spalte ein Max-WIP und ein Min-WIP angewandt wird. Dann verjüngt sich der Trichter von ganz alleine. Doch keine Angst, fangt einfach erst einmal an und experimentiert mit WIP-Limits, denn neu am Upstream ist vor allem das Min-WIP-Limit.

Mit der Farb-Klassifizierung der Arbeiten gewährleisten wir Transparenz über den Wert der Arbeit, um dann mit Hilfe der WIP-Limits die Arbeit wertabhängig zu pushen oder zu reduzieren. Wir haben damit direkten Zugriff darauf, was als nächstes fertig für die Entwicklung sein wird.

ROT: Äußerste Dringlichkeit. Überspringt möglichst den Upstream-Prozess und geht möglichst schnell in die Entwicklung.

GELB: Hoher, aber unsicherer Wert. Früh beginnen, aber spät festlegen: Vorwegnehmen und Optionen erstellen.

GRÜN: Geringer, aber sicherer Wert. Kann bei Bedarf commitet werden. Nur starten, wenn nötig.

BLAU: Wird den Upstream Auswahlprozess wahrscheinlich nicht überleben. Möglichst schnell verwerfen.

Kanban bedeutet Veränderung und wer kennt das nicht, Veränderung bedeutet oft Unbehagen. Doch wenn der Schmerz der Auftragserhebeung groß genug ist, könnte ein Upstream-Kanban eine Lösungsrichtung geben und eine Veränderung begleiten und forcieren. Wenn ich in Folge dessen einen Upstream vorschlage, begegnen mir immer wieder ähnliche Bedenken, hier einmal eine fiktive Unterhaltung zwischen Egon Ausgedacht und mir:

Egon Ausgedacht: Wir machen doch aber schon Scrum!

Ich: Ja großartig, sogar ein ziemlich gutes mit Ein-Wochen-Sprints! Deswegen fällt uns ja jetzt auch auf, dass der Prozess vorne dran hinkt.

Egon Ausgedacht: In Scrum muss aber alles auf ein Board!

Ich: Stimmt. Wenn wir alles auf ein Board packen, können wir die Auftragserhebung nicht unterscheiden und separat optimieren. Außerdem passen unsere Scrum-Spalten weder zum Auftragserhebungsprozess noch das DoD. Ein Ready to develop gibt’s auch nicht – das wird dabei ja gerade erst herausgefunden. Wir dürfen doch in ein Sprint Backlog nichts reintun, was nicht Ready to develop ist.

Egon Ausgedacht: Jetzt muss ich auf zwei Boards nachschauen!

Ich: Stimmt, wir müssen ja nicht in jedem Daily drauf schauen, sondern nur dann, wenn es wichtig ist. Wenn wir das schlank halten, ist der Mehraufwand vielleicht vertretbar.

Egon Ausgedacht: Noch ein Meeting?

Ich: Ja doof, vielleicht können wir das schlau zusammenlegen, z. B. 15 Minuten vorne ans Planning dran, dann wissen wir gleich, ob die Capability für diese Woche reduziert sind. So können auch Urlaub oder Weiterbildung vor dem Planning besprochen werden, weil sie die Capability reduzieren. Wir müssen ja die Arbeiten auf den Upstream nicht in einem Sprint durchkriegen, Kanban hat ja keine Sprints.

Egon Ausgedacht: Ach keine Sprints – dann kann ich ja daran arbeiten, wann ich will.

Ich: Naja… wir wollen natürlich schon fertig werden.

Egon Ausgedacht: Wie geht das ohne Sprints?

Ich: Na, wir optimieren nicht den Sprint wie bei Scrum, sondern die Durchlaufzeit.

Egon Ausgedacht: Wie optimiere ich denn auf „Durchlaufzeit“?

Ich: Na, wir gucken einfach besonders auf das, was uns blockiert.

Egon Ausgedacht: Das sind in der Regel externe Blockaden!

Ich: Ja, das ist oft eine externe Blockade.

Egon Ausgedacht: Gegen externe Blockaden kann ich nichts tun!

Ich: Ab und zu schon – dazu müssen wir sie aber feststellen, klassifizieren und dann mit den Stakeholdern ins Gespräch gehen.

Egon Ausgedacht: Blockaden klassifizieren? Wie geht das denn?

Ich: …

Ihr seht, es bedarf einer guten Kommunikation, guten Argumenten und eines langen Atems. Stellt euch also auf einen langen Weg ein. Dieser lohnt sich aber.

Hier einmal ein paar Beispiele von Upstream Boards mit den jeweiligen Besonderheiten:

Dieses Board hat eine Fastlane (Expedite) für Dinge mit äußerster Dringlichkeit. Um die Abwurfrate zu sehen, werden die verworfenen Arbeiten in Fertig rot markiert und es wird aktuell nur mir Max. WIP Limits gearbeitet.

Dies ist ein noch wenig ausgereifter Upstream, denn das Team ist neu und hatte viel mit dem Entwicklungsboard, dem Teambuilding und einer Produktdeadline zu tun. Das bisher noch nicht so viel Zeit ins Upstream geflossen ist, ist z. B. an der Blockiert-Spalte und der generellen Verwendung von Standard-Spalten zu sehen. Wir erkennen dennoch bereits einige typischen Upstream Dinge wie z. B. die Visualisierung des Alters, um Blockaden auszumachen, die Benutzung von Swimlanes, um Arbeiten von höherem Mehrwert von den anderen zu trennen und einem Min. WIP auf Next.

Das ist ein Beispiel eines Teams, dass im Entwicklungsprozess auch mit Kanban arbeitet. Das bedeutet, das Team hat viel Erfahrung mit der Visualisierung des Wertstroms, daher sehen wir hier einen elaborierten Workflow mit zwei Feedbackschleifen. Das Team hat auch ein Min. WIP auf Erledigt, was mit dem genutzten digitalen Tool aber nicht abgebildet werden kann.

Jetzt muss ich schon wieder zum Ende kommen. Nun habt ihr eine Vorstellung, aber immer noch kein eigenes Board. Daher werde ich in einem weiteren Artikel beschreiben, mit welchen fünf Schritten ihr zum eigenen Upstream Kanban Board kommt.

Und das bedeutet: Stop staring, start finishing.

Hier ist nun also der Punkt an dem ich einen Schnitt machen muss, sonst werden die Artikel zu lang. Bleibt gespannt auf den dritten Teil und macht es wie Bruce:

„Don’t get set into one form, adapt it and build your own, and let it grow, be like water.“

Bruce Lee

Über die Autorin:

Ich heiße Gina, lebe seit 30 Jahren in Hamburg und beschäftige mich mit agilen Arbeitsmethoden und Organisationsentwicklung. Ich bin akkreditierte Kanban-Trainerin der Lean Kanban University und habe im Laufe meiner beruflichen Laufbahn einigen Firmen bei der agilen Transition geholfen. Bei intersoft bin ich seit 1,5 Jahren als PO tätig und wirke dabei während der alltäglichen Arbeit auf die agile Transformation ein.

Während und nach meinem Meteorologie-Studium habe ich am Max-Planck-Institut für Meteorologie gearbeitet, wo ich mit der Open Source Welt in Kontakt kam. Seit 2003 war ich diesbezüglich stark engagiert, Vize Präsident der TYPO3 Association, danach ein Neos-Core-Team-Member und Direktorin der Neos Foundation.

Privat liebe ich es, durch die Welt zu reisen, zu schwimmen und Kajak zu fahren. Ich bin Tauchlehrerin, GUE Höhlentaucherin und segle ab und zu auf einem Traditionsschiff namens Windsbraut.