Crystal Clear methodology says teams get better through "Reflective Improvement". Waterfall shops i've had experience with prescribe a "Post Mortem" or a "Lessons Learned" as if to weep about the past or to punish those who need "Taught a lesson". When i worked at a helpdesk we had a monthly team meeting and a bi monthly training session. When i worked at a restaurant, we gathered at the bar after hours and talked about what we could work on together to make more tips, sales ideas, etc.

The common ground that i find with the successful teams i've been in is that they all revolve around the act of recognizing places where they could improve and working slowly towards those improvements wherever they could.

First off... Retrospectives are NOT:

1. a place to vent
2. a pulpit to shout your pet peaves the loudest to get your agenda
3. a soapbox to preach best practices or argue some other holy war
4. a replacement for summarizing the sprint/iteration and recognizing commitments

A retrospective is:

1. a chance to look at some real data about the team
2. a chance to hear how you may have impacted a team member (favorably or unfavorably)
3. a chance for you to decide where you want to see the team make improvements
4. a chance for every voice to be heard in a constructive way

Now i'm going to pimp a book i've been reading lately called "Agile Retrospectives - making good teams great" by derby and larsen. Just like Fowler's book being the definitive refactoring book i think this is clearly the definitive book on retrospectives (mainly because i don't know of any other books for either topic! haha)

Let me summarize what these two ladies suggest you do for a retrospective to keep in on point, concise, interactive, and productive.

1. Set up the stage: they give you tons of "set the stage" activities to use with your team. Step by step guidance on how to go through them. Plus this generated a few ideas of my own just by reading these. The big point here is that you give everyone on the team a chance to talk briefly, with 1 or 2 words so that it's easy to get involved with the discussion.
2. Gather Data: a retrospective doesn't work without having some type of information to work on. Sometimes, you have to just wing it. Like right now, my gathering data is basically (what did we do good? what did we suck at?)
3. Generate Insights: this stage is all about letting the team think of reasons why they were awesome or reasons why they sucked. This isn't the time for discussion on  what to do about it yet, but a chance to go over the real details of what they saw, heard, felt, and experienced during these moments of bliss or frustration. This will help them do the next stage.
4. Deciding what to do: now that we have insights into why these things happened (hopefully). We have to figure out what it is that we're going to do. In my case right now, i'm limiting the team to 1 thing that they're all going to vote on to 'work on' and then generate a list of ideas through brainstorming that they'll propose will 'help' this area of need. For example: We want code to be testable sooner... well you could write unit tests first via TDD. You could write the UI first for UAT scripting. You could have a tester pair up with you to work on something and build it from their perspective first. maybe more.
5. close the retrospective: this is i thought would be self explanatory, but it's not really. Take the extra effort to thank the team for their efforts, and for being involved with the retrospective.