
Does Your Team Hold Retrospectives? - signals
Wondering how many teams out there hold retrospectives or if you find them helpful&#x2F;not helpful?
======
joeblau
We hold retros and they are helpful to analyze the previous sprint. The main
issue is that changes need to be enforced or they are useless and just become
a time to complain, not improve.

~~~
signals
Thanks for the comment! This is exactly what I've seen. How do you enforce
that changes are made?

------
trcollinson
I believe in the "introspective retrospective". The introspective portion is a
key to getting change to happen. The rules in my retrospectives are:

1) You may put anything up on the board that you want as long as it doesn't
break any of the other rules.

2) Anything said during retrospective will not be used against, or brought up
during, a performance evaluation.

3) Anything you add to the board must in some way involve you.

4) You may not complain about other teams inside/outside of the organization.

To break these down a bit. First, we can write anything (that doesn't break
other rules). In a sad column I might put "I didn't update Jira well, I felt I
wasn't really getting any value out of it." "I was stuck on some code and
decided not to test drive my solution, then I didn't go back and add tests."
In the happy column I might put "John reached out to the SA group and I was
inspired by his attitude in doing so." "Our team accomplished task 123 in half
the time we thought because we pulled together on the algorithmic portion."
When I first started conducting retrospectives people were hesitant to put
down things THEY were doing wrong and needed to improve on. They just
complained. Getting them to open up was important.

This leads to rule number 2. People need to feel safe to say things that they
need to improve without being penalized. Frankly, why would we penalize people
for trying to improve? Yet the psychology of the situation often makes us
believe we will be in trouble for honesty. This is why the rule was added.
When people realize and become comfortable with it, they open up well.

Third and fourth rules go together. You must be introspective: "What can I do
better?" "What did I do well?". Too often retrospectives degrade into
complaining sessions and nothing is our fault. Enforcing the rule that we must
never complain about another team and we must talk about ourselves removes
this nicely.

The psychology of the whole thing is quite interesting. Let's imagine you add
the following to the sad column of the board: "I was stuck on some code and
decided not to test drive my solution, then I didn't go back and add tests."
The hope is that there would be some great discussion about this, "Why didn't
you get back to the testing? Well I didn't have time because of these other
requirements. Oh, next time let me know and I'll help you write the tests, or
take the tasks." That is all good discussion (and it could go 100 different
ways). But the other part is, do you really want to put that up multiple weeks
in a row and admit to your coworkers that you aren't testing if that is the
cultural norm? Heck no! So you do better. Often, you are your own judge and
advocate.

A few final thoughts. When starting retrospectives with a team for the first
time I will often put up the worst things about myself. I want people to feel
comfortable adding things about themselves. It helps. I hold retrospectives
once a week not at the end of sprints (unless a sprint is a week, which I am
also a huge advocate of). I hold retrospectives in the morning and never on a
Monday or a Friday. It is always at the same time and on the same day. My
teams are usually relatively small (another thing I highly suggest). Never
over 8 people, and often 4.

~~~
signals
Thank you for the thoughtful write-up. Lots of actionable items here, I'm a
huge fan of #4. I'm working on an app for retros, signalshq.com, and already
see 2 or 3 points from this that I can build into the app.

~~~
trcollinson
I'll definitely check it out! Sounds like fun.

