Three Types of Meetings
Agile development requires a couple of different meetings in order to get things done. Most people know about the daily standup meeting where all the members of the team stand and one at a time say what they did the day before and what they plan to do that day. Ideally you pass around a token (conch shell anyone?) and only the person holding the token can speak.
The other important meeting is called 'estimation'. This is held every sprint (week or two) and it's when cards are estimated by the people who will likely do them. Only those people can estimate (usually with point values of 1, 2, 3 and maybe 5).
Both of these meetings are absolutely critical to a team's success in the agile scenario.
There is a third meeting that some groups forget about but which is no less important. In fact, I would say it's the most important meeting and it can even be used without the rest of the process on a non-development project (for instance with a sales team).
What is the Retrospective Meeting?
First of all, get everyone in the room or simply commandeer the entire office. This is a group event and nobody on the team should be missing it (unless they're busy playing Starcraft of course). Don't be lame and exclude certain staff. If you don't value their input enough to have them in the meeting, let them go entirely. If there's a senior person who doesn't even want to come to the first meeting - know in your heart that that person doesn't value you and start looking for another organization to work at or start thinking long term about ejecting that senior figure from the group. Hiring and firing is an important part of all organizations - face it head on.
There is an exception to the 'invite everybody' rule and that's if an invitee might make other people feel 'unsafe' and otherwise keep members of the group from speaking up. This might happen if you're a consultant called in to fix something. If you're consulting, they've called you in to fix the problem. Don't invite the toxic character but do make sure he or she knows the outcome of the retrospective meeting and work with them to fix the problem. Hopefully you can fix the situation and earn your keep - or you can at least identify the problems for upper management who can then make tough decisions. If this is your team, this situation is really bad.
Anyway, once everybody is together, let them know this will take 1 hour (1:15 if it's 10+ people and it's the first time). Don't let meetings go more than 5 minutes over time - you really don't deserve the respect of that person who didn't come if you can't even end the meeting on time.
Cellphones and computers off.
* Post-it notes or index cards with tack/putty/magnets to stick them on a whiteboard.
* Bunch of markers to write on the cards.
Let's get started
Make sure to start things off by asking about safety and make sure that everyone is comfortable enough to speak. This is the organizer's responsibility. Everybody gets a stack of cards or block of post-it notes.
What Worked? What Didn't Work?
On each card, participants write about the previous 2-3 weeks (every 2-3 weeks is a good cycle for these meetings) with "things that worked" or "things that didn't work". Let them brainstorm for a solid 10 minutes or until there's not much else to write. When people have written all their cards, they all get put on the board either on the left side reserved for "things that worked", and the right side for "things that didn't work".
Some people add a 'puzzle' section on the right side of the board for things that people didn't understand (i.e. what's that giant box that got delivered last week and is sitting in the corner of the room shaking every couple of minutes?).
Group the Cards
The organizer then reads the cards out loud one by one. If one is similar to another that has already been read, he puts them together in a cluster on the board. If the organizer needs clarification, she asks whoever wrote the card to offer more details to the group.
When all the cards are grouped on the board, each person gets a chance to vote on the cards they think are important by adding a dot. Each person gets a total of 3 votes (feel free to put 3 votes on one card).
It's nice to vote for "things that worked" but over time, people are going to focus on "things that didn't work" because those are the things people want to make better.
Now the organizer takes the top 3-5 cards and moves them to the upper right side of the board in order. Only the top 3 are typically discussed but sometimes there's time to talk about #4 or even #5 so it's best to just move them to the upper right as well if the vote count is close.
Starting with the top, you open the floor to discuss each item one by one. Give about 5-7 minutes to explain what didn't work and why it matters. At the end of the discussion (shut it down if it's taking too long), ask for a volunteer to be the point person to address the problem ahead of the next retrospective meeting. The volunteer DOES NOT HAVE TO FIX whatever didn't work. The volunteer just has to move forward with putting together the solution to the issue: getting the right people together, finding out how to fix it, assigning people to fix it, or of course, just fixing it.
Each session gets a bit easier and smoother and this is when the point people assigned to unwind (or at least start to unwind) the things that didn't work from the previous session get to talk about their progress. If progress isn't sufficient, the person keeps at it (or maybe somebody more senior takes over) until there's some sort of resolution. Not everything always gets fixed but the team sees how they were able to push forward problems and get them addressed - and that's an amazing step forward for most organizations
Just do it! If after you read this article, you're worried about buy-in and getting people on board, let the powers that be know that this is a great way to build a better organization and that the staff will really respond positively. And as with all things in the agile process, don't think too hard about it - just do it. You can always say "that was stupid" and never do one again. If a group can't try something just once to see if it works, it won't grow and be able to innovate. The capacity to experiment and innovate, sine qua non.