FDD is what I like to think of as a wrapper methodology, in that it allows you to apply a method to manage projects at a very high level, but it still allows you to use other methodologies at a lower level.
FDD's focus is on being able to set estimates and schedules and to report on the status of a project as a whole, or at a very granular level, but it doesn't prescribe a specific method to apply in order to create the schedule, leaving that up to you to decide. The idea is that you can look at your project and state with some certainty what the project status is, whether you are on time, slipping, early and so on.
I use FDD as a means to organise my projects into manageable stages, so that I know WHEN to sign off and commence any given stage. But by itself, FDD would be pretty useless. For example, I personally use Evidence Based Scheduling and a combined BDD/TDD as elements of a development processes that are managed under a kind of FDD umbrella. Personally, I couldn't do the full XP, or SCRUMM without running into problems because my projects and team would be hindered if they were forced to engage in practices from other methodologies that don't add value to our own unique circumstances.
In any case, it is better not to fixate on any given methodology, because the needs/conditions of the company and project are likely to change regularly, and you need to be flexible in how you approach managing projects if you want them to be successful. No single methodology is a silver bullet, so the trick is to determine which methods work for you and tune your methodology to suit your individual needs. This is what being "Agile" is fundamentally about.