Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Adopting Agile by Increasing Psychological Safety in a Software Team

Adopting Agile by Increasing Psychological Safety in a Software Team

This item in japanese

To test the agile way of thinking, a software team worked on their psychological safety with kick-off exercises, sharing coffee breaks, celebrating wins, a stand-up question, and 1-on-1 talks. In her talk at ScanAgile 2023, Pirita Maarit Johnsen shared how they increased psychological safety in their software team.

In the kick-off, the team agreed on their way of working:

  • Use Scrum as a method
  • Only work on this project as far as possible
  • Full transparency towards the client
  • Encourage the client to be part of the team during the whole project

Johnsen mentioned that this was a new approach for the team and the client, where the team committed to testing the agile way of thinking in a project to see if they could gain something from it.

Some of the members of the team had been working together for years and some were new, so psychological safety was not very high at the start, Johnsen said. They did several things to get to know each other and gain psychological safety. In the kick-off, they used several exercises to get people to talk, for example, "Draw your self-portrait blindfolded", which broke the ice and got people talking, Johnsen mentioned.

Johnsen encouraged team members to talk more with each other, not only about technical topics, but also about personal topics, their hopes and frustrations, while the new ways of working were implemented in the team. To enable these talks, she organized shared coffee breaks with cinnamon buns, which got people together and talking in a more relaxed setting.

Celebrating the wins was also something she asked team members to do, no matter how small the win was:

It let them see the progress in the project and also created more of a team spirit which then led to increased psychological safety.

In the stand-ups, they used one specific standard question, "How can you collaborate with others today, or is there something you need help from someone else?" This made the start of collaboration easier and increased communication between the team members, Johnsen said.

Johnsen also had 1-1 talks with all the team members to get to know each other better on a personal level:

We both revealed more of who we are, what interests we have and our preferences on work practices. In this way, we discovered common interests and topics to talk about outside the technical questions.

Johnsen shared her learning from the agile adoption in the software team:

What did work was:

  • Clear communication about the agile methodologies and mindset
  • In the beginning: keeping the process simple to create good habits, like daily standups
  • Letting the team decide what to do, even if they might fail; that way the team discovers the best ways of working for them

What didn’t work:

  • Forcing someone to use agile methods
  • Telling people what to do and not explaining why; for example, you need to explain why retrospectives are important

Johnsen mentioned that she was not acting as a classical team lead, but used more of a mentoring approach:

I’d give them examples from theoretical cases and other team’s experiences and then let them decide what methods they wanted to try out.

During the project, the team members experienced how the agile way of working was helpful for their daily workload, Johnsen concluded.

InfoQ interviewed Pirita Maarit Johnsen about adopting agile.

InfoQ: How did the team members experience the change towards agile?

Pirita Maarit Johnsen: The team members had a range of experiences and emotions during the change towards agile. Some were positive and embraced the change, while others were more hesitant or uncertain. Examples of the words they used to describe their experiences were: "confusion", "bureaucratic language", "change is good" and "someone else’s plan".

We interviewed team members at the end of the project and one of the questions was about the information given about the change towards the agile organization. One person mentioned that, "information was given but not in a language that was understandable, but it has improved a lot".

To the question if we have reached our goal with the change, one person answered, "No, this takes time, and it’s good that it takes time. Then we don’t stop, we don’t stop developing. It drives us to learn more when something happens around us."

InfoQ: What are your suggestions for establishing and fostering change toward agile in organizations?

Johnsen: My experience from several places is that managers and tech leads push the change towards agile without even knowing why they want it. Usually, it’s something that consultants have been telling the managers and leaders to do because "it’s really hot and cool and it makes your company survive!"

In these cases, the leaders often think that just adhering to a method (like Scrum) is enough and that the change happens by telling the people (in this case the developers) what to do, without telling them why to do things in a particular way.

And then if you fail, the people will resist and will carry out the instructions mechanically or not at all, and the true potential of the agile mindset is not reached.

About the Author

Rate this Article