Agile has a notion of defining “done.” This might sound funny – how could we not know when something is done? But, 
as with any creative endeavor – there is “done” and then there’s Done.
Just try it – ask 5 different people on your project how they determine when a development task is “done” and, as the saying goes, you’ll get a lot of different answers. But, while this might be an interesting exercise, if you really want to understand the problem, don’t just ask them what is meant by done. Instead, look and see what they’re actually passing off as done.
On my current project, it seems pretty clear that the management – if not through their words, then through their actions – has defined “done” to mean that code was checked in and a little checkmark was placed in the “Done” column for that task.
This makes all of the management’s schedules and reports up to their management look nice and tidy. Give yourselves a pat on the back, “well done, Bob!”
On the other hand, this makes the code look like a bloody mass of … well, you get the idea.
In management’s defense, the managers aren’t developers and even if they were, there’s way too much code for them to dig through to determine if it’s really production ready or not. Why shouldn’t managers be able to rely on their developers’ word for when something is done?
In the developer’s defense, they are working from outlandishly unrealistic schedules and whenever anyone tries to explain 
that more time is needed they’re rewarded with a management gem such as “well, it’s just got to be done by that date because that’s when we go live.”
So the developer’s, God bless ’em, tried their best to meet those deadlines – because why shouldn’t developers be able to follow their manager’s direction? At the very first sign that the code seemed to be working, they checked that puppy in and moved on to the next task.
The results are reminiscent of one million monkeys typing. You know the type – amorphous blobs of stuff that aren’t even sustainable enough to get us to an initial release of the product. One step forward, two steps back.
meaning that we need to value the craft of building software to last over the mad rush of delivering the first solution we think up that appears to work. Sure, managers and customers are always going to try to squeeze the last dime of productivity out of us – that’s just human nature. But what it really comes down to is that we, as developers, are the ones that ultimately say when our code is done. We are the experts that management ultimately relies on to tell them what is needed. And every time we agree to deadlines that don’t allow us to do our jobs, every time we proclaim our work as “done” using crap rather than craft as our measuring stick, we’re failing to live up to our responsibility.
What do you think? Who defines done on your project? How do you think it should get defined?