Schon einmal etwas von Upstream Kanban gehört? Dies ist der dritte Teil eines Artikels dazu. Wenn euch die Theorie klar ist, aber eine Anleitung fehlt, wie ihr wirklich euer erstes Upstream Kanban Board selber bauen könnt, seid ihr hier genau richtig.
Bevor ich hier bei intersoft meinen Platz gefunden habe, habe ich in meiner beruflichen Laufbahn als akkreditierte Kanban Trainerin, Kanban Coaching Professional und Kanban Management Professional gearbeitet. Kanban bietet in vielen Fällen (insbesondere auch in Fällen in denen nicht programmiert wird) Lösungsansätze, die Scrum in erster Instanz nicht bieten kann. In diesem Artikel stelle ich euch eine besondere Geschmacksrichtung von Kanban vor: das Upstream Kanban.
Upstream Kanban – was ist das genau?
Wenn ihr euch diese Frage stellt, seid ihr hier erst einmal falsch, solltet zuerst diese beiden Artikel lesen (Upstream Kanban Teil 1 und Upstream Kanban Teil 2) und dann wieder hierher kommen 😉. Wenn ihr euch diese Frage nicht stellt, geht’s jetzt los und ich zeige euch wie ihr in 5 Schritten zum eigenen Upstream Kanban Board kommt.
Erster Schritt: Prozess der Wissensgewinnung visualisieren
Zuerst solltet ihr den Wertstrom abbilden, dazu könnt ihr folgende Dinge abarbeiten:
- Welche Schritte passieren vom ersten Hinzufügen zum Backlog bis hin zum Fertigsein für die Entwicklung?
- Wer ist involviert? Haben die Personen Zugriff auf das zukünftige Board und wo werde ich ein kurzes How-To bereitstellen? (Mehr dazu unter Dritter Schritt: Erstellen von expliziten Richtlinien.)
- Mache aus den Schritten Spalten.
- Wann ist eine Arbeit fertig? Kann ich das möglichst genau beschreiben?
- Erstelle daraus ein DoD, hier ein Beispiel:
- Inspect & adapt: Beobachte das System kontinuierlich und adaptiere es in regelmäßigen Abständen.
Zweiter Schritt: Commitment Point definieren
Erinnert ihr euch an den Trichter der Optionen aus dem ersten Teil? Jetzt geht es um den Punkt zwischen den beiden Systemen Upstream und Downstream. Dieser wird Commitment Point genannt. Es ist der Zeitpunkt, an dem die Arbeit im einen System als Done erachtet wird und im anderen System als Ready to develop.
Das muss kein dedizierter Zeitpunkt sein, kann also kontinuierlich geschehen, kann aber auch z. B. so etwas wie ein Releaseplanning sein.
Am Commitment Point geht der Kunde und das Entwicklungsteam eine wechselseitige Verpflichtung ein:
- Das Entwicklungsteam bestätigt, über alles zu verfügen, was es zum Initiieren der Arbeit benötigt und verpflichtet sich zur Lieferung.
- Der Kunde verpflichtet sich, die Arbeit zu verstehen und bereit zu sein, in sie zu investieren.
Dritter Schritt: Erstellen von expliziten Richtlinien
Ich will nicht noch mehr Regeln bekommen! Aber darum geht es auch gar nicht. Es geht darum, dass sich das Team im Klaren darüber wird, was an welchem Schritt geschehen soll, daher muss sich das Team darüber unterhalten und das Beschlossene festhalten. Daraus wird dann automatisch ein How-To, das an alle Stakeholder weitergegeben werden kann, um Klarheit zu schaffen. Zu den Regeln gehören, z. B. was in welcher Spalte passieren soll und wann es wie in die nächste Spalte kommt, ebenso kann dazu auch eine Definition of Ready gehören, die Triage oder eine Time Guillotine.
Hier ein Beispiel:
Vierter Schritt: Replenishment einführen
Um Himmels Willen, was ist das denn? Ein Replenishment ist notwendig, um das Commitment der Teammitglieder zu bündeln und sicherzustellen, dass die richtigen Dinge zur richtigen Zeit in Angriff genommen werden. Es wird beschlossen, woran als Nächstes gearbeitet werden soll, damit die wichtigsten Arbeiten ausgewählt werden, die dem Kunden den größten Nutzen bieten. Es ist dem Planning in Scrum sehr ähnlich. Einen expliziten Termin brauchen wir dafür aber nicht zwingend, es kann:
- z. B. Teil des Jour Fixe mit dem Kunden sein
- z. B. vors Scrum Planning vorgelagert werden
- oder auch beides
Wichtig ist, dass es regelmäßig stattfindet, denn in der Wissensarbeit haben wir fast nie Gewissheit über die Zukunft und damit wollen wir uns nicht zu früh festlegen.
Fünfter Schritt: Identifiziere den Punkt „sinkender Renditen“
Hier geht es darum, dass die Triage ein fortlaufender Prozess ist, der kontinuierlich angewandt wird. Das ist der Entwicklung der Wissensarbeit geschuldet und wir sollten wie folgt vorgehen:
- Am Anfang wird in sehr kurzer Zeit viel neue Information gefunden.
- Dort steigt die Sicherheit bei der Bewältigung der Arbeit schnell.
- Mit der Zeit verlangsamt sich die Geschwindigkeit, mit der neue Informationen entdeckt werden und damit steigen auch die Kosten.
- Sobald festgestellt wird, dass keine neuen Erkenntnisse gewonnen werden, ist der Punkt erreicht, an dem die Erträge sinken.
- Jetzt ist der Moment zu entscheiden, was als Nächstes mit der Option zu tun ist.
- Wollen wir warten, bis sich eine bessere Gelegenheit ergibt, um damit zu beginnen?
- Wollen wir Arbeit investieren und sie in eine Verpflichtung umwandeln?
- Wollen wir sie ganz verwerfen?
Auf jeden Fall ist das der Punkt, an dem entschieden werden sollte und gegebenenfalls wechselt die Option dann die Swimlane oder wird verworfen.
Alles klar? Nicht? Na dann fangt doch einfach mal an ;-). Mit etwas gutem Willen und etwas Zeit wird euch ein erster grober Wurf gelingen, den es dann gilt, kontinuierlich anzupassen. Akademisiert am Anfang nicht zu lange rum, einfach mal machen, nicht zu viel investieren. Die Investition ist dann das kontinuierliche Verbessern und das macht erst dann Sinn, wenn wir es am lebendigen Leib ausprobieren und sagen können, was uns davon hilft und was uns davon hindert. Das allerdings, dürft ihr unter keinen Umständen vergessen, denn sonst geht es in die Hose.
Viel Spaß bei Bauen eines Upstreams und nicht vergessen: Wir machen Kanban!
Hier ist nun der Punkt an dem ich einen Schnitt machen muss, denn hier Kanban zu erklären, würde den Rahmen sprengen, aber eins ist klar: Wir machen in einem Upstream eben auch Kanban – mit allem was zu Kanban gehört. Meine wichtigsten Kanban-Punkte nenne ich hier kurz und wer mehr wissen möchte, der kann sich hier einen Überblick verschaffen.
- Start with what you do now
- Kanban ist nur dann Kanban, wenn es sich verändert
- Kaizen = Change Good
- Inspect and adapt
„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.