Re: [scrumdevelopment] Re: Passing to QA, what is a good definition of done?
- But again, what are the quality standards of your development team in the mean time?
One of the most noxious effects of waterfall methodologies is that they have, in practice, encouraged mediocre (or desperate) development teams and managers to fully compromise on quality, since the testers will catch the bugs later anyways.
This leads to rampant speculative scenarios like delivering garbage on time in order to meet an artificial (but signed-off) delivery date, and letting the poor sucker in QA try to figure out how the hell this piece of functionality is supposed to work (hint: it doesn't). I have seen managers go as far as to seriously consider delivering prototypes (as in mockups of web pages), since they were out of "development" budget but had ample "bug fixing" budget for the QA phase.
So, to focus on your original question: your definition of "done" should -theoretically- be exclusively related to your quality standards, and should be independent of the existence or not of an external QA team.
But that is theory. In practice, once management has understood the long-term objective of merging QA within the teams, all you can do until you get there is to strive to deliver the highest quality product as possible from within the context of your team. That is your goal. This means, in plain english: "Develop the highest quality software you can with whatever budget you have, and call whatever the end result is done". Of course, you should, in the meantime, try to involve the external QA people as much as possible before the handoff in order to help you increase this quality.
XavierOn Fri, Mar 28, 2008 at 11:12 AM, Mattias Skarin <mattias.skarin@...> wrote:
Hmm.. no surprices..
Getting "rid" of the end QA is not a small step, it involves moving people,
buying hardware, move facilities. Do not get me wrong, we are heading in
this direction. But we cannot allow teams to work without a clear goal
until we have completed.