The sign-off approach basically requires that you sign off some work as complete before being allowed to proceed to other work. If you can't sign off some bit of work, you spend more time on it until you can. The logic of this is of course to make any troublesome or unsatisfactory work surface and impact the schedule early, rather than letting problems accumulate and cause slippage or panic late.
In a classic waterfall model, you would sign off a specification before proceeding with development, or during development you would sign off a basic module before starting work on a dependent module. You wouldn't immediately associate sign-off with "agile" methodologies, but it seems that XP (in my very limited exposure to it - I'm no expert there) is very strongly sign-off. It requires that you sign-off (approve) stories before moving on to other stories.
Conversely, the fix-and-raise approach doesn't require that you do anything to completion before moving on. You just have to make some improvement to the software (fix an issue), and note what work remains to be done to achieve something good (raise residual or new issues). In a purist form, you'd start a project to write a word processor by raising an issue that "We have no software". Then someone would fix it by writing some trivial application and raising new defects that "The application does nothing" and "We have no installer for our application". And so on. Soon enough you'll have something that looks like a word processor and your issues will be genuine missing features or bugs. Late on, your issues will be only feature creep and bugs.
I'm not aware of any projects that implement this as a conscious methodology from the beginning (again, they might exist, I'm no expert), but I've experienced many projects that, having created some body of software in a different methodology, transitioned to fix-and-raise in the period before release. Sometimes two parallel systems were in place, an earlier sign-off as well as the fix-and-raise, and at other times the project clearly entered a fix-and-raise phase. The latter case generates less friction.
I prefer the fix-and-raise approach, because I think it's more in tune with reality and with the fundamental problem that software gets late because of the time needed to remove uncertainty. Conversely, I think sign-off is unrealistic because it's just not practical to sign off some piece of work in isolation early in the project - you just can't think of good enough sign-off criteria when you have only small fragments of the project in front of you. Also, I think fix-and-raise is nicer on people. It lets developers make an improvement and move forwards, and it lets managers appreciate in a clear way how far the project is from completion in terms of outstanding issues.