The problem is that in many large organizations, the retrospective is a political game where the objective is to find and blame a person (or persons) who caused the team to underdeliver on the sprint. That mindset is an anathema to the sorts of honest constructive discussions that are required to meaningfully improve process. Instead the meeting turns into a toxic political mess that ends up disadvantaging the most talented developers on the team.

You clearly haven't worked with people who like the sound of their own voices quite so much as I have.

>> What went well during the sprint cycle? >> What went wrong during the sprint cycle? >> What could we do differently to improve?

I have had Agile Evangelists, who are supposed to be good at making this stuff streamlined, turn around and say "Everyone needs to come up with five things in each category, then we'll go through and discuss them all, deciding on the most important things to change at the end"

In a team that was already too large (15ish people) I watched that eat an entire afternoon and produce no useful output on more than one occasion. In the team I was on (four, five?) it still seemed to take hours.

I know, I know, they were probably doing it all wrong, this is just my experience of one workplace.

I'm not saying it can't be done right, just that it doesn't seem to be a magic bullet and can devolve into navel-gazing.

From my limited experience, scrum can work (defining 'work' as 'make people more productive'), and even in the classic situations that give rise to the flaccid variety (I work for a blue-chip media corporation which is just in the last couple of years trying to build a modern engineering culture basically from scratch, and it happens to work).

A pretty important point for making scrum work, however, is aggressive timeboxing of everything. If you don't want retros to become a 4 hour developer-kvetch about somebody else's team, start by ruthlessly clipping it to 45 minutes.

I understand that this is not always an option in malfunctioning corporate environments; but Kanban/XP/programming motherfkerism wouldn't fly either in those situations.

>> If you don't want retros to become a 4 hour developer-kvetch about somebody else's team, start by ruthlessly clipping it to 45 minutes.

When I rule the world, as they say, every meeting will contain only the people it needs to, "I don't feel this is relevant to my work or that I can contribute" will be the best reason not to attend and time limits will be aspirational in as much as everyone will aspire to beat them by as much as they can.

Unfortunately, as a contractor, I can suggest these things but not mandate them.

In that case, part of the retrospective should probably be 'these meetings aren't actually solving anything, are actively getting in the way of getting things done. how can we do this meeting differently?' ;)

After a while we fired the Agile Evangelist and became a whole lot more agile :)

In my experience, either:

- A few people end up discussing some minor point only of interest to them while everyone else stares into space

- Every retrospective ends up being the same as the previous one: it's like someone recorded a meeting 2 years ago and plays it back every 8 weeks

- Things that went well are all internal; things that went badly are all other teams' fault (this can't always be true)

Yes, I realise those aren't really agile issues, just a symptom of having a relatively poorly defined meeting with lots of people.

>>A few people end up discussing some minor point only of interest to them while everyone else stares into space

Mostly the manager's minions and pets talk, generally in a softer tone more towards appreciation bordering sycophancy. The remaining fear to give any genuine feedback, fearing retribution. If some one does speak they are taken as non team players who will be handled appropriately the next raise/promotion cycle.

There fore no one talks.

The scrum master or even "team lead" is supposed to catalyze things a little bit in those situations. A lot of times there's a culture of "everyone knows about it, but nobody will say anything about it because they're afraid of the axe," where "it" is the thing that's horribly wrong.

These are clear symptoms of not having retrospectives facilitated in a proper Wat. A good facilitator uses different exercises, has people focused on a fixed scope or time period to catch learning points, supports a team in coming up with actions that they can do immediately and that are small enough to finish on a short notice.