Avoiding local optimisation with Value Streams
At a startup communication is easy and work flows efficiently. Everyone knows what is most important and gets on with it. As the organisation grows, this inevitably becomes more complex. What was once automatic starts to become problematic. It seems to take too long to get anything useful done.
These are all signs of friction creeping into the systems. Inefficiencies which Lean refers to as “waste” (“muda” in Japanese) build up as the organisation grows. Generally little thought goes into streamlining these processes as a scaling organisation is “too busy”. But, like technical debt in the code, this “organisational debt” builds up and slows the delivery of value.
We want to ensure a flow of work through the organisation. In Lean, by “flow” we mean a state of continuous movement of work through a process, where work is delivered in a smooth and uninterrupted manner. Like a river with boulders, flow can be interrupted by disruptions or waste.
However, it can be hard to visualise how smooth the flow really is. Value Stream Mapping gives us a tool to look at how work flows through the organisation and assess where to focus improvement.
Define Value
One of the challenges if we are to discuss value streams is to make sure we have an agreed understanding of “value”.
The worth of a deliverable is judged by the person receiving the value. Primarily this is external customers, who pay for services or license products. However, value stream mapping can (and generally should) also be applied to internal customers who use internal services and platforms.
Value does not equate to other factors such as effort, cost or quality. Remember the key point is how the customer perceives the value.
Quality is probably closer to value, if we define quality as being fit for purpose. But the organisation’s purpose may differ from the specific customer purpose. A high performance capability, for example, may not be valued by the customer.
High effort does not correlate with high value. The customer may not be aware of the effort and certainly won’t pay more for something just because it was difficult to produce. A simple solution which solves the customer problem may be worth far more than a complex solution which doesn’t help the customer
Cost, like effort, is not a measure of value. Again, the customer may be unaware of cost and sees only the price.
Value Streams
To start, we can use the definition below to understand what is a value stream.
A value stream is an end to end set of activities which collectively creates value for a customer.
“The Great Transition” – James Martin
Within our organisation, we start with a concept or hypothesis and perform a set of activities which result in value for the customer. The original hypothesis starts with no value, and the chain of activities builds the value.
A value stream is a linear representation of the chain of activities from hypothesis to customer value. It is not the same as a process map. In a process map, we identify and describe all the organisation’s processes. This is an important part of ensuring clear, well-understood and effective ways of working. A process map is typically a web of inter-related processes with one map for the organisation. A value stream by contrast is linear and represents a slice through that process map. There could be many value streams within a single organisation.
How do we identify a value stream? Typically we start from a valuable customer outcome (for example a deliverable) and work backwards through the organisation to identify the value stream which leads to it. Remember there can be multiple value streams in an organisation, as the organistion may be delivering multiple products, customer services and internal services.
Below we have a simple value stream from hypothesis (the lightbulb) to value (the diamond). This might be typical for a software product or a new software feature.
- We make a clear enough definition of the concept, perhaps as a set of user stories and acceptance tests.
- We create enough initial design to satisfy the concept’s needs
- We develop the artefacts (code, documentation, tests) to address the needs of the definition and design
- We deploy the artefacts in customer-facing systems (such as a SaaS product)
It’s worth noting that a value stream is not the same as a customer journey. The value stream is within the organisation and delivers at a specific point on the customer journey. While we may mostly consider the value stream for delivering to the customer when they are using the product, we could have a separate value stream for delivering what the customer needs to explore the product initially.
Value Stream Management
Why does a value stream need managing?
The objective of value stream management is to optimise the flow of work which delivers value through the value stream. This is performed by measuring outcomes to make better decisions across the organisation.
By focussing on a value stream, we can identify which parts of the process add value and which are non-value adding waste. We can then continually improve the processes to reduce the waste.
All we are doing is looking at the time line, from the moment the customer gives us an order to the point when we collect the cash. And we are reducing the time line by reducing the non-value adding wastes.
Taiichi Ohno
Let’s consider why this is a challenge and why the value stream needs “management”.
We are used to simple organisational charts such as the one on the left below. But a value steam does not follow the organisational chart. When we map the stream, we may find it moves across the organisation, perhaps following the dotted line on the right. Ideation is in one group, activities are across multiple groups and value is delivered by a different group.
We are used to working with hierarchies and for a manager to have oversight over an area of work. The weaker the links between parts of an organisation, the more problem a cross-organisational value stream will cause. Ideally we can solve this the Agile way by building cross-functional teams to allow a single team to cover an area of work, minimise handovers and maximise self-management. In Takeuchi and Nonaka’s original vision, this is exactly what we would do, with the team operating as a wholly independent organisational structure.
In most cases however, a value stream runs across the organisation. It is rarely possible to keep it within a single team, even with cross-functional teams. It’s challenging to fully comprehend an end-to-end value stream since any individual can typically only see a portion of it.
This then leads to a huge risk of local optimisation. Without end to end visibility, we optimise our local part of the value stream, perhaps the coding, when the key constraints lie elsewhere. If we are good at developing software, but weaker at deployment, those coding optimisations will have little overall benefit. Worse still, by developing software faster we may be overwhelming our downstream deployment team even more.
Good Practices
As an Agile leader it will be important to implement continuous improvement and to increase the level of flow in the organisation. Mapping the value streams in the organisation will be a good first step here. Be aware this is significant work to do well. You will need to work collaboratively across the organisation as the value stream itself is cross-organisation. However, the investment will prove more beneficial than local optimisation of what you can currently see within your own area.
When working with a scaling organisation, mapping processes and value streams is often a good place to start. It helps to ensure a common language and understanding and allows you to identify places to work on improvement. The need for value stream mapping often becomes apparent when bottlenecks and inefficiencies start to appear.
Leave a Reply