When its Just Barely Good Enough, of course!
JBGE - I find - is the term used on agile projects to make sure you don't 'guild the lily' (GTL). Once you have something that can reasonably be built and tested the plan is to go for it in a 'sprint' development to get early sight and feedback on what you are building. Helps developers, helps users, helps produce a more targeted end product. You may have to go round the loop a few times refining and changing - but that's the nature of the beast anyway in the software development arena.
An excellent view of how this fits into agile developments can be found on the following link
The issue comes when you try and introduce these techniques into organisations who are steeped in the more tradition waterfall approach to software development. Lets get the requirements - all of them - can't be doing with a bit of uncertainty, therein lies risk - write them all down then tick them all off as we grind through the design and development cycle. Trouble with this approach is - and don't get me wrong it does have its uses in certain arenas where you need to have full control and visibility - in a fast moving business environment, you will be overtaken by the opposition if you are not fleet of foot. If you are not careful the waterfall will simply be a cliff edge!
What the more agile approach provides are mechanisms for accelerating a project other than simply chucking bodies at it. You can shorten the 'sprint' - build intermediate releases, for example - which can help accelerate testing and user acceptance. You can re-evaluate what is JBGE for the development - does it really need to be all shiny and new?
Of course you need to make sure that what is produced is fit for purpose and doesn't fall into the NJCP category (Not Just Crap Programming).
Onward and upward ;)