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??
(Cross-posted @ Beyond the Intersection of Business and IT)