The "no such thing as done" thing is just part of the agile post-modern philosophical mumbo-jumbo that gets in the way of the methodology being useful. It is the typically immature attitude that every software project is some internal corporate IT chore or web-thingy that can be rolled out in unlimited increments. I'm quite fascinated to see that some agilists understand that there are stakeholders who expect schedules and deadlines, and all the agile shucking and jiving in the universe won't talk them out of things they actually need.

Some programs have to be "done" on a calendar date. Don't get your y2k fixes in by december 31 and guess what, crash boom! Don't get your features done in time to ship for Christmas and you miss 3/4 of your revenue for the year. Don't get your embedded code "done" and your contract manufacturer charges you a 30% premium for expediting to meet your original schedule commitment, and profit turns to breakeven (if you're lucky). Hello! Most of the world is all about "done". Anyone who says otherwise is either living in a bubble or they're in denial.

You keep on writing articles about agile development. You like the subject area but cannot seem to embrace the essence of it. Your article doesn't say anything. It just seems to be filling space.

An agile project clearly needs to be delivered on time. Without a reasonably clear idea of time and deliverables then you are not talking agile but something called Soft Systems Methodology. An agile project approaches the end point in a different way to a structured methodology. The end result is however essentially the same except much quicker, cheaper and more enjoyable for the people involved.

At Golden ROM date, the code is finished. Or you are.

Kurt, I couldn't agree more. It seems that 'agility' can end up as a convenient smoke screen for not taking responsibility for delivering something to specification and on time. It's a shame that while the business making the IT investment (i.e. paying for all the code) has to exist in a real, competitive environment, and will go to the wall if it can't cut the mustard, the droves of artfully pierced and scruffily attired kiddie winkies cutting code can just shuffle off to their next contract without facing the consequences of any failure to deliver, once the project is er, 'done'. Or not. Like, whatever.

"a fundamental tenet of agile planning is that the dates are fixed but the scope may vary"

Ah right. So by May you'll have what I want. Only it won't be what I want because you'll have 'redefined the scope', but I'll certainly have whatever it is by May. Nice.

I wonder if you'd accept this kind of logic from a plumber - "See mate I can't fix your leak today - hell I can't even stop it today - but I can have ordered the parts". Not really what you want to hear as a customer if the plumber's promised he'll fix your leak by tonight is it?

There's no wonder IT development has a reputation for being unreliable! If you don't know in exacting detail what's required, by when, and what impact each thing will have on your customer if it's not delivered on time and bug-free then your skills as a project manager can't be up to much, can they? You wouldn't get away with this kind nonsense in the heavy engineering industry - "I can't have my Petronus towers by next Wednesday you say? You're sacked!" - and if IT really wants to be considered a serious industry it needs to step up to the challenge or f-off.

Simon, I think you have miss-understood agile somewhat. For a start, one of the fundamental principles is the involvement of the customer in decisions such as what is de-scoped from the project. You commit to a deadline, if you cannot make that deadline for various reasons, you explain to the customer and they then decide what they want to have or not have, so your analogy is somewhat inaccurate. What should happen is the plumber would say "I can't fix this leak by tomorrow because there is a worldwide shortage of washers and they are very difficult to get hold of. However, instead I could apply some kind of temporary fix in the meantime or whatever else might fit with you."

As for not knowing the impact on the customer, what is required etc. again this goes against the principles of agile of customer centered focus and having them on board for the project with you to make key decisions. If the team has been 100% transparent and ideally co-located with the customer then you wouldn't be in the kind of situation where you see a customer baffled as to why their entire project cannot be delivered on time without de-scoping certain aspects.

Agile is, in my opinion a far more realistic way of running a project. In reality how often are projects given realistic deadlines that they meet? You might be sold the idea that you can have the Petronas towers in a week with some impressive figures, but an agile team should give you a more realistic timescale for what that team can deliver and by when. If wembley stadium was agile, for example, and it was essential that it was done for a year ago, we might have ended up with a stadium without the impressive arch rather than a complete stadium a year or so too late!

I am beginning to think the best way of getting on in software development is to write a book pulling some good practises into book and giving it a "funky" name.

Coming from an Electronics Engineering background, I find it amazing just how many ways software people can express the same ideas which have been used for decades in other disciplines without the need for fancy names

Mean while – time to carry on fixing this "Agile project" to make it what the users really want, not what the original "agile" coders created

...software development would be a whole lot easier.

As it stands, and to stretch the metaphor to breaking limit, what the client believes is a problem with the taps could be the pipes, corrosive water, or the sink.

Never mind using 'never done' as a smoke screen, how many times have contracts been used to insist that the client got 'what was specified' even if the system is a pile of junk? Stupid client for not knowing what they want! After all, you don't call out a plumber to fix your taps, find out that there is a hole in your feed pipe, and insist that they fix the problem, do you? No, you insist that they replace that perfectly good tap.

Agile projects can have deadlines - the only ones that wouldn't are those where something is continually developed and improved in-house, such as online retailing. That makes sense. I don't know of any Agile developer worth their salt who would begin a project without a clear idea of when it is expected to end.

The difference is that Agile, with that end date in sight, has mapped out a series of iterations with reasonable goals. This approach leaves room for changes in requirements, and provides reasonably tight, though not oppressive, checkpoints to follow the project's health and progress.

I wish I knew where this 'warm, fuzzy agile message' was. If you run an agile project as one of the poorly run agile projects Matt describes, you're not doing agile development. You're an idiot.

Agile development is Still Hard Work. You still have to graft, you have to think, and you have to be mentally on top of things. What you don't have to do is a lot of stuff that impacts your ability to deliver the software. What you must, absolutely _must_ do is manage the project properly, as Matt says.

Well, I say 'as Matt says', but I managed to pick this up from my interpretation of that 'warm and fuzzy message'. If you spend a day refactoring code to a better pattern design, you had better hope that this is in your 2-week plan, _and_ signed off at the morning meeting. If there is more important stuff than moving functionality around, I would be surprised to see something like that get past a morning meeting. Or are we talking about people who say 'agile looks good, but pair programming looks like it sucks, and I don't really like tests while coding, and morning meetings are no good, and there's no way we can deliver what we promised in a 40-hour week, and... and... and...'

That isn't agile. It's also not part of the agile message.

This is the kind of writing that I imagine would be pretty good if you wanted to convince people that you had written a book that 'fixed' agile. You know, finding 'problems' and then 'addressing' them, albeit with solutions that are 'already' part of the process you are 'refactoring'.

Hmm... Matt, haven't you written a book about this somewhere? Oh yes, there it is plugged again :)

"artfully pierced and scruffily attired kiddie winkies cutting code"

----

Close - except I'm only "scruffily attired" outside work.

Anyway...

However agile your development process it makes little different if the client moves the goalposts. You agree to get features XY AND Z in-place, by a given date, to meet the agreed "go-live" date. You can give the customer the pig they wanted, it's pink-ish, goes oink, provides sausages and bacon, marvellous - 3 weeks into the project and they want it to fly too AND glow in the dark.

The point, I guess, with agile development cycles is that you can re-prioritise the properties of the given pig... it can fly by the deadline, but you don't get bacon, OK?

"I can't fix this leak by tomorrow because there is a worldwide shortage of washers and they are very difficult to get hold of. However, instead I could apply some kind of temporary fix in the meantime or whatever else might fit with you."

But that dosent answere the point that programing should not be a fix. Its more like saying "Yes sir, we know we said we would deliver you a brand new kitchin by today, but we didn't bother to check we had any sinks in stock befor we sold one to you." Very lax.

In my opineon alot programers (And most of the IT industry) hide behind the fact that most people dont realy know what they are doing. Some are no better than the Dodgy car mecanics of old who would charge Women more and make you pay for work they never did.

Kurt, Simon et al, your insistence on defining everything up front ("If you don't know in exacting detail what's required, by when, and what impact each thing will have on your customer") is fine, but conveniently ignores reality. The customer frequently doesn't know what is required, and we frequently don't know how whatever it is can be achieved. These are the problems that agile approaches try to solve, applying common sense to the situation and recognising the way people's minds work best. By iterating our way to a solution, we allow the customer to better develop their ideas as to requirements, and we as developers are able to offer better advice as to costs and benefits of various approaches.

Building software is not analogous to any other form of manufacturing, but is closer to the design process, where iterations are commonly used (cf James Dyson's 3500 prototypes of his vacuum cleaner).