Are we nearly there yet?

The goal of software delivery is to minimise the lead time to business impact. Everything else is detail.

The longest journey ¶

When I was young our summer holidays usually involved a drive to somewhere on the south coast of England. From where we lived in London this would be a 5 hour journey for a regular driver, or around 8 hours for my father, who never drove above 40mph. Almost as soon as the car was moving, one of us kids in the back would ask: “Are we nearly there yet?” We had no sense of time so we would pick up this refrain from time to time for most of the journey. When the first one of us “saw the sea” (“Where? Where?”) it was the highlight of the day!

We write software for a reason: to support a business need, provide or enhance a capability or address an existing situation in a new and innovative way. At the outset of the journey we want to be confident we are likely to get there. We don’t need all the resources up front but we want to know we have access to them. Our car journey used to require filling up with fuel on the way. My father knew there wasn’t enough fuel in the car to get us the whole way but that didn’t worry him—he had a plan. And stopping at a service station meant he could refuel himself and us kids too.

All the way to the coast, the only thing on our minds was: are we nearly there yet? When you commit to delivering a capability to a business stakeholder, that’s pretty much all that’s on their mind too. Unfortunately we’ve got into the habit of reporting progress rather than how far is left to go. I suspect this is due to a historical mutual distrust leading the delivery folks to feel a need to justify their existence.

Looking the wrong way ¶

This is how a sprint showcase often goes:

- “How is the project going?” - “Since we last spoke we committed to delivering seven new features and managed six.” - “Um, OK, great. What happens now?” - “Now we commit to some more for the next time we meet.” - “Right, let’s do that then.”

What’s really being said is more like:

- “Are we nearly there yet?” - “Since you last asked we went through six motorway junctions, which was good, but we got stuck in some roadworks.” - “Um, OK, great. Doesn’t really answer my question but I guess it’s progress. What happens now?” - “We have a discussion and commit to covering some more distance for next time.” - “Well if distance travelled is the only metric we have I guess I’ll have to pretend it’s OK.”

When we started the project we said we would speed up their sales order process. Or reduce the amount of rework for processing settlements. All they want to know once we are under way is: Are we nearly there yet? How soon can I enjoy my faster sales order process, or see the savings from the reduced settlements rework? Instead we tell them how much ground we’ve covered, usually in terms of features we’ve delivered. Burn-up, burn-down, throughput, they are asking how much more is in front of us, we’re answering with how much is behind us.

Our rationale is that we can apply this historic information to our guess at what features are left to deliver, and estimate when we’ll be done. Of course this journey metaphor doesn’t really apply. I can look at a route planner and figure out how many miles are left. I can even ask my planner how long it thinks it will take. The planner will lay out every turn and junction with distances and estimated timings. That’s easy with a well-known route.

The goal of software delivery ¶

A better metaphor might be climbing a mountain. An experienced mountaineer can look at an unfamiliar peak and estimate how long it will take to climb, what kind of team they will need and what equipment they should bring. Once they start climbing though, everything is contextual. They don’t know when or where they will attach ropes, where they will rest, or which route up might be easiest. They may go a fair way up a promising-looking ascent and then discover a crevasse which means they have to double back a distance. Everything they are learning will help future climbers, of course, but the choices this first time are down to experience and luck.

Even this metaphor is a little lacking. How about sending multiple mountaineers up multiple paths simultaneously, and have it not matter which one of them gets to the top first? Let’s have them all communicating with one another while they do it, so if one of them learns something, they all learn it. The pay-off of having one of them get to the top will outweigh the expense of the additional climbers. This is analogous to having the team try multiple ideas simultaneously: it’s less efficient but more effective than trying one at a time, or more commonly choosing one approach and sticking with it come what may.

So here’s the punchline. I believe the goal of software delivery is to minimize the lead time to business impact.

Let’s unpack that statement. Lead time is different from cycle time. It’s the time from first wanting something to having that thing available—the elapsed time from the customer’s perspective. This includes all the necessary priming of the system, as opposed to cycle time which is the average time for a single piece to flow through a system once everything is up and running. Optimising for cycle time of features, for instance, may not globally optimise for getting to the top of the mountain, the business impact. All that setting up of the pipeline or polishing the artefacts can be a huge time sink. It’s easy to obsess about tuning and oiling the machine and lose sight of the fact that the goal is to drive it. Here’s a conversation I had not so long ago:

Me: Look at how this code turned out. Isn’t it lovely? I’m really pleased with it. Him: Hey, nice-looking code. Is it live yet? Me: Not yet, no. Him: Do you know if it does what they want? Me: It does what they asked for. They liked it in test. Him: How soon can you get it live so they can check it out for real? Me: I can get it out today. Him: Great! How soon could you have got it live? Me: …

Of course I could have realised the business impact of that code sooner by being more focused on the goal and less on the beauty of my code. I’m not suggesting hacking out crappy code, or not taking design and programming seriously. In fact I’m suggesting the exact opposite, that the degree of care should be directly appropriate to optimising the lead time to business impact. And not just the nearest business impact, but sustainable impact over time. Mountaineers don’t scramble up mountains, or dash from peak to peak. That’s not how you get to the top quickly, that’s how you get dead quickly. Instead they apply the appropriate amount of care. They walk quickly along flat terrain and use pitons for the ascents. They rest when they are tired. They could use pitons all the way up, but then they would get through a lot of pitons and make unbearably slow progress. Sound familiar?

It’s taken me a long time to realise the implications of the phrase “business impact”. Gojko Adzic has been talking about impact mapping, which uses a Real Options planning approach of starting with the impact the business wants to make, and working backwards to figure out multiple paths to achieve it. The goal is not necessarily to deliver features or business functionality. Perhaps you can create business impact by suggesting those two people in different buildings sit next to one another. Now the miscommunication that caused the problem that prompted the original system request goes away. Immediate impact with no software!

Business impact isn’t necessarily a big bang ¶

There are a number of sound agile principles that come from this goal of minimising the lead time to business impact. The impact could be lots of little bangs: small, interim incremental releases. Many business cases can be sliced into pieces, each of which contributes to alleviating the pain or opening up the opportunity. “We need to be trading in Asia.” Sure thing, let’s set up a guy in an office with a phone and a notepad. It’s not scalable and there will be communication overhead, but look at us, we’re trading! We quickly follow that up with a more robust operation that replaces the original piece. Truly iterative delivery rather than just incremental. The interim business impact more than pays for the disposable solution.

The tyranny of the backlog ¶

So how does this apply to my carefully-constructed product backlog? We planned out the backlog as a team, estimating and discussing each feature, we groom it regularly in Product Backlog Review sessions, we have a good idea of where we are heading and how long it will take to get there. Your mountaineer metaphor thing doesn’t really apply to me.

Well maybe not, but perhaps it does. When you build a product backlog you are defining one possible future. There are many paths up the mountain, many ways to skin the cat, many roads to the metaphor of your choice. Sure we all know we’re allowed to remove things from the backlog, change priorities, add new things, but mostly this takes the form of fine-tuning of an assumed best path. When is the last time you deleted the entire back third of your carefully-estimated backlog? How about more than half? Did you feel a little sick when it happened, thinking of all that preparatory work you were throwing away, or has it simply never happened?

Say you split your software delivery schedule into three chunks: today, tomorrow and the remainder. You can safely make this assertion: Today is the only time in that whole schedule you will know less than you do tomorrow, and the remainder is the only time you will know more. Right now is as ignorant as you will ever be about what you are currently doing. This is a rolling truth for every day, which means that any day you choose to plan out more than a few days of detail you are guaranteed to be more ignorant than at any later time.

Are we nearly there yet? ¶

So why do we do this? Why is the advice to prepare “a few sprints” worth of work to deliver? It comes back to that fear of uncertainty. The more detail—the more precision—we can apply to a plan, the more we can convince ourselves we have certainty of direction. The pseudo-science of Fibonacci estimation, min/likely/max story estimates, risk percentages and all the other agile planning gubbins gives us a feeling of confidence. More specifically for our business stakeholders, those poor, long-suffering folks with the look of fear, frustration, desperation or anger in their eyes, it gives them a feeling we have a chance of delivering their solution.

Instead we could embrace the fact that today we always know more than we did yesterday, and that tomorrow we will know even more. We can take a fresh look up the mountain every time we pause to regroup, to plan. So our sprint/iteration/periodic planning sessions become more like this.

Given where we are and what we have learned so far:

1. What next action(s) would give us the shortest lead time to business impact? Technically this is where we collapse our immediate portfolio of real options into a set of decisions. Should we try exploring several alternative paths, creating a new portfolio of options? Or just crack on up this trail which seems like the best way for now? Is there some interim strategy that would deliver partial impact?
2. What activities might surface information that would materially affect our understanding of how much is left? What action is most likely to tell us this isn’t like the other mountains, and invalidate our assumptions? Can we look ahead and see the bridge is out, so we aren’t nearly there yet after all?
3. What should we be doing to assure our stakeholders we are moving towards the goal? In order to achieve the impact we need to be allowed to move forward.

Let’s remember who we are doing this for. We need to bring the stakeholders on the journey with us and we want them to be invested and participating. Better to have them looking ahead and getting excited about seeing the sea than sitting in the back asking if we’re nearly there yet.