Many organisations don’t recognise the difference between upstream and downstream. Some do recognise, but don’t consciously think about the nature of the difference between the two and consequently don’t design their systems of work in the most effective way. I hope this article will help you recognise the difference between the two and secondly, how to handle each situation.
Both upstream and downstream involve knowledge work. I consider knowledge work anything that requires the use of the “necktop computer”. That is, it’s inherently human and requires skills and knowledge, but it’s also about knowledge discovery. The following diagram is a visual representation of flow moving through upstream and downstream.
Upstream
Upstream is to the left of the “commit point” (the red line). You can see a few columns there describing a basic flow, plus a discarded area at the bottom. Different types of work may flow through at different rates, but usually the high value items will take longer to move through this flow.
Upstream is about discovering and selecting from your options. This is why it’s slightly different here – you can see the discarded area where we drop options that are not worthy of our time in delivery. We have other things like minimum WiP limits to help ensure that we don’t starve downstream.
Key to upstream is that you’re buying information. That is, you’ll need to make decisions thus you should understand what decisions you’re looking to make and get the appropriate information for those decisions. Doing so, you should usually find the cheapest and fastest ways to get information that is “good enough” for making decisions.
I also like to overlay this with the Cynefin framework. I quite often consider a lot of the work that occurs upstream to be in the complex domain. We often probe to find the information we need to make decisions. We may also apply some expertise / analysis (complicated domain) – for example to get the appropriate information to be considered “Ready” for downstream consumption, but the main high value work will usually involve some probes.
Image source: https://en.wikipedia.org/wiki/Cynefin_framework#/media/File:Cynefin_as_of_1st_June_2014.png
There are also linkages with upstream once an item is “Done”. There may be some validation that occurs once items are deployed which will feed new options into upstream. Ensuring appropriate feedback loops and data capture are performed are ready should also be considered when designing your system of work.
Downstream
Downstream we’re looking to convert the options chosen into outcomes. This is quite different to upstream – whilst still knowledge work the goals are different and we need to adapt the system appropriately. I often also see / refer to this as “Delivery” as well.
This is why in downstream we consider things like efficiency and quality. Often downstream is quite costly – there may be a variety of skills and competencies here that aren’t cheap to buy so we want to make sure we’re getting the best “bang for our buck”. Here we’re looking to avoid blockages and bottlenecks and convert the option as quickly as possible, or at least doing so in a way that’s fit for the customers purpose.
As this conversion of options requires quite a lot of skill, often we see most of the work in the Complicated domain of Cynefin. That’s not to say that we won’t see elements of complexity or best practice, just that predominantly it will be complicated. Ensuring we adjust the system of work that is created should reflect this nature. We see this in agile software development quite a lot, where teams might be working on stories that fulfil user / customer needs, but there might be other types in there such as “Spikes” which are a form of probe.
The quality aspect here downstream usually get’s us to ask “are we building the thing right”. Conversely, upstream are often asking the question “are we building the right thing”. Downstream we focus on making sure the customer’s need was met through the service we’re providing. We’re also looking more deeply at “how” we do it rather than “why” – upstream should have already answer the question of “why”.
Conclusion
As you can see, there are considerable differences between upstream and downstream. Just knowing the differences will help you create a better design for your system of work. Please consider both and make sure your system has been optimised in the right way at the right points to enable better outcomes.
If you want to learn more about upstream, we cover this off in more detail in the Kanban Systems Improvement course. I’d encourage you to do Kanban System Design first if you haven’t yet done so to understand more of the basics of how to create Kanban systems.