How to optimise a Value Stream

When faced with problems it is easy to rush into making changes in your own team to respond. It is always easier to work with what is under your control than to try and work cross-organisation.

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 the waste is occurring.

In this example, we will work through how to optimise a simple Value Stream for the development of a new software feature. The teams involved have met and discussed and mapped what the Value Stream is. In this example we have four stages involved, all managed by different teams in the organisation.

• Define: Initial definition of the feature is done by a product manager and typically takes a week
• Design: The work is then put on the queue for the design team. Design typically takes two weeks, but there is always a backlog and it takes six weeks for the new feature to work through the queue.
• Develop: An average feature will take around four weeks for a development team to complete. There is a single development team and a new feature is typically picked up in around four weeks
• Deploy: Releases happen twice a year and the deployment team take around 6 weeks to package and deploy the feature for the release. For this example we are initially assuming that we deploy a single feature in each release.

We can draw this as a value stream map as below, showing the activities, the duration of each and the time elapsed between each activity. Note that the Value Stream Map is schedule based, not effort based.

How good is the flow?

It is probably obvious that our example is not a very efficient way to work, but let’s look at how we might analyse this value stream using Lean metrics. This gives us a chance to introduce some of the key metrics which we would use.

Lead Time – The lead time is the overall elapsed time from hypothesis to value. In this diagram we sum up all of the schedules of activities and handovers to get 36 weeks, or around 8 months. Clearly we have a very slow process to get value to the customer. It looks well worth doing this exercise to make improvements.

Delay Time – The delay time is the total time spent in handovers between activities. This is 23 weeks out of our 36 weeks. Since handover delays are a typical area of waste, this is going to be a good place to start when looking for improvements.

Flow Efficiency – The flow efficiency is the fraction of time where there are activities. This is 13 weeks out of our 36 weeks or 33%. It seems we have a process which is a long way from good flow as most of the time deliverables are waiting for attention.

Value Add Time – The Value Add Time is the total time spent in activities which directly increase the value experienced by customers. This would probably be the Design and Develop activities. Define and Deploy are internal activity which do not directly add customer value and so are “waste”. Remember that Lean is very harsh here – “waste” does not mean we can immediately stop doing them, only that the customer does not directly gain value. If we had a different way to capture needs (Define) or deliver software (Deploy) the customer would be equally happy. Value Add Time is only 6 weeks out of 36 weeks, or 17%.

Throughput – How many items can we deliver in unit time? The longest activity is deployment, at six weeks. Assume (for now) it takes six weeks to deploy each feature, then we can only deliver one feature every six weeks.

Work in Progress – By Little’s Law, if the lead time is 36 weeks, and the throughput is 1 per 6 weeks, our work in progress is 36/6 so we have around 6 items in the value stream at any time.

Local changes don’t help with flow

Our metrics are not good. Senior management are concerned and we want to improve the situation. In many organisations, individual teams will run their own improvement activities. What is the likely result of these local optimisations?

Product Management

Product Management are probably feeling frustrated. It only takes 1 week to define a feature and yet we deliver only one feature every six weeks. A common reaction is to feed more work into the system. Product management can propose more features and increase the rate of feature definition to 1 per week.

Will this increase throughput?

Unfortunately not. Our throughput remains limited to one every six weeks due to the deployment constraint. All that will happen is that work in progress will increase. Queues will develop before each of the slower activities, increasing stress. With more work in progress, each new feature will also take longer before it can be delivered.

Pushing more work into the start is a common reaction but has a negative effect on the overall process.

Engineering

Engineering is also feeling frustrated. There is upstream pressure from Product to deliver more. A frequent response is to ask for more people. So let’s imagine we build a second engineering team. We assume that teams are cross-functional and could pick up any feature.

Will this increase throughput?

Unfortunately not. Our throughput remains limited to one every six weeks due to the deployment constraint. And because we are only moving at that speed, the second team has no work to do.

If Product Management also pushed more work into the system, this would give enough work for a second team. Sounds great? But those features would simply sit in handover C, waiting for deployment. We would still be limited to the same throughput. The extra people have no benefit.

Address the constraints

If we want to improve the overall effectiveness of the teams, we need to look end to end. We need to identify the constraint which is preventing efficient flow and address that constraint. Having done that we can address the next constraint and so on. This is the purpose of Value Stream Management.

In this case, our throughput is limited by the six weeks taken to deploy a feature. Of course, this constraint is artificial for this example. The deployment team may spend six weeks on a release, but that release could realistically include multiple features.

1. So for our first step, let us allow the deployment team to include multiple features in a release. Now the six weeks will still affect lead time, but has no effect on throughput (if we assume the team can cope with any number of features in one release).
2. What would now be our limit on throughput? The engineering team limits us to one feature every four weeks. Now we can apply the plan to have a second team in parallel. That would mean that engineering can manage two features every four weeks. And as a bonus we are waiting less long for the team to become free, so handover B decreases.
3. Finally we could look at our longest delay time, which is handover C. Let’s move from two releases a year to four releases a year. That will reduce the average time waiting for a release to six weeks.

These three steps then can constitute our first plans for improvement. These would take us to a future state as below:

What are the values of our key metrics under the new system?

As we can see, most of the metrics have seen a startling improvement. We are now shipping more and faster. The only negative indicator is Work in Progress. This has increased because we have a higher throughput, putting more into the system, but a relatively low reduction in lead time.

Ideal State

The future state above represents the target for the next stage of our organisation, and it will take a time to get there. However, it is also valueable to consider an “ideal state”. Where might our improvements lead us if we continued to address bottlenecks. There will be increasing cost and disruption from these changes, and it is valuable to build a business case by agreeing what the end goal may be.

To agree an end goal we must consider what level of optimisation adds value for the organisation. One valuable concept here is “takt time“. “Takt” is the German word for a conductor’s baton, and in Lean approaches “takt time” is the rate which we are targeting to satisfy customer demand. How frequently does the component or product need to be produced and how fast will the customer consume it? If a customer will only take annual releases, is there a business case for optimising delivery beyond that point?

In our case we could propose that the next steps in optimising the value stream might be:

1. Continue to reduce the deployment frequency. If we introduce a continuous deployment (CD) process, we can remove batched releases entirely, taking away the delays around deployment.
2. Add two more parallel development teams, to allow four features to be developed in parallel. An equivalent might be achieved by reducing batch size, and making the features smaller. More teams will also reduce the upstream handover B.
3. As there is now a constraint on the design team, add a second design team. This will also reduce the upstream handover A.
4. Increase the integration of Product and Design to reduce the handover time A even further.

We could imagine an ideal state something like the one below.

What are the values of our key metrics under the ideal system?

We can see the potential for dramatic improvements from the original, wasteful, process.

Good Practices

As an Agile leader it is easy to rush into making changes in your own team. However, as in this example that can be ineffective and even detrimental to the overall objectives of the organisation.

Value Stream Management gives an alternative viewpoint of looking across the flow through the whole organisation. We assess bottlenecks and find areas of waste. This allows us to target interventions to get the maximum possible effect.

It is more complex to work across the organisation and to include everyone involved. It can even seem daunting if the organisation is heavily siloed. However it can be far more productive to work this way.