NBA79: Kanban Upstream und Downstream einfach erklärt

Nicht vergessen! Wie wichtig ist Kanban Upstream und Downstream

In dieser Episode erkläre ich die Konzepte von Upstream und Downstream in Kanban und deren Bedeutung für effizientes Arbeiten. Ich zeige auf, wie die Arbeit zu unserem Team gelangt und wie wichtig der Feedback-Zyklus ist, um wertvolle Erkenntnisse für zukünftige Entwicklungen zu gewinnen. Wenn du agile Methoden anwenden oder optimieren möchtest, sind diese Aspekte entscheidend für deinen Erfolgsweg.

Shownotes

Über Feedback freue ich mich immer: nobsagile@gmail.com. Ihr erreicht mich auch auf Mastodon unter https://mastodon.social/@nobsagile oder ihr hinterlasst mir eine Sprachnachricht: +4950329677123

—

No Bullshit Kanban Starter Guide

• Artikel und Infografik: https://no-bullshit-agile.de/no-bullshit-kanban-guide.html
• Folge zum Anhören: https://no-bullshit-agile.de/nba77-no-bullshit-kanban-starter-guide.html

NBA78: Kanban Serviceklassen (Classes of Service)

• https://no-bullshit-agile.de/nba78-kanban-serviceklassen-classes-of-service.html

NBA56 – Agilität trifft Realität: Was tun, wenn Kunden oder Stakeholder nicht mitziehen?

• https://no-bullshit-agile.de/nba56-agilitaet-trifft-realitaet-stakeholder.html

Zusammenfassung

In der aktuellen Episode des No Bullshit Agile Podcast beschäftige ich mich mit dem Upstream- und Downstream-Prozess innerhalb des Kanban-Systems. Ich erläutere, wie Arbeit in ein Team gelangt, wie wichtig die richtige Priorisierung und das Definieren von Anforderungen in der Upstream-Phase sind.

Darüber hinaus betone ich die Notwendigkeit, den Feedback-Zyklus im Downstream zu strukturieren, um kontinuierliche Verbesserung zu gewährleisten. Du erfährst, wie ein ganzheitliches Verständnis des Wertstroms letztlich zu höherer Effizienz und erfolgreicheren Projekten führt. Diese Folge richtet sich an alle, die die Prinzipien von Kanban in ihrer Organisation anwenden wollen.

Transkript

Hallo und herzlich willkommen bei No-Bullshit-Agile. Mein Name ist Thomas. Jede Woche spreche ich hier kurz und knapp über Themen rund um agiles Arbeiten.

In der letzten Folge ging es um Serviceklassen in Kanban. Die Frage ist da unter anderem, wie kann ich verschiedene Prioritäten oder auch SLA's, die ich mit Kunden habe, in Kanban abbilden. Das ist, wie ich finde, ein sehr schönes Verfahren. Wenn dich das interessiert, hör da gerne rein. Den Link zu der Folge und alle weiteren Links, die ich erwähne, findest du natürlich in den Shownotes.

Heute in Folge 79 geht es um Upstream- und Downstream-Kanban. Die Frage dahinter ist also, wie kommt die Arbeit in unser System, was muss ich dabei beachten. Unser System ist in diesem Fall unsere Insel. Das Wort werdet ihr jetzt öfter hören. Das bezieht sich dann vor allem auf das Schaubild zum Kanban-Advanced-Guide, an dem ich ja gerade arbeite. Und die zweite Frage ist, wie verlässt die Arbeit unser System und wie schließen wir so einen Feedback-Zyklus.

Bevor wir da im Detail einsteigen, habe ich noch ein ganz kleines bisschen Housekeeping. Ich habe jetzt ein bisschen Zeit investiert, um die Webseite zum Podcast unter no-bullshit-agile.de ein bisschen umzustrukturieren, was den Content anbelangt. Den Einstieg ein bisschen besser zu gestalten für diejenigen, die auf der Webseite ein bisschen lesen wollen. Und wie immer freue ich mich da über euer Feedback. Wenn euch das interessiert, wie die Webseite jetzt aussieht, schaut doch einfach gerne mal rein.

Dann würde ich sagen, steigen wir mal ein. Kanban Upstream und Downstream.

Kleiner Rückblick vielleicht. In der Episode 77 habe ich ja den Kanban Starter Guide vorgestellt. Auch dafür gibt es ja einen begleitenden Artikel und vor allen Dingen auch eine Infografik inklusive Download dazu. Die Idee hinter dem Starter Guide ist, allen den Einstieg in Kanban ein bisschen zu erleichtern. Da habe ich so meine Praxistipps zusammengefasst.

Und ich erwähne da schon ganz kurz, dass es eben ein Starter Guide ist. Sprich, es gibt noch ein paar Dinge, die man bei Kanban sich angucken kann. Man fährt mit dem Starter Guide ziemlich gut, wenn man damit erst mal anfängt. Wenn ihr dann einen Schritt weiter seid, gibt es wie gesagt aber ein paar mehr Punkte.

All das möchte ich in diesem Kanban Advanced Guide dann noch mal darstellen. Der ist so 50 Prozent fertig, würde ich gerne sagen. Wenn du das Cover Bild siehst von der Folge beziehungsweise auf der Webseite, dir den Teaser zu dieser Folge anguckst, dann siehst du schon so einen kleinen Sneak Peek auf die Infografik. Ja, das als kleiner Teaser.

Und ich werde dort ein Prinzip einführen, wo ich mir gedacht habe, das ist eigentlich jetzt schon interessant und deswegen mache ich jetzt hin zu diesem Advanced Guide halt so Zwischenfolgen. Und diese Folge hier beschäftigt sich jetzt halt mit dem Grundprinzip in Kanban Upstream und Downstream.

Wir leben auf einer Insel und diese Insel hat jetzt einen Hafen, der Dinge von einem Festland annimmt und verarbeitet. In einer Fabrik sage ich jetzt einfach mal. Und dann zurück an das Festland gibt. Das heißt, wir haben jetzt im Starter Guide unsere Insel behandelt, unsere Fabrik. Wie bauen wir ein Kanbansystem für die Entwicklung oder die Weiterentwicklung unserer Produkte?

Und wir schauen uns jetzt die beiden Enden an, die es ja braucht. Die Arbeit kommt irgendwo her, muss vorbereitet werden. Das ist dann der sogenannte Upstream und ich nenne das einfach Hafen, um diesem Insel Hafen Festland Bild zu bleiben. Und dann gibt es eben den Downstream. Wir haben etwas fertiggestellt. Wir liefern das jetzt und wir wollen natürlich auch Feedback dazu haben. Wir wollen ja eben wissen, wie gut funktioniert das, was wir da entwickelt haben, um das in eine nächste Iteration oder in eine nächste Produkt Weiterentwicklung einfließen zu lassen. Und diesen Teil etwas verlässt jetzt unsere Insel und geht wieder zurück zum Festland, den Downstream.

Wenn man jetzt so wie ich das in dem Starter Guide gemacht habe, das kann man System nur auf das Team bezieht, dann fehlt eben was. Dann hat man einen sehr guten Start in meinen Augen, aber die komplette Wertschöpfungskette ist eben nicht erfasst. Es fehlt der Teil, woher kommt die Arbeit oder der Wunsch nach einer Produktverbesserung und es fehlt der Teil Feedback dazu, wenn das geliefert ist. Wie hat das wieder Einfluss auf unseren Input, der Downstream.

Upstream und Downstream sind also verbunden. Ihr könnt euch das wie ein Kreislauf vorstellen und das werdet ihr tatsächlich auch in der Infografik von dem Advanced Kanban Guide dann sehen.

Okay, wir schauen uns jetzt mal den ersten Teil an. Wie kommt die Arbeit bei uns im Team an? Wie landet die Arbeit auf der Insel, auf der diese Fabrik ist?

Und ja, wie schon gesagt, beim Upstream Kanban oft werdet ihr auch Discovery Kanban als Begriff finden. Es bezeichnet den gesamten Prozess, bevor es wirklich anzuentwickeln geht. Das heißt, wir arbeiten mit dem Kunden, mit Stakeholdern, mit allen Interessierten und allen, die ja ein Interesse an dem Produkt haben jetzt, was aus diesen Wagen wünschen, wo wirklich als erstes geliefert werden soll.

Also Ablauf kann man sich so vorstellen, da kommt jetzt ein Wunsch und der wird gesichtet, der muss konkretisiert werden, der muss priorisiert werden, der muss zerteilt werden, damit eben klar ist, was ist zu tun, was soll hinten rauskommen und wo sagen alle, ja, das ist das, was ich erwartet habe, als ich diese Anforderung formuliert habe.

Und diese gesichteten oder zu verarbeitenden Ideen, die sammeln wir ganz klassisch in einem Backlog. Und dann gibt es verschiedene Einflüsse, um zu entscheiden, wann ist dieses Ding jetzt dran. Also der Kunde hat eine gewisse Priorität, ihr habt eine gewisse Priorität, der Markt erzwingt manchmal was. Oft ist das Beispiel auch so, rechtliche Anforderungen habe ich auch schon erlebt. Wir müssen das so und so machen, weil sich da rechtlich bei uns was ändert. Könnt ihr euch vorstellen, es gibt eine wichtige Veranstaltung beim Kunden, wo auf einmal Ideen in diesem Backlog wichtig werden.

Und sobald diese Idee wichtig wird, muss sie halt weiter nach oben in unserer Liste und wir müssen gemeinsam Team, Kunde, Stakeholder daran arbeiten, die jetzt zu zerlegen, zu konzipieren und zu überlegen, welcher Teil davon schafft jetzt gerade den größten Wert. Wir wollen ja keine Riesen-Story, sondern wir wollen handhabbare Storys haben. In dem Starter-Guide sage ich auch, eine Story zwischen ein und drei Tage größer sollte die nicht sein. Das lässt sich natürlich im Vorhinein nicht besonders genau definieren, aber in diesem Rahmen denke ich schon, kann man das festhalten.

Und das wollen wir jetzt in dieser ersten Phase, in diesem Upstream-Bereich eben identifizieren. Wir wollen gucken, was haben wir da, wie kriegen wir das klar definiert und ist es wirklich etwas, was der Kunde, die Stakeholder, wer auch immer unsere Anforderungen formuliert, jetzt wirklich braucht.

In dem Starter-Guide empfehle ich euch tatsächlich so eine Spalte dafür zu haben. Ich nenne die Konzept-Spalte, denn ich finde es wichtig, auch diesen Teil der Arbeit auf dem Board zu reflektieren, denn das ist schon auch eine Arbeit, wo das Team stark beteiligt ist.

Und wichtig ist zu erkennen, warum hebe ich das jetzt so hervor, dass es hier noch ein Upstream gibt, dass wir zwar in diesem Fabrik-Bild oder diesem Insel-Bild bleiben können, wir aber auf jeden Fall diesen Hafen, diesen Upstream einführen sollten. Es ist wichtig zu erkennen, dass die Fabrik, das Team, die Umsetzung nur gut funktionieren kann, wenn der Input in die Fabrik gut ist.

Wir können auch schlechten Input nehmen und versuchen, unsere Fabrik zu optimieren auf der Insel. Und auch da finden wir Optimierung ganz sicher. Aber wenn wir es wirklich richtig gut machen wollen, müssen wir weiterdenken und in diesem Fall eben in diesem Upstream denken.

Das ist übrigens auch der Grund, warum es Discovery-Kanman heißt, um rauszufinden, was ist davon gut und was brauchen wir nicht. Und für die Dinge, die gut sind, wie definieren wir die so, dass wir sie wirklich umsetzen können? Und wie identifizieren wir, ob das Ding, was wir da benutzen oder umsetzen wollen, wirklich den größten Wert hat?

Ihr seht, da ist viel Dialog zum Beispiel auch drin. Die Wertedefinition ist natürlich ganz wichtig. Die kann nur gemeinsam mit dem Kunden stattfinden oder mit denjenigen, die diese Idee zur Produktweiterentwicklung haben. Das kann ein Dev-Team nicht für sich alleine machen. Das hat sicherlich da drin eine Position oder eine Rolle, aber alleine geht es nicht.

Und ich spreche in dem Podcast in vielen Folgen ja immer wieder darüber, wie wichtig es ist, die Stakeholder, das ist mein verallgemeineter Begriff dafür, mit ins Boot zu holen. Und das ist zum Beispiel eine super schöne Stelle, wo man mit den Stakeholdern auch über agiles Arbeiten im Allgemeinen sprechen kann. Warum macht das Sinn? Warum zerlegen wir Dinge? Und warum es für den Kunden selber auch so gut ist.

In dieser ersten Phase mit dabei zu sein, denn wir kommen ja gleich zum Downstream. Das, was wir entwickeln, muss ja dann geprüft werden und wir müssen dann ja Kriterien haben, um zu sagen, gegen das wollen wir das prüfen. Und das können in dieser ersten Phase natürlich Akzeptanzkriterien zum Beispiel sein. Je besser die auch aus Kundensicht formuliert sind, desto leichter fällt es auch dem Kunden später zu sagen Ja, das ist das, was ich mir gewünscht habe oder dem Stakeholder, wer auch immer da beteiligt ist.

Wir holen uns in dieser Phase eben verschiedene Stakeholder dazu, Produktmanager, Fachexperten, im Zweifelsfall auch Nutzer, also Endkunden, um eben zu klären, was nehmen wir durch den Upstream auf als nächstes, was wir bearbeiten und welche Anforderungen sind da und wie kriegen wir das konkretisiert.

Und das ist der Upstream. Ihr seht halt schon, wenn wir einfach irgendeine Arbeit annehmen, die von irgendwem kommt, die nicht durchdacht ist, wo wir nicht beteiligt sind und das jetzt auf unsere Insel nehmen und es in unserer Fabrik bearbeiten, dann ist es mehr oder weniger Zufall, wenn das gut funktioniert. Selbst wenn ihr als Team jetzt wirklich gut eingespielt seid und einen guten Flow im Kanban habt, denn die große Gefahr ist, dass gar nicht das rauskommt, was sich jemand gewünscht hat.

Das bedeutet eben, dieses Involvement und sich Gedanken machen, was schaffen wir, was brauchen wir wirklich, was sind die Anforderungen, ist ein großer Teil der Arbeit. In einem Kanban-System, ehrlich gesagt in jedem System, ob das die Methode Kanban ist oder die Methode Scrum oder ein Mix oder XP oder was auch immer ihr tut, diesen Upstream-Teil, den habt ihr eigentlich immer. In Kanban, finde ich, ist er sehr klar formuliert.

Das heißt, wir haben jetzt den Teil, wie kommt die Arbeit zu uns, einmal definiert. Wir arbeiten dann etwas. Hier nochmal der Verweis auf den Starter-Guide, der sich vor allen Dingen darauf konzentriert und jetzt verlässt die Arbeit unsere Fabrik. Wir sind fertig. Das heißt, wir gucken uns jetzt den sogenannten Downstream an und schauen, was ist da für uns als Team noch zu betrachten.

Das Erste, was hier wichtig ist, wir wollen natürlich so oft wie möglich releasen. Das hängt auch von eurem Umfeld ab, das ist mir schon klar, aber es macht gar keinen Sinn, Arbeit liegen zu lassen und sie nicht zu releasen. Wie oft ihr releasen könnt, hängt von sehr vielen Faktoren ab.

Ich persönlich denke, um nochmal kurz auf Scrum einzugehen, viele, zumindest nach meiner Erfahrung, verstehen Scrum so, dass man nach dem Sprint releast. Das sehe ich überhaupt nicht so und ich verstehe auch, ehrlich gesagt, die Denke dahinter nicht. Wenn etwas fertig ist, warum wollt ihr es nicht schon releasen? Damit startet doch ein ganz wichtiger Zyklus, den wir jetzt im Downstream auch unter anderem beachten und betrachten, nämlich der Feedback-Zyklus und ihr verdient auf einmal auch Geld mit dem, was ihr entwickelt habt.

Deswegen, also bei einem Sprint von zwei Wochen ist es wahrscheinlich noch okay, aber bei einem Sprint von vier Wochen verstehe ich nicht, wenn Arbeit denn fertig ist, warum sie nicht auch releast wird. Ich hoffe, viele von euch machen das, auch wenn sie Scrum machen. Ich weiß aber, einige machen es nicht.

Gut, kleiner Sidequest zu Scrum, zurück zu KanMan und dem Downstream, das KanMan-System vorsieht. Wir wollen eben gucken, dass wir etwas liefern und wir wollen institutionalisieren, wie wir das Feedback dazu bekommen. Woher wissen wir jetzt, ob das, was wir mal als eine Hypothese hatten, als wir im Upstream waren und das ist, was wir daraufhin entwickelt haben, auch so funktioniert, wie wir es wollen.

Und das ist ein ganz, ganz wichtiger Prozess, denn das hat wieder Einfluss auf unseren Upstream, also was als nächstes kommt. Deswegen, ich hatte es vorhin ja schon mal gesagt, da schließt sich dann der Kreis. Wir haben unsere Fabrik, die liefert etwas, das ist der Downstream, das ist dann wieder ein Input-Signal für unseren Upstream und wir sind wieder in der Fabrik. Das ist genau dieses Bild. Insel, Hafen, es kommt was an, Festland, wo wir liefern.

Und wenn man sich diesen gesamten Prozess anguckt, dann sieht man, dass KanMan durchgehend in einem Pull-Prinzip denkt. Das fängt beim Kunden an. Der Kunden nutzt etwas und damit startet jetzt eine Feedback-Loop, denn wir müssen etwas verbessern, weil der Markt bestimmte Dinge vielleicht nicht akzeptiert oder sich der Markt verändert hat. Wir haben durchgehend über alle Stationen in KanMan ein Pull-Prinzip.

Wir wollen, und das finde ich auch so schön an KanMan, den ganzheitlichen Wertstrom haben. Upstream, Downstream und unsere Insel sind End-to-End ein Flow, den wir managen wollen.

Es gibt dann noch einen anderen Begriff, da werde ich noch eine dedizierte Folge zu machen, da bin ich im Starter-Guide auch nur ganz kurz darauf eingegangen und der wird in dem Advanced-Guide auch eine größere Rolle einnehmen. Das sind nämlich die Flight-Level und was wir jetzt gerade gemacht haben, war wir haben uns den Flight-Level 2 angeguckt. Wir sind eine Ebene höher. Wir gucken jetzt nicht mehr nur noch auf unser Team, sondern wir versuchen den gesamten Wertestrom zu beachten.

Schauen wir nur aufs Team und das ist der Starter-Guide, dann sind wir auf dem Flight-Level 1. Das was wir jetzt so Schritt für Schritt vorbereiten für den Advanced-Guide geht dann in den Flight-Level 2 über.

Ja und das soll es eigentlich gewesen sein. Kurze Zusammenfassung vielleicht. Wir sind auf der Insel, wir haben da unsere Fabrik, wir produzieren etwas, das findet ihr in dem Starter-Guide. Wir müssen aber in einem nächsten oder übernächsten Schritt einen Schritt weiter gehen. Das tut man ehrlich gesagt fast natürlich und wir schauen uns mit dieser Idee von Up- und Downstream jetzt halt die gesamte Wertschöpfungskette an. Arbeit kommt rein, sie wird durch den Wolf gedreht im Upstream, so wie ich das erklärt habe. Wir bearbeiten das, wir entwickeln etwas, wir releasen etwas und durch Feedback-Zyklus auf der anderen Seite im Downstream und das Managen dessen schließt sich jetzt der Kreis und so haben wir eine komplette Wertschöpfungskette.

Das soll es für heute gewesen sein. Wie gesagt, in dem Podcast versuche ich ja Themen vor allen Dingen anzureißen und versuche immer so bei 15 Minuten zu bleiben. Ich glaube wir sind vielleicht ein bisschen drüber, aber das finde ich auch nicht schlimm und ich bereite jetzt so Schritt für Schritt mit diesen Folgen, ja ich sage mal das Wissen für diesen Advanced-Can-Man-Guide vor.

Wie immer interessiert mich dein Feedback. Habe ich vielleicht etwas übersehen? Siehst du Dinge anders? Hast du aus der Praxiserfahrung heraus vielleicht Dinge, wo du sagst, naja es gibt noch einen ganz wichtigen Punkt im Up- oder im Downstream. Wenn du sowas hast, freue ich mich eben sehr auf dieses Feedback. Du erreichst mich per Mail oder auch per Mastodon. Alle Kanäle, wie du mich erreichst, findest du natürlich in den Shownotes.

Insgesamt habe ich eine ganz große Bitte. Wenn dir der Podcast hier gefällt, wenn dir vielleicht über die Webseite auch gefällt, wenn dir diese Folge gefällt, dann teile das gerne. Teile das mit deinen Kolleginnen und Kollegen, teile es auf deinen Social-Media-Kanälen. Je mehr Leute von diesem Podcast erfahren, desto mehr Feedback bekomme ich. Das kann ich aufnehmen und kann daraus neue Folgen produzieren oder Themen nochmal anders beleuchten und wenn es gut läuft, kommt dir das ja auch zugute.

Ansonsten sage ich, ganz vielen Dank. Habt noch eine ganz tolle Woche und bis zur nächsten Folge bei No Bullshit Agile.