One important aspect of agile methodologies is having feedback loops. Feedback loops allow a team to make improvements to their process, by keeping what works and changing what doesn't.
In my experience, feedback loops have a huge, positive impact on teams. Continuously improving processes, allows people to work more effectively. Making changes requires less negotiation. People are less reluctant to try out something new, because a change can always be undone in a next iteration.
Another positive result is team motivation. Everybody is encouraged to contribute. This leads to less complaining and more commitment. Especially in times of stress, looking back and clearing up the air can prevent a lot of frustration between team members.
So what is a good time to provide feedback? If immediate results can be obtained, it is best to make improvements directly. Some shortcomings are less apparent though. One way is to have a retrospective meeting with the core team. I found that just after the start of a new iteration is a very good time for this. The last iteration is still fresh in people's memory and there is plenty of time left to finnish the current iteration. Adding another meeting takes precious time though. I'd suggest a retrospective meeting can be tried at least once. If the team finds it ineffective, it can always be cancelled at the next retrospective.
Having a good retrospective meeting is hard. It can easily get out of hand and become ineffective if it has no clear structure, It can be tempting to complain about other teams, or talk about the weekends. It is most effective however to look for improvements that can be made by the team itself. A good retrospective meeting results in clear actions and an agreement on when they must be executed and by whom. It is also satisfying for every participant.
The Retrospectives Wiki has some formats to do retrospectives. Ilja's blog post on retrospective anti-patterns is a good read as well.
