Agile Is… Never Having To Commit To A Deadline?!?

Is there a way to shave years off of the trial and error implementing Agile?
Find Out Now.

7. Agile is… Never Having To Commit To a Deadline?!? // The world of business is full of deadlines. But deadlines and Agile don’t seem to mix. Picture the scene:


– Location: a small conference room.
– Present: a Software Development Team, an Agile Coach and a Business Manager.
– Subject under discussion: the launch of a new website.

It was all going well until the Business Manager asked this question:

“When will the website be finished?”

Oh dear.

Enjoy the video.

Music: 260809 Funky Nurykabe:

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

Related posts: