Presenting a UX design is never a single task that you do once and never do again. You goal isn't to present your design, but rather to get it implemented. Sharing your design is something that you will do over and over again throughout the development process, regardless of whether the process is agile or waterfall or some mix therein.
The way that you communicate your design depends on the needs of your audience. Your communication style needs to match theirs. If they communicate exclusively through their bug-tracking mechanism, then your design needs to be communicated there too. If they communicate via wiki, then your design needs to be wiki-fied. If there's one stakeholder who really needs to buy off on your design and everyone else will follow that person, then you need to figure out who that stakeholder is and figure out how to get them to buy off on your design. If everyone needs to come to agreement that your design is the one that they will implement, then you probably need to have one discussion with project managers and a different discussion with engineering. Each of those groups have different goals and different needs, so having a separate discussion with each of them means that you're able to address their unique goals and needs, as well as answer any questions that they might have.
You'll need to do this more than once. You'll need to track the development process and ensure that your designs are being acted upon, and communicate with the team if they're deviating from the design. It might be that they've forgotten elements of your design, or that someone new has come on board and simply isn't aware of it, or they disagree with it and so are conveniently disregarding it, or (as in every software project that has ever existed) they're having to make changes to their plan (adding features, cutting features, cutting parts of features, etc), and thus parts of your design are impacted by those changes. If they're going to make design changes or compromises, you should be a part of that discussion -- you know the design the best of anyone, and you know why you made the design decisions that you made, and you can help them make decisions and discuss the trade-offs between development time and user experience.
Remember: no-one cares about your work more than you do. For your design to be truly effective and fully implemented, you're the one who's going to have to track it and make sure that it actually happens. A beautiful design that never gets implemented is meaningless.