I was looking through some material the other day and a statement came up that I found intriguing. “What is your team’s definition of done?”
Since I believe in the concept of “good enough” rather than spending the time and effort to hit perfection (since we all know that is probably not attainable) this concept of having a formal team definition of when to “put a fork in it” and call it done, made me think – how often do we have a formal structure and definition of being done? Is it flexible??
I’ve talked with people who were doing in-house agile development and their definition of done always seemed to be when they ran out of time or money. Rarely was it when they ran out of requirements. Is that OK?
For programmers who do have a defined set of requirements and are coding for money, they’re done when the requirements were all met, the code was all compiling, everything was tested, the code is installed in production and the customer has signed off. That is getting pretty close to perfection.
Can each of the roles in a project can have their own definition of done? If all those individual definitions are met, is the project done? I can think of a number of situations where the architects completed all their work products but the results were never used effectively. The flag was raise but no one saluted, so done was declared too early.
It just seems like something we may all want to take a moment and think about – when I think I’m done, are the other stakeholders satisfied??
Beyond the intersection of technology and life 
Charlie — you make good points. Too often, “done” means the developers met a deadline and the result (sort of) works.
One ingredient I would like to add is craftsmanship and good practice. I can’t regard a program as “done” if corners have been cut and/or good practices have not been followed, even if it compiles cleanly and passes tests.
That scenario arises from the myth of “quick and dirty”. I say “myth” because, in my experience, in the hands of a competent practitioner cutting corners not only doesn’t speed up delivery, it actually delays it. And, of course, a much larger price is paid down the line. It’s a tragedy that so many development managers subscribe to this pernicious myth.
LikeLike