Arbeitet ihr an den richtigen Dingen? Selbst wenn ihr über einen gut etablierten Entwicklungsprozess verfügt, müsst ihr den Zufluss der Arbeit regulieren – nach oben oder nach unten. Um dem Kunden einen tatsächlichen Mehrwert zu liefern, müssen das auch fokussiert die richtigen Dinge sein. Das ist das Reich des Upstream-Kanban und dieser Artikel hat drei Teile.

Kennt ihr das Gefühl des Flows? Wenn alles flutsch und wir in einer Stunde so viel schaffen wie sonst in vier? Wie schön wäre es, wenn wir ein Rezept hätten, um in den Flow zu kommen – denn der Flow stockt nicht, es ist genau die richtige Menge an Arbeit und er folgt einer schönen Linie, gerne auch einer geschwungenen, mit Pepp 😉.

Das Konzept des Flows ist bei Kanban eingebaut und ich zeige euch in diesem Artikel, wie ihr versuchen könnt, mit der Auftragserhebung in den Flow zu kommen.

Habt ihr auch ein Entwicklerteam das flutscht? Wenn ihr das nicht habt, solltet ihr besser das Thema angehen als den Upstream 😉, aber das ist dann nicht Inhalt dieses Artikels – denn ich habe eins 😉.

Wenn ihr eins habt, dann kennt ihr vielleicht die Frage, die sich viele Menschen dann stellen: Warum sind Entwickler oft so schnell, während Geschäftsinhaber oder Produktmanager so langsam und wasserfallartig sind?

Aussagen die ich hier oft höre sind z.B.:

• Die Klärung dauert ewig!
• Sind wir nur eine „Verlängerte Werkbank“?
• Das ist zwar die Schnittstelle zwischen Strategie und Umsetzung, aber es wird nicht wirklich priorisiert.

Es geht also um die Optimierung des Lebens vor der Entwicklung. Und wir treffen vorab zwei Annahmen:

1. Die agile Entwicklung im Dev-Team funktioniert.
2. Wir haben eine Strategie – also eine von der wir Prioritäten und Mehrwerte ableiten können.

Den Wertstrom kennen wir alle – die Arbeit folgt diesem Strom. Na dann muss dieser Strom doch nur noch in den Flow kommen. Offensichtlich flutscht es in der Mitte bei der Entwicklung, aber vorne bei der Auftragserhebung stockt es.

Hier sollten wir uns klar machen, dass nur analysiert werden kann, was separat betrachtet wird. Wenn wir alles in einem Topf werfen, erschwert dies die Übersicht. Dann ist Fehlerfindung und Optimierung schwer. Wir brauchen also zuerst einmal eine gute Übersicht – wir brauchen Flughöhe.

Dazu müssen wir den gesamten Wertstrom abbilden, also auch die Auftragserhebung. Und das natürlich nicht in einem Topf, sondern so hintereinander, wie die Arbeit den Strom durchläuft. Das Ganze nennt Kanban dann den End-to-End-Flow und nun können sich die Zuständigen immer den Teil, in dem sie arbeiten, herausnehmen, optimieren und in den Flow bringen.

Natürlich sind hier auch die Schnittstellen zwischen den Abschnitten interessant.

Verschiedene Abschnitte zu haben, bedeutet jedoch nicht, dass nicht ein Team von vorne bis hinten zuständig sein kann – das ist sehr gut möglich. Es bedeutet nur, dass die Arbeit die führende Größe ist und nicht das Team und wir flogen mit diesem Konzept der Arbeit.

So sieht ein En-to-End-Flow schematisch aus. Wir sehen hier eine Unterteilung in Upstream und Downstream. Alles oberhalb der Entwicklung, genauer gesagt des Sprint Backlogs ist Upstream (dunkelgrün), der Rest Downstream (hellgrün).

Das sind nun viele Worte, daher einmal eine kurze und knappe Definition:

Als Upstream-Kanban bezeichnen wir den Teil des Wertstroms, der der Entwicklung von Optionen oder der Produktfindung entspricht. Alles, was getan werden muss, bevor wir tatsächlich mit der Entwicklung einer Software beginnen.

Dieser Begriff wurde ursprünglich von Patrick Steyaert in seinem Buch Essential Upstream Kanban eingeführt.

Was unterschiedet denn das Upstream Kanban von den Downstream Kanbans?

Ein Upstream wie auch ein Downstream Kanban folgt einigen gemeinsamen Prinzipien und Praktiken und daher brauchen wir auch hier ein dediziertes Board für den Wertstrom.

• Das Upstream Board ist etwas schwieriger zu bauen als das Downstream Board. Das liegt daran, dass der Prozess der Auftragserhebung schwieriger zu fassen ist. Zur Not fangen wir mit einem Standard an und passen es kontinuierlich iterativ an.

• Es werden möglichst viele Stakeholder eingebunden, um Blockaden adressieren zu können und Prioritäten zu klären (das wird im dritten Teil des Artikels bei Fünfter Schritt: Identifiziere den Punkt „sinkender Renditen“ relevant).
• Wir arbeiten auch mit WIP Limits (Work in Progress Limit). Allerdings wird die Arbeit vor allem nach unten begrenzt, um dafür zu sorgen, dass das nachfolgende Entwicklungsteam immer genug Arbeit hat.
• Um an den richtigen Dingen bezüglich der Strategie zu arbeiten, selektieren wir kontinuierlich mit Hilfe der Triage (in Teil 2 dieses Artikels findet ihr dann ein Beispiel für eine Triage). Wir nutzen dazu den Trichter der Optionen.
  Dieser veranschaulicht, dass im Downstream – also im unteren „Rohr“ des Trichters – die Arbeiten, die angefangen werden, in der Regel auch abgeschlossen werden.
  Im Gegensatz dazu ist die Aufgabe des Upstreams – also das obere „Dreieck“ des Trichters – möglichst effektiv die Arbeiten mit hohem Wert von denen mit geringem Wert zu unterscheiden und diese schnell zu verwerfen. Die Abwurfrate im Upstream ist daher im Gegensatz zum Downstream hoch.
  Damit gewährleisten wir, dass wir an den richtigen Optionen arbeiten, was wir mit Hilfe eines Abgleichs mit der Strategie (und hier erinnern wir uns an den Anfang, die Annahme ist: Wir haben eine Strategie) validieren. Zwischen den beiden Prozessen/Boards (Upstream und Downstream) – und damit an Zusammentreffen von „Dreieck“ und „Rohr“ – befindet sich der Commitment Point, mehr dazu im dritten Teil des Artikels unter Zweiter Schritt: Commitment Point definieren.

Was das mit der Triage genau auf sich hat und wie das funktioniert, werde ich in einem weiteren Artikel beschreiben, ebenso was für Bedenken auftreten können und euch einige Beispiele zeigen.

In einem weiteren Artikel werde ich beschreiben, mit welchen 5 Schritten ihr zum eigenen Upstream Kanban Board kommt.

Und das bedeutet: Stop starting, 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 zweiten und 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.