I am interested to know what the “norm” is for participation in retrospectives. From reading your post I think the retros that I run are technical ones as I only do it with the development team. I was advised by a coach that having the business or even the product owner involved wasn’t ideal.

I could see a release retro being the place for all hands being involved though.

What are peoples thoughts on this?

George, will you tell us which safety exercise you used in this case and why you chose it? Perhaps it be good as another post. Thx

Even if the team retros go well, I’ve found value in having different “communities of practice” get together. In a large company, this might be everyone interested in testing getting together to watch a demo of how one team is solving a particular testing problem.

Recently on my team, we testers decided to get together and talk about testing and ideas we wanted to try. Some good ideas came out which we brought to the whole team and we are experimenting with those now. It’s been really beneficial. It isn’t that we are afraid to speak up in retros, but there are so many potential issues to discuss, we might not focus on testing.

I reached a simillar conclusion for a project I coach. People were only raising “acceptable” issue. I was forced to advise them to do a retrospective without “business people”.
We tried that last week, and non-popular issues have been raised and tackled.
I think this was the right decision.
The point is to align the composition of the ritual with the organisation (it guys vs non-it guys).
I find it sad, non agile (re-read the manifesto), but it was the only way to be efficient.
Perhaps is it a first step. When the (IT part of) the team will be confident, we may try to bring the rest of the team.

Having a handful of models still gives people a useful framework for hanging their thoughts, but forces a choice which counteracts the “by rote” tendency.

In both cases, sometimes it is indeed a more natural fit. Especially, “barf if there’s an error”. But sometimes, not so much. Different tools for different jobs….

Great post. It captures and expands on my thinking perfectly.

As Agile moves away from the motivated it gets adopted by the “less motivated” who may just follow it by rote. That is why I’m reconsidering whether the G-W-T needs revisiting.

Chris

I find that at least as pleasant as the one in G-W-T form, but perhaps it’s because I’ve spent years orienting my programming along that pattern.