Retrospectives in agile can make me grumpy. Sometimes, we just complain about things. Sometimes, we end up arguing about how something isn’t actually a problem, thus avoiding the “how do we improve this” conversation. Sometimes, we jump in with solutions before we understand the full extent of the problem. Thus, retros can very easily leave me frustrated and just grumpy.
I think a big issue that teams deal with is psychological safety. Amy Edmondson coined the term about team behavior as “Psychological safety is a belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns or mistakes.” Her TED talk on this topic is here. If team members don’t feel like they can speak up without being judged, or if they don’t feel like they will actually be listened to, the entire team suffers. Some of the onus of speaking up falls on the individual, but as a team, we need to make it a safe environment to let people express thoughts and emotions. A big part of that is making sure we know how to listen to each other, listening to understand rather than to reply.
We’re trying something new on our team at Anonyome Labs. During our bi-weekly, end-of-sprint retros for MySudo, when someone talks about something that went poorly or needs improvement, we first ask questions or encourage further discussion. Questions can be something simple like, “Can you tell me more?”, to loosely trying the 5 Whys, to just teasing out where the problem is and whether it’s process or people or workload or something else. Sometimes, what seems to be the problem isn’t the actual problem, and questions help separate the emotional frustration from the problem. When we understand the problem, we move on to the next problem without trying to offer solutions yet. After everyone has talked, then we decide upon action items and experiments.
The experiments seem to be a positive thing. We commit to trying something new for a sprint or two, and during that time, we go all in on it and try to make it successful. In retro, we review those experiments, and at the end of each experiment, we decide whether to keep doing it, abandon it, or tweak it. Labeling something as an experiment is helpful, because it validates feelings and opinions about it while simultaneously encouraging people to give it a chance. When we know we “only” need to do something for two or four weeks, it’s easier to try it out and evaluate it fairly.
Outside of retro, another way we try to increase psychological safety is by assuming team members have concerns about features, stories, or bugs on MySudo, and we proactively ask what those are, rather than waiting for people to bring them up themselves. This, again, validates people and lets them voice their concerns as adding information to the conversation, rather than making them feel like they’re not team players. We build better software this way as well, when we uncover issues before they’re designed in or programmed in. Good things happen all around!
Psychological safety at Anonyome means giving people room to raise doubts and concerns about the software we’re building, the way we’re building it, or the way the team interacts. It allows the team to build community and support each other. When we change how we respond to problems being raised by asking more questions, team members learn to respond to vulnerability with kindness and curiosity, eager to listen and help solve problems where appropriate. And this produces better software as well as making everyone happier and more productive.
