What is the single aspect in a team, that has the highest impact on the quality? Is it their development-practices, technical skills or the number of tests?
The highest impact on quality is …… the psychological safety of the team.
This is a somewhat surprising finding from Amy Edmondson’s research described in her book The Fearless Organization. The result was later supported in The Project Aristotle, where Google identified psychological safety as the number one reason for team performance.
Building quality software is often seen as a technical discipline. However, the results from Amy Edmondson’s and Google’s Project Aristotle show that this is not the most critical area when it comes to quality.
In this article, we will look at what psychological safety is and why it is essential when building software with the right level of quality.
Let’s start with the definition of psychological safety:
In teams with psychological safety, the team members take interpersonal risk and speak up when they are unsure if something is right, or they need help.
The Fearless organization
Psychological safety is essential in agile and lean software development. Some examples of the best practices for agile software development are
- Refining and planning together in the team. This is done in collaboration between the Software developer, Software tester, and Business analyst. And it is essential that team members ask questions for clarification and shared understanding.
- Daily update in the team with focus on knowledge sharing and ask if anyone needs help or input.
- Helping with tasks outside the team-members field of expertise with Mob-programming, Pair-testing and Pair-programming.
It is evident that all these practices require a high degree of psychological safety.
Focus on psychological safety before test-practices
If the quality of the development team is low, it is easy to focus on better test and development practices instead of the team’s psychological safety.
As an example, let’s look at automated tests. Building test automation can help the team get faster feedback and use less time on manual testing. But automated test requires both technical-, test- and business-knowledge.
Technical skills to ensure the automated tests are closely linked to the production code, the low maintenance costs, and the feedback to the software developers is fast.
Testable skills to combine best test practices and knowledge on what should be automated and what should be tested manually.
Business skills to ensure that the requirements and automated tests are aligned.
Teams with low psychological safety will isolate their work into separate areas. They will avoid close collaboration, especially between the software testers, business analysts, and developers.
Their primary focus might be on the technical problem, like what tool to use for test automation and how to link requirements and tests.
The ownership for the tests will be on a few individuals, and the feedback and knowledge sharing within the team will be low.
The result is automated tests that have deficient value and high maintenance costs.
How to foster psychological safety
By practicing, leaders and managers can help grow and foster an environment with high psychological safety.
- Humility, respect that we don’t have all the answers.
- Curiosity, acknowledge that there is always more to learn.
- Empathy to support that taking risks is complicated and should be nurtured.
Understand psychological safety
The most important thing is ensuring leadership, managers, and teams all know what psychological safety is and is not.
Psychological safety is often mistaken as a trust or a safe comfort space for team members. This misconception will undermine the psychological safety within the organization.
Trust is not the same as psychological safety.
A manager or team member can trust another team member to have the skills needed to complete a specific task. Here, the trust mainly focuses on having the technical skills and knowledge required. Having people you can trust to do the job differs from psychological safety.
A safe comfort zone, is not the same as psychological safety
Another misconception is that the teams work best if the team members are in their safe comfort zone. They are not being challenged by questions that bring them out of their comfort zone. Instead, they can work on a problem independently and focus on self-protection. This can lead to team members grouping into areas of expertise.
Psychological safety
Psychological safety is not the same as trust and, in many ways, the opposite of a safe comfort zone.
Psychological safety means team members are actively and willing to take a risk that they might have missed something and that their interpersonal relation is not lost. This can make it uncomfortable in some situations.
Psychological safety limits the development-practices
In my experience, the development practices that a team uses to match the level of psychological safety.
For instance, there are several ways to improve the quality of a team’s code. Here, I have listed 4 different setups, sorted by the level of psychological safety required to implement them.
- Code Review, between software developers.
- Pair programming, with 2 software developers.
- Pair programming/testing with a software tester and developer.
- Mob-programming, where all team members write and review the code together.
All practices have different pros and cons. However, a team with low psychological safety will only use code review and rarely pair programming. In contrast, a team with high psychological safety can use all 4 practices when appropriate.
So, before the team can implement practices to improve the code or build automated tests, be sure that the psychological safety matches their new practices.
