This comes from the Poppendieck's book Implementing Lean Software Development under the section on "Eliminate Waste".
The inventory of software development is partially done work. Partially done software has all of the evils of manufacturing inventory: It gets lost, grows obsolete, hides quality problems, and ties up money. Moreover, much of the risk of software development lies in partially done work.
Tom and Mary Poppendieck
I really like the whole idea of minimizing the tasks that are "in process". If you think about it, if I have 3 tasks that will take me 3 days each and work on them all "simultaneously" there are a few problems. One, at the end of 3 days you still have nothing done, and if you are truly working on them in parallel you won't see any results until the 7th day.
Even more dangerous is work that is perceived as "done" but isn't really done. One of the great things about Scrum is that you need to think about what "done" really means. Many projects out there don't get anything "done" and, as such, end up with the hare's problem and must "declare bankruptcy" frequently to clear out the "excess inventory".
Now this doesn't mean that you "get it right the first time". Often you will need to redo something that was previously "done", but leaving things undone because they might change is just a recipe for disaster.