The idea is to complete the portions of a feature that will unblock those dependent on you. This way development moves along smoothly because more lines of development can be active at a time. For example, instead of implementing the entire database, implement the simple interface and stub it out. People can work for a very long time this way using that portion of the feature that caused others not to block. Plus it's a form of rapid prototyping because you get immediate feedback on these parts. Don't worry about the quality of implementation because it doesn't matter yet.
Sounds somewhat like "pull from demand" in LeanProgramming.
Also known as an IntegrationPlan?, but that probably sounds too much like WaterFall for the present generation.
I think of it as short cutting an integration plan so that subsystems can implement using the "real" interfaces they will need, but sooner than they otherwise could. The integration would require real functionality so all the tests would pass. With a non-blocking approach you get other code working as fast as possible, but it really only works in the broadest terms.
Oh, a sort of improvised planning. I like that!