How would you like your code? Refining our Definition of Done
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?
Here’s a pop quiz for you.
I just got back from a presentation by 
