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?' ;)
>> 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.