Some Q & A on retrospectives

How do I select a time for a retrospective?
When it comes to sprint retrospectives, I want to have the retrospective on the same day as the demo. People going home and coming back the next day don't have that sprint in mind anymore. Most people forget how they felt the day before and that feeling is important to catch.

When it comes to a project retrospective, it's a good idea to have that on a separate day, but if the new project is up and running the day after, try having the retrospective before the other project starts.

Who's holding the retrospective?
The first rule is that the person should come prepared. The person should also understand or be able to read the participants. And the person should have the time and the personality to document the result and present it to stakeholders.

It's also easy to get lost during a retrospective. People can get into these long discussions and the rest of the crew get unintested or you don't have the time to finish the meeting. You need to be able to draw the line. Here I believe it's important to "park the question" instead of just dropping it. I tell the persons having the discussions that they can bring it up after the meeting or at a time that fits them. Of course this must be treated with care: some discussions are such as they cannot be dropped and have to be solved.

Who should participate?
This is a tough question. Of course, team members should participate but should other stakeholders participate? Depends on how free team members feel to take up their issues if for example a boss is present. The experiences of the participants should also be connected - it's no use drawing a time line if none the participants understands the other one's notes.

As a product owner, I've participated and I've been there just listening. Now I participate but stuff that does not involve the team's tasks are not presented. That should also go for part time resources - talking about details in the other project is of no use but if the other project affected this one - write a note which says "Other project".

Should you come up with solutions during the meeting?
This is also a tough one. Sometimes the solutions are easy to find but it's often easier to get into a long conflict driven discussion which ends with a really bad solution. If there is nothing obvious pops up, I tend to give people in pairs the task of coming up with one or a few solutions on a subject. It's best if everyone gets a task, but the most important thing is that the solutions should not always come from the same persons.

We have so many meetings, I don't think the guys wants more meetings...
There are few meetings that are directed at solving problems for the team as such, not the company, not the product, but their situation. The retrospective is for the team. Therefor it should be fun and there should happen something with the result of the meeting. If there are ideas and solutions from retrospectives which are never implemented, then out goes the retrospective.

My suggestion is start with a short, active meeting. Perhaps just drawing the time line. Then, always act on the suggestions of the team. The most important thing about retrospectives is that if the participants don't believe in them, they are a complete waste of time. And then having a beer and getting people to chat on can be a better option.