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.
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.
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.
6 comments
[ 2.7 ms ] story [ 35.8 ms ] thread1) 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.