Psychological Safety in Agile Teams

Think back to the first time your code was under review. As the dread of receiving negative feedback looms over you, someone yells at you, “HEY! Don’t be scared. You need to feel safe”.

Unless you are a bot, chances are this does not make you feel any safer!

Psychological safety in a team is the belief that making mistakes, taking risks, and sharing ideas, opinions and concerns are acceptable, and the individuals who do so do not face repercussions or judgments.

The extent to which individuals feel safe in their work environment directly impacts their willingness to contribute as team players.

Psychological safety, as a belief, is very individual. You cannot directly control the level of safety any team member feels.

When teams feel psychologically safe, they embrace mistakes as learning opportunities and engage more in open communication.

What Reduces Psychological Safety?

In the coding world, fear of judgment and failure contribute to low psychological safety. During code reviews and pairing sessions, developers expose their way of working and unique thought processes. This could lead to their fear of being judged in terms of competence and the mistakes they make.

Some signs of decreased psychological safety could be -

• Bias towards following processes as opposed to mastering practices and blaming the process when something goes wrong
• Resistance to trying new things or taking risks
• Not expressing ideas or speaking up during meetings and discussions
• Hesitant to give feedback, only resorting to giving anonymous feedback
• Fear of embracing failures and mistakes

Psychological Safety Improves During Co-creation

When developers work in isolation, they may make their code perfect over multiple iterations before publishing it.

This published code sets a very high standard for everyone else on the team. However, no one has seen or realized that the code seems to look spotless due to multiple iterations.

Co-creation lets you see the mistakes of others, their process, and finally, the outcome.

Once you can see others making mistakes, you feel safer making mistakes too!

Pairing, a practice in extreme programming and a type of co-creation allows team members to collaborate in coding activities, simultaneously seeing and accepting each other’s mistakes. It has a high impact on psychological safety.

When you co-create more, you start to feel psychologically safer.

The diagram above shows this cycle:

• The more you co-create, the more you see others making mistakes
• The more you see others making mistakes, the more you are open and accepting of errors
• The more you accept mistakes, own and of others, the more everyone feels psychologically safe
• The more everyone feels safe, the more they co-create. The loop continues.

Reduce Batch Size to Increase Safety!

Kent Beck famously said, “Make it work, make it right, make it fast.” (In that order!).

A piece of code evolves as follows:

1. It first solves a specific problem.
2. It is then refactored to be maintainable.
3. If necessary, it is changed to perform better.

In most organizations, these stages of evolution are not visible. Everyone directly sees the end state of the code through processes like pull requests(PRs).

As a result, others feel they must also showcase only their polished code, decreasing the likelihood of the entire team showing their work early in the SDLC.

So they wait on these changes until it piles up, resulting in a mountain of different work items batched together. As the batch size of PRs increases, so does the size of failures. Bigger the post-release issues, the more unsafe the developers feel!

Now, imagine you are continuously releasing small, incremental changes. You are automatically reducing the size of possible failures and thus the repercussions, aren’t you?

By draft PRs, teams are encouraged to see how code evolves from mediocre to “perfect,” i.e., seeing a piece of code go through multiple iterations. The developers also reduce the batch size by showcasing their work early and frequently.

The diagram above shows this cycle:

• The bigger the size of the failure, the less safe someone feels
• The less safe someone feels, the less likelihood of exposure to early work
• The less likelihood of them exposing their work early, the larger the batch size becomes
• The bigger the batch size, the higher the potential for failure, and the loop continues.

Combining both system diagrams gives you a better understanding of the levers or knobs that positively and negatively impact psychological safety.

• Pairing helps increase psychological safety as developers are open about their mistakes.
• Draft PRs help increase safety and decrease batch sizes.
• Sharing and learning from failures increases the psychological safety of a team.
• Higher psychological safety leads to a willingness to receive mentorship and improve technical competency.

Conclusion

Overlooking psychological safety leads to many consequences in different areas of a company. Unsafe employees feel unfulfilled and contribute to work poorly, affecting an organization’s quality of work and customer happiness.

As a first step, team leaders can lead by example. Acknowledging mistakes and actively seeking and implementing feedback is how you instill confidence in others to do the same.

This slowly moves the needle towards creating a productive and harmonious work environment where nobody feels penalized for making mistakes or restricted from sharing what’s on their mind.

Thanks to Dragan Stepanovic for the inspiration for this blog.