I was asked the above question the other day. From all my experiences, reading, etc. retros are good to mix up a bit – the reason is that when you look at the purpose of a retrospective it is for the purpose of continuous improvement. One ‘book’ says to only have the Scrum Team participate, (developers, QA, PO, Scrum Master (I would also include an Agile Coach here since you are usually talking about at least some Agile process issues)), but there are individuals with different perspectives even if they are not on the Scrum Team. For example, the Support Team sees things that the Scrum Team might not and vice versa.
So, I encourage teams to vary their retrospective participants. I've also had a lot of success with varying the types of retrospectives being done. Some common retrospectives I do are:
- Release Retrospective - focus on the release that just occurred. This is typically cross-functional across all departments.
- Leadership Retrospective - focus on how you are doing as a leadership group. This can be focused in a department or cross-department.
- Topical Retrospective - pick a topic and retrospect only on that. Some examples include: continuous integration, design and architecture, process, and client service.
So, I would encourage you to start to ‘draw outside the lines’ a little when it comes to the Agile processes, and be open to change up your retrospectives and try out different types of retrospectives as well.