Agile is... Never Having To Commit To a Deadline?!

Are you responsible for a SOFTWARE DEVELOPMENT TEAM?

Is your team an AGILE Dev Team?

Have you ever had a “difference of opinion" with your team?

Or a full-blown argument?

Were you, by any chance, discussing an important DEADLINE?

The world of business is full of deadlines… but deadlines don’t necessarily “compute” for an agile team.

But there may be a way of both sides to get what they need.

Hi this is Gary, welcome to Development that Pays

Picture the scene.

A small conference room at the BBC in White City.

In attendance, a development team

our Agile Coach

and a Business Manager.

The subject under discussion: a new website for BBC Worldwide.

My memory of the first part of the meeting is hazy. But I have a very clear recollection of what happened after the business Manager asked this question:

When will the website be finished?

It was clear he wan’t looking for an answer like “ next Spring”. He was looking for a date.

We turned to our Agile Coach for the official answer. But Mr Agile refused to answer the question.

Mr Business was taken aback.

Really? Surely we had some idea?

After all, the people in the room had has previously build several similar websites. If anyone know how long it would take to create a site very-like-one-we’d built before it was is,

But the Mr Agile would not be moved.

He could not and would not commit to a date.

Mr Business was incredulous. Didn’t we realise that launching a website is a bigger thing than just building a website:

Editors need to be hired Copy needs to be authored Launch partners need to be engaged

WE NEED A DATE!

But Mr Agile would not be moved. The rest of sat in silence staring at our shoes….

The argument between Mr Business and Mr Agile troubled me. And not just because it was toe-curling awkward.

Here’s my dillema:

I agreed with Mr Business : I could see that there needed to be a launch date.

I also agreed with the Mr Agile : launch deadlines and the agile approach don't really mix.

Can the two really co-exist?

At the time, I really wasn’t sure that they could.

But I think that maybe they can.

Let’s take a look.

I don’t know much about Mr Busenss' background, but it’s not much of a stretch to say that he was used to working to deadlines: he did, after all, work for a major broadcaster.

Programmes go out at specific times on specific dates. There’s zero time flexibility.

So he’s used to projects that start slowly… and ramp up…

and things would ramp up again as the broadcast date arrived.

That’s a graph of effort.

But what about a graph of value?

More specifically, customer value.

Well, for almost all of the project, the value to the customer is zero.

It’s only towards the end of the project that all of the elements come together in a programme.

In fact, it it’s a sign of good project management when things DON’T come together until the last minute.

What about an Agile project?

What does the customer value curve of an Agile project look like?

It might be a while before anything worthwhile can be released, so the line starts at zero.

But it’s not long before something is released*. A very base-bones website, for example.

Now I’m not suggesting that a bare bones website is released to the public...

But at this point, and at any point in time after this, we have something that could be released to the public.

At this early stage the potential customer value - lets call it that - would be low. Say 10%

The potential customer value increases as the team adds new features.

One of the key tenets of Agile is to work on the most important features - the features that add the most customer value - early in the process.

So the value curve increases quickly as this high value features are added.

We then enter a phase of diminishing returns as low value features are added.

Overall we have an s-curve

We’ve ended up with two very different value curves.

But can we reconcile them?

Can we present a picture that Mr Business and Mr Agile can live with?

Let’s superimpose the lines.

Clearly this is bad news: the launch is happening way to early

What about this case?

Well, the value level is up… but things are changing fast: it would be tough to predict the level of value on any particular date.

What about here.

This is really the sweet spot. And not just because the level of customer value is high.

the curve here is flat: the level of customer value is changing slowly. which means that there’s very little difference between launching here and launching here.

In words that Mr Business would understand:

the risk of launching in this period is high the risk of launching in this period is low

Mr Agile would never have committed to a “finishing the website on a specific date".

But he could have drawn a fairly accurate value curve.

And Mr Business could have used it to fix a launch date.

Where there was conflict there could have been harmony.

Talk to you next time.