I’m embarrassed to admit that, as a long time Agile coach, I hadn’t appreciated the benefits of burn-up charts over burn-downs, merely seeing it as a mirror image - I was wrong.

However it has brought me to this metaphor of landing the project in a zone where two joysticks, held by different stakeholders, guide in the project (or MVP or ‘next release’). The PO (business) holds the scope ‘joystick’ whilst the team adjusts the ‘throughput rate’.

Being co-pilots in this joint endeavour helps foster collaboration between the two ‘sides’.

i find that the most insight-generating metaphors are simple and incorporate a familiar aspect of our physical world.

Make the most of the historical data we have

Our historical data of ‘completed work’ shows the rate of delivery (velocity). Which we can extrapolate into the future using pessimistic and optimistic rates.

A vertical line down from where these cross the scope line, gives us a date range that this project will finish. In this case I’ve assumed the scope doesn’t change after today.

The angle of those pessimistic and optimistic throughput rates is largely determined by the team and overall system effectiveness.

Note: We currently use simple calculations to decide the angle, e.g. optimistic (median +25%) and pessimistic (median – 25%). Alternatively a moving weighted average works well too.

Not forgetting the ‘S curve’ that David Anderson writes about here

This shows there is often lowering of the throughput rate in the last 20% of a project – assuming that the definition of done was not quite perfect – which is common!

We are also developing projections based on ‘probabilistic forecasting’ and Monte Carlo simulations to provide more clarity on the likely outcomes. Troy Magennis has been leading this approach in the Agile world – this video is a great introduction

Step 2 – Scope evolves

We know the scope line will probably continue to drift upwards, in fact there are probably two future scope lines:

1. The desired scope that was in the business plan and stakeholders thought was necessary when the project was first conceived.
2. The minimal scope, or MVP, that would deliver value to users, generate learning and is a viable delivery.

We need to develop better ways to model this change in scope, however we’ve all seen this in projects, even if the root causes vary.

There are two possible date ranges within which this project will go live.

• Minimal scope = mid-June to early-August
• Desired scope = mid-July to mid-Sept

The Landing Zone

It’s easier to visualise and to say, with a fair degree of confidence, that the project is going to land somewhere in this green zone.

Representing the truth in this comprehensible, palatable way stimulates many more possible interventions, for the team and business, than a RAG status ever could!!

Options to hit an immovable date

To be confident that we can launch at that conference in mid-August, we can see what options we have to reduce scope to come within the pessimistic line.

It’s also clear that we will at least have the MVP by the conference and possibly a little more.

The simplest illustration of the benefits of focus must be this one – clearly illustrating that if we focus on _and finish_ one feature (or project) at a time then all 3 features are delivered quicker.

Agile emphasises delivering value sooner – in order to generate revenue, create lessons and validate assumptions.

1. In the ‘current situation’ all three features are started as soon as they are requested – but none are finished until near the end.
2. Focusing on one at a time means that A and B are delivered value sooner in the second example
3. However, many studies (e.g. in Tom DeMarco and Tim Lister’s book ‘PeopleWare’) show that there is a real cost in switching between tasks.
   Therefore, assuming a saving of only 10% – we see that all three features are delivered significantly sooner. This is not just a marginal gain, it could translate into weeks of additional sales.

As well as the benefit of earlier value and lessons – don’t underestimate the energising effect on a team that delivering A, and knowing it’s in the hands of users, can bring. Focus increases the ‘realness’ of the work and sense of achievement and recognition that the team.

Focus also means more collaboration within the team, which can only bring a better solution – creatively built from multiple perspectives.

The intuitive assumption is that the sooner we start something the sooner we finish it…

… the real challenge is how to adjust the behaviour that’s driven by this assumption, which often recurs at every level of the organisation.

Tweet.

The delivery pipeline is an idea which resonates with our clients. The simplicity of the metaphor and the truths that it reveals make it a compelling message to share with others in the organisation.

The pipeline helps to visualise two key Lean principles; seeing the end-to-end value stream and ‘optimising the whole’ http://bit.ly/ImpLean It illustrates the emerging emphasis on Continuous delivery’ http://bit.ly/CDAgile

The overall organisational aim is to balance the pipeline, as any constrictions generate waste.

The pipeline helps with the key challenge of getting senior stakeholders to prioritise and budget the money, and time, to balance the pipeline end-to-end.

Instinctively, because developers create functionality then, if we want more functionality, we must need more developers. Whilst jarringly simplistic, this is a perspective held by too many senior stakeholders.

However, adding more developers or teams, immediately leads to an imbalance in the capacity of each section. More development teams develop more code, which we then try to force through the lower environments – where it sits, wastefully, in queues or trying to muscle its way past other projects waiting for a limited slot in a integration test environment.

In addition to the waste, the quality plummets due to the stress of trying to get work through this constriction. A situation that is often made worse when these downstream environments are shared with other projects / programmes.

Similar constraints usually exist upstream of the developers. The Product Owner role is new to most businesses and the level of on-going work they need to do is often underestimated. Beyond the responsibility for preparing stories every sprint, collaborating with the team on a daily basis, POs need to actively engage with stakeholders and users.

The diagram below illustrates the actual capacity of the pipeline, which can be quite an attention grabber. It’s troubling for senior stakeholders to realise they are paying for all that under-utilised development capacity.

Steps to a balanced pipeline

Step 1: Communicate the need of optimising the system end-to-end

Use the pipeline diagram to communicate the essence of the challenge. These issues are difficult for even IT people to see and understand, even though they live with the stress of these systemic shortcomings on a daily basis. Create a sense of urgency by providing estimates of how much this waste is costing, both in money and in delayed value to customers.

Step 2: Prioritise and target specific interventions at the points where they will have most impact

• Investment in the environments, automated testing and deployment tools to ensure frequent/continuous movement of software through the environments to live
• Improve the quality and frequency of collaboration across traditional organisational boundaries, e.g. between developers, service introduction, support and infrastructure.
• Improve ways of working upstream between Product Owners, stakeholders and the teams. A clear vision with stable portfolio backlog is more likely to create a steady flow of high priority work into the development teams.
• The teams themselves can improve quality and throughput by adopting Agile/XP technical practices and working more closely with both the product owners and the ‘downstream’ teams.

Step 3: Visualise the waste with a value stream map

Visualisation and quantifying of the waste is key to building a sense of urgency for change and then targeting interventions at the most wasteful sections of the pipeline.

Value stream mapping is the simplest and most effective way to identify where the biggest queues and worst bottlenecks are in the system. The best resources on value stream maps are Mary Poppendieck’s books, including Implementing Lean Software Development’ http://bit.ly/ImpLean

Real-time visualisation of queues is best done with Kanban techniques, which can highlight emerging issues in the system.

Step 4: Get senior stakeholder support and the budget and time

The level of investment needed in environments and tools are often new to a business, which may not be clear on the sizeable returns available. These returns are often in the form of reduced waste, which many senior stakeholders can’t see or evaluate – even though they can sense waste all around.

A senior director estimated that 50% of their software development expense was wasted. How have we ended up accepting, or not able to deal with, this level of waste?

A smoother flowing pipeline also reduces cycle time, meaning that profit-generating functionality is deployed sooner.

Whilst getting the budget is difficult enough, ensuring the work actually gets done, month after month, is even harder, given the prevailing culture in many businesses.

Businesses and managers are rewarded for delivering value to customers. Few businesses reward managers for improving the capability of their system to deliver value.

It’s common to recognise the sacrifice in fixing problems – rather than rewarding those who prevented the problems in the first place.

The ‘non-functional’ work needed to improve system capability is difficult to value and prioritise in any company-wide backlog of work. Those that understand the potential benefits of a balanced pipeline need to articulate that value and be prepared to be held accountable for delivering the promised benefits.

This cultural bias, towards delivery and not improving the means to deliver, continually sabotages attempts to balance the pipeline.

Step 5: Expect resistance and be in it for the long haul

The value stream maps highlight that many constrictions occur at existing boundaries within the organisation. The delay, hand-offs, lack of visibility and accountability at those boundaries are the biggest challenge to creating a balanced pipe.

These changes to what people do, how they work with others, changes to accountability and their daily work will generate resistance.

Specific action is the best way to ignite the change. People on both sides of the boundary typically suffer from its existence and are often keen to improve the situation.

And… it’s not just the pipeline… but the shape of what you put down it..

In addition to working on the pipe itself – the throughput will be significantly improved by looking at the material going through it. This is the subject of a follow-up blog, where we’ll look at batch size, variance and work-in-progress as key variables.

In the meantime, Mary Poppendieck already has some good insights on this at http://bit.ly/LeanPipe

Tweet.