What does “done” mean to you?

Scott Hanselman discusses Scrum with Ken Schwaber in his recent Hanselminutes podcast. A large part of the conversation centres on the meaning of a€oedonea€. When your developers say they are done and have completed a piece of work, what does that mean? Ken argues that unless it means ready to deploy and of known good quality (my words) then it is meaningless and, in fact, that any team can increase the apparent amount of work they do by varying the definition of done to mean something less.

One of the key things that he stresses is that the code must be refactored into a good state that can be used as a firm base for future development and that this is part of the work to get to done.

One of the observations that Scott draws out is that Scrum might look quite heavyweight compared to work done by a team before Scrum. At first glance this seems counter-intuitive until you realise that following a non-agile approach makes it harder to see whether the same definition for done is being used (and it probably isna€™t). The team probably wasna€™t doing solid testing, probably wasna€™t ensuring that refactoring was being done, probably wasna€™t creating a quality product.

This sounds all well and good if you have a skilled team working closely together. The question this raises in my mind is whether Scrum can therefore work if you have a mediocre team with only a few very good developers? Will the less-experienced developers be capable of refactoring the code so ita€™s left in a good state? The argument might go that ita€™s no better and no worse than another approach and you find out quicker whata€™s not working.