How do you get people to tell the truth at a retrospective meeting?

Recently I saw a bunch of discussions about the retrospective meeting:

The general idea is that the sufferer lamented that the retrospective meeting is the most difficult meeting to hold, and the real opinions are often said only after people leave. They are all determined to leave, what else can't or dare not say?

But from my observation and personal experience: those who decide to leave are often the hardest to get a real opinion. It's not that I can't say it, I dare not say it, but I don't want to say it.

When people choose to leave voluntarily, no matter the reason, the end result is to leave the company. Everyone wants to get together and break up, and what you can say at the retrospective meeting will naturally become the premise of not offending people. Think about it, a guy who is going to leave tomorrow is pointing at this company, this equipment is too bad, that process is too cumbersome... Don't you feel like you want to get rid of him?

Today, let’s talk about how to get people to tell the truth at the retrospective meeting:

1. Not grouped

The two teams adopted different methods for the order in the retrospective meeting: Team A let everyone sit at random, and everyone took turns to publish; Team B published in groups.

I think it's easier for Team A to get the real voice. The group leader usually explains the group-by-unit presentations first. If there are no questions, it's easier for the group members to swallow what they originally wanted to say in order to "get the crab".

In addition, it is easy to focus on the matters related to the group while ignoring the matters related to the process and the team. As always heard: the iOS group went well this week, no problems. But the problem you observe is not extremely related to the iOS group, it may be the problem of finding the boss and other groups, forgetting or not wanting to say because the focus is on iOS.

2. Everyone must propose good things and things to improve

This seems to be one of the essential elements of a retrospective meeting. However, if it is written in the textbook and not really implemented, it often becomes a meeting that announces good news but not good ones.

My experience is: PM asks directly, did anything happen this week? Although it may sound good or bad, without coercion, people tend not to speak ill, and with the addition of 1) group inquiry seems to be a bit like: if there is any problem, it is not my group leader wrong? So would I still tell you what went wrong?

How to actually implement it? Our approach is to send a piece of paper for 5-10 minutes, and ask everyone to write down the good things and the things to be improved on the paper. When publishing, they must also declare 1) the good things 2) the things to be improved. . It's also easier for people to speak (write) the truth by forcing everyone to think about what happened in this sprint.

3. Propose solutions to the issues to be improved

Opinions at retrospective meetings tend to be sensitive issues, and a careless one sounds like a complaint. But if you come up with a solution and put it forward at the same time as you put forward the items to be improved, you will have a better psychological construction for the person who proposes: I am not just complaining, but there is a solution! People who listen also easier to accept.

For example: In this sprint, I changed a function and found that I had to change 20 places. There is a problem with this code!

become

In this sprint, I changed a function and found that there were more than 20 places to be changed. It is recommended that CI import the DRY plugin, track and try to reduce the duplicate code.

Is it right away from a complaint to a constructive improvement project.

4. The most important step is also the most difficult step, face and really solve the problem raised

Problems within the team are relatively easy to solve. Our approach will write down the problems that everyone wants to solve first and paste them on the whiteboard, such as: making the server-client integration smoother through API files, and reviewing whether they have been implemented in the retrospective meeting of the next sprint And solve the problem we want to solve? If not, what is the problem?

In this way, team members can clearly feel that the opinions raised are really listened to, and they are tracked visually, so that they will not disappear in a dark corner for no reason! We took the risk of being hacked. Opinions are really accepted and have a positive impact on the team! This kind of obvious feedback will be the best encouragement for team members to come up with real suggestions again next time.

Outside of the team, it's quite difficult, and aside from a strong scrum master support and a competent manager, I haven't gotten to that level to deal with those issues.

2014.1.21