For years, I’ve seen people argue online about who should and should not be invited to a retrospective. In typical consultant fashion, my answer is “It depends.” Here I want to describe the dependencies so that it’s not such a mystery.

First, let’s define the basics so we have a foundation for the conversation. My definition of a retrospective is

• Looking at the past, together
• To gain insights
• And make choices for the future.

“Looking at the past, together” is what the word “retrospective” literally means. The word dates to the 17th century, and is formed from the Latin retro meaning “back,” and specere “look at.”

Let’s see how this affects the question of who should attend.

What are you looking back at? For a retrospective to make sense, the people involved should be looking at some shared experience. They’re unlikely to come up with insights if they’re each looking at something different.

I emphasize the “together” part because I see so many teams and organizations assume that everyone saw the same things and interpreted them the same. Even for a small team working together in a common room, this is almost never true. The differences in what different people noticed, or how they interpreted what they noticed, is often the root of the most illuminating insights.

The “who should be invited” question is answered by “who shares that experience.” If you invite just the programmers who are working on a project, they’ll address the things that are important to programmers, and therefore noticed by them. There may be times when this is exactly what you want.

As you move to “whole team” product development, you’ll naturally want to include other members of that whole team to include other points of view—that of software testers, designers, customer researchers, and whomever else is adding value to the product. These various constituencies may be working somewhat independently, but toward a common result. The more closely these constituencies work in collaboration, the more reason for them to retrospect on the work together. If they work separately with coordination of their efforts, then retrospecting together on their coordination activities makes more sense. Each constituency won’t have much visibility into the workings within the others. Of course, they might gain the insight that their work together might be more effective if they collaborate instead of coordinate, and that would change things.

Usually this question come up in terms of whether the manager or the product owner should be invited. There again, it depends on the working relationship. I’ve seen product owners who collaborate very closely with the team building the product, especially if things like customer research and user testing are done within that team. These would naturally be part of the same retrospective. I’ve seen other product owners who “throw requirements over the wall” to the team working on the product, and show up again to receive the finished work. These would likely interfere with the effectiveness of a team retrospective. They won’t share enough commonality with the team, and likely have a difference in power status that would inhibit others from speaking freely at the retrospective. The same it true for managers. The important question is do they collaborate well, or do they use their positional power to get what they want.

In cases where it’s not clear, I suggest having retrospectives both with and without the “more powerful” position in question. You may find that they are both valuable, but the insights and decisions made are on very different levels. In the same way, you might find that it’s sometimes worthwhile to have retrospectives of even larger communities within the endeavor—whole departments, divisions, or even the whole organization. They will uncover different things than a team retrospective, but that has value, also.

Now, look at your own situation. Are there people being included that inhibit more detailed insights into the work? Perhaps try a retrospective without them. Are there viewpoints missing that would be valuable to address some perceived problems? Try a retrospect including them. This doesn’t mean you have to give up the retrospectives that you’ve been having. That’s a decision for later. For now, try it and see how it works for you.