3 ms·

Never seen anything useful actually come from a retrospective. There are open and interesting conversations about what went wrong/could be done better, but thos

Never seen anything useful actually come from a retrospective. There are open and interesting conversations about what went wrong/could be done better, but those discussions never materially change the team. Generally people are who they are, the work is what it is. How the team will be is relatively static given the same set of people and projects.

latchkey 4y ago
This is why Pivotal Labs would rotate people on teams quite often. Nobody gets "stuck" doing the same thing endlessly.
arnvald 4y ago
Interesting, I have a very different experience. My team does retrospective once a month (we don't do Scrum, so it's not tied to "sprints") and every month we actually do some improvements. Sometimes the problems are small, let's say our products have inconsistent CLI interfaces for developers, and that slows us down, so we decide to unify it. Sometimes it's big stuff, for example the team feels that we don't have enough clarity about long term of the product, or there are too many interruptions. Then it's my (EM) or PM's role to figure stuff out. Some of the good things we changed as a result of retro: we removed stand-ups, we agreed to meet in the office once a week, we introduced a daily support rotation for our users (we build internal tools). We can't fix everything, but every month we get something done, and that keeps the team motivated to bring new ideas to retros.
cableshaft 4y ago
I have the same experience with retros. Generally they've have been a waste of time. Any useful information that could have been gleaned from them were probably already had in an earlier discussion, tend not to be remembered to be brought up again in retros, and at least in the teams I've been on the minutes from the retro meetings don't get recorded anywhere anyway, so there's nothing to refer back to in the future.
- pas 4y ago
  it seems these teams lack(ed) the drive to consciously change. meetings should have conclusions (action items based on consensus, which are commitments from all members) and it's a typical team dysfunction when members don't honor commitments (someone doesn't do something and then others don't bring this up to hold each other accountable) if the team is so dysfunctional that it just does the same thing over and over again while constantly promising to change then it should be broken up before the members themselves start to suffer the psychological toll of this cognitive dissonance.
  - trhway 4y ago
    >it seems these teams lack(ed) the drive to consciously change. classic Scrum statement - putting the blame again on teams. A team usually has no power to change anything that matters.
    - pas 4y ago
      what has this has to do with scrum? I haven't even mentioned it (or even implied that this has something to do with scrum), dysfunctional teams are waaaay more general problem than whatever scrum is/isn't. Blame implies responsibility, which - like you mentioned - is not that simple. (Depending on personal philosophy maybe each team member has a responsibility toward themselves to get a job where they are not put into the aforementioned loony toones situation, but even with that in mind I honestly think you misinterpreted my comment, because I don't meant to assign blame at the team and its members. You might notice I expressly mentioned that if the team is too dysfunctional it has to be broken up "from above", implying that its not the responsibility of the team.)
- urthor 4y ago
  Disagree. After retrospectives we've always had a pretty good idea of what our problems are. Motivation to fix those issues is a different story. Scrum can't solve for lacking motivation.

latchkey 4y ago

This is why Pivotal Labs would rotate people on teams quite often. Nobody gets "stuck" doing the same thing endlessly.

arnvald 4y ago

Interesting, I have a very different experience. My team does retrospective once a month (we don't do Scrum, so it's not tied to "sprints") and every month we actually do some improvements. Sometimes the problems are small, let's say our products have inconsistent CLI interfaces for developers, and that slows us down, so we decide to unify it. Sometimes it's big stuff, for example the team feels that we don't have enough clarity about long term of the product, or there are too many interruptions. Then it's my (EM) or PM's role to figure stuff out. Some of the good things we changed as a result of retro: we removed stand-ups, we agreed to meet in the office once a week, we introduced a daily support rotation for our users (we build internal tools). We can't fix everything, but every month we get something done, and that keeps the team motivated to bring new ideas to retros.

cableshaft 4y ago

I have the same experience with retros. Generally they've have been a waste of time. Any useful information that could have been gleaned from them were probably already had in an earlier discussion, tend not to be remembered to be brought up again in retros, and at least in the teams I've been on the minutes from the retro meetings don't get recorded anywhere anyway, so there's nothing to refer back to in the future.

pas 4y ago
it seems these teams lack(ed) the drive to consciously change. meetings should have conclusions (action items based on consensus, which are commitments from all members) and it's a typical team dysfunction when members don't honor commitments (someone doesn't do something and then others don't bring this up to hold each other accountable) if the team is so dysfunctional that it just does the same thing over and over again while constantly promising to change then it should be broken up before the members themselves start to suffer the psychological toll of this cognitive dissonance.
- trhway 4y ago
  >it seems these teams lack(ed) the drive to consciously change. classic Scrum statement - putting the blame again on teams. A team usually has no power to change anything that matters.
  - pas 4y ago
    what has this has to do with scrum? I haven't even mentioned it (or even implied that this has something to do with scrum), dysfunctional teams are waaaay more general problem than whatever scrum is/isn't. Blame implies responsibility, which - like you mentioned - is not that simple. (Depending on personal philosophy maybe each team member has a responsibility toward themselves to get a job where they are not put into the aforementioned loony toones situation, but even with that in mind I honestly think you misinterpreted my comment, because I don't meant to assign blame at the team and its members. You might notice I expressly mentioned that if the team is too dysfunctional it has to be broken up "from above", implying that its not the responsibility of the team.)
urthor 4y ago
Disagree. After retrospectives we've always had a pretty good idea of what our problems are. Motivation to fix those issues is a different story. Scrum can't solve for lacking motivation.