RESOURCES

Cultivating Psychological Safety in Agile Teams

About this Publication

High performing teams require psychological safety. As such, Agile teams need to feel that they can speak up without any repercussion whatsoever. While this may seem trivial, many Agile teams operate in an environment that forces them to avoid difficult conversations and tiptoe around the truth. This report will outline the benefits that Agile teams can expect to receive from the adoption of psychological safety. It will also explain the role of leaders throughout the adoption. For readers that are familiar with psychological safety but unfamiliar with Agile concepts, they will likely appreciate the applicability of psychology in the world of technology as this age of digital disruption affects us all. For the Agile readers that are unfamiliar with psychological safety, they can expect to receive an understanding of behaviors that were previously misunderstood but are now brought to the forefront so they can be addressed. In essence, psychological safety is not a luxury for Agile teams. It’s a necessity.

1.     INTRODUCTION

“Psychological safety means no one will be punished or humiliated for errors or questions in the service of reaching ambitious performance goals.” [1]

On February 1, 2003, the space shuttle Columbia burned up on re-entry into the Earth’s atmosphere, killing all seven astronauts.

Eight days prior (during liftoff), it appeared that a chunk of insulating foam may have struck the left wing of the shuttle.

While trying to voice this concern, the engineer that made the discovery was discouraged by his futile attempts. He decided not to pursue the issue any further as he feared there might be career consequences.

As we can see, the lack of psychological safety can have dire consequences.

Google conducted a 2-year study on team performance (i.e. Project Aristotle) [2]. They found that the high-performing teams had one thing in common. They all had psychological safety. While the space shuttle example may seem like a one-off, healthcare professionals are faced with such difficulties every day. In their world, the absence of psychological safety can also result in death. For Agile teams, psychological safety is not a nice-to-have.

Throughout my career, I’ve witnessed many situations where people felt psychologically unsafe. In many of those cases I was unaware of the phenomena nor was I aware of the impact. I believe this experience report needs to be told so that others feel empowered to examine and promote psychological safety amongst Agile teams.

This experience report will not just focus on the experiences themselves, but it will also detail how you can put this into practice, discuss the overall benefits, and express what leaders can do to help.

2.     Experiences

Throughout my career I have witnessed many unsafe environments. Here are just a few.

2.1        Experience #1

Recently I was working with a team where there was a clear division between senior and junior developers that had existed for quite some time. The seniors made all the decisions while the juniors felt powerless. As the Scrum Master, I ran a retrospective (see Practice 3.1) with the team where I explained the concept of fixed vs. growth mindset. I then asked them to identify areas where they felt the team had adopted a fixed mindset. And then the same for a growth mindset. The whiteboard was almost entirely filled with fixed mindset items. As we talked through the items, the juniors felt empowered to speak up. Even though they had been through many retrospectives where they were asked to identify improvement items, they had never felt empowered to speak up about things that really mattered. Reframing the conversation from “improvement” to “mindset” seemed to promote an open dialogue.

Unfortunately for this team, action may have been taken too late. Less than one month after the retrospective, one of the team members left the organization entirely and two others were removed from the team. The lesson learned in this example is that when trying to instill a culture of psychological safety, waiting for the most opportune moment can have unexpected consequences. Some people will not wait for change to occur and instead opt for employment elsewhere.

2.2        Experience #2

Another example is when I took part in a SAFe PI Planning event. There were multiple Agile teams (over 100 people) trying to come up with a plan for the next 3 months in just 2 days. Towards the end of the 2nd day, a confidence vote was held. Essentially, everyone in the room is required to show their vote 1/2/3/4/5 fingers at the same time (i.e. fist of five). In SAFe, a 3/4/5 is considered a pass. Everybody voted a 3/4/5, except me. I voted a 2. It was clear that some people wanted to vote a 1 or a 2, but the psychological safety just wasn’t there. After all, “no one was ever fired for silence” [6]. What happened next was quite interesting. After I expressed “why” I felt the way I did, others chimed in and changed their vote to a 2 as well. It seemed that once I led the way with my vote, I inadvertently encouraged others to speak up (see Practice 3.2).

This pattern was repeated at future PI Planning events. While that was a step in the right direction, there seemed to be a threshold of psychological safety that the organization was unable to overcome. The only time anyone was comfortable speaking up, is when I started the conversation. Many people expressed to me that they would not have spoken up if I had not initiated the dialogue. I think this highlights the point that there are various levels of psychological safety as opposed to a yes or no determination as to whether an organization is psychologically safe.

2.3        Experience #3

Measuring psychological safety can be a huge benefit. To do this, I ran the Explorer/Shopper/Visitor/Prisoner retrospective (from Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsson). Keeping a tally of each role is the measurement I tracked. I ran the exercise with one team every 3 months for a year (see Practice 3.1). Even though the exercise is not aimed at psychological safety, I found that at the end of the year we didn’t have any prisoners. Every time I ran the exercise, we talked about the results and why we thought they appeared the way they did. Then we came up with some actions which made it into our backlog and the overall results improved every quarter (see Practice 3.4, “improvement items”).

Another approach is to incorporate the “Happiness Metric” [3]. At the end of each sprint each team member answers four questions:

  1. On a scale from 1 to 5, how do you feel about your role in the company?
  2. On the same scale, how do you feel about the company as a whole?
  3. Why do you feel that way?
  4. What one thing would make you happier in the next Sprint?

By making these incremental improvements every sprint, you can easily determine the impact it is having on your velocity.

I ran the Explorer/Shopper/Visitor/Prisoner retrospective with another team with different results. They had a prisoner throughout, but it was not due to lack of psychological safety. It was due to the fact that the individual saw no benefit to Agile nor the various ceremonies (including retrospectives). It’s important to determine the outcome you’re hoping to achieve and then look at metrics that will provide indicators towards that outcome, not the other way around. If we look at the second example, suppose an organization is looking to reduce its turnover. The Happiness Metric could be a tool that is used to measure how the organization is performing towards their goal of reducing turnover. If they were to start with a metric with no clear outcome, the metric is likely to provide little to no value.

2.4        Experience #4

While working with a DevOps team who had a lot of pride and never wanted to admit when they were wrong, I created a space where they could comfortably do so. At the end of every week in our standup, we had a 60 second segment called “Mistake of the Week.” Anybody on the team could use this time to declare their biggest mistake of the week (see Practice 3.4, “it’s ok to make mistakes”). 60 seconds was typically more than enough because everybody already knew about the mistake. This usually ended with “I’ve been there” or “I know exactly how you feel.”

What we discovered is that simply identifying the mistake is not enough. The team needs to discuss how to prevent the mistake from happening again. In fact, that’s the real magic behind admitting to your mistakes. If a team member admits to a mistake and then continues to make the same mistake, they aren’t learning. Furthermore, some teams are quick to determine that a peer review will solve the problem going forward. While that may be true, it still doesn’t identify the underlying problem in the first place. Maybe the onboarding process didn’t include a thorough explanation of a particular infrastructure. Whatever it may be, the team should take the time to identify the ‘real’ root cause.

3.     Putting it in Practice

3.1        What are the next steps for an Agile Team experiencing an unsafe environment?

If the team or the Product Owner is witnessing an unsafe environment, they need to vocalize this as soon as possible. Essentially, this should be brought to the attention of the Scrum Master. Ideally, the Scrum Master has already observed this but that is not always the case. The Scrum Master can then talk to each team member one-on-one, or they can broach the topic in a retrospective. They could also perform a combination of both. By asking powerful questions, the Scrum Master should try to uncover the underlying issue. In some cases, the team may have had high psychological safety, but an event occurred that depleted it. The Scrum Master should also try to determine if the source of the low psychological safety is primarily internal or external to the team. For instance, one team that I worked with had very low psychological safety, which was largely due to the one developer who ridiculed everybody else’s code (internal). Another team I worked with was uncomfortable having open conversations because a team member had been fired and nobody provided an explanation as to why (external). Scrum Masters should also try to identify whether the absence of psychological safety is specific to the team or whether it exists amongst other teams. This could be a discussion topic for a Scrum of Scrums. Once Scrum Masters are able to answer these questions, they are better enabled to proceed accordingly.

3.2        Who is responsible for psychological safety?

The responsibility of psychological safety should lie with the Agile leaders. Agile leaders do not have to hold a ‘C’ level position. In fact, anyone can fulfill the role of an Agile leader. “Moreover, only these leaders can create an environment that encourages high-performing Agile teams to flourish and produce value. Leaders, therefore, must internalize and model leaner ways of thinking and operating so that team members will learn from their example, coaching, and encouragement” [7]. With that said, Agile leaders in organizations need to understand that they have a large part to play and they need to support the teams. They can help invoke high psychological safety by reinforcing psychological safety, having difficult conversations, participating in conflict resolution, and removing (or addressing) team members that limit the psychological safety. When adding team members, the interview process may include questions around psychological safety (e.g. Do you typically feel comfortable speaking up? Why is that?). The hiring process can be a good place to start for Agile teams that are looking to increase and instill psychological safety.

3.3        How do you apply psychological safety from an organizational perspective?

Simply put, leaders need to lead. In many cases, that means leading by example (see What can leaders do?). However, this is only possible if leaders realize there is a problem. All too often, people are outraged by a particular problem(s) and fail to notify anyone. When Agile teams are faced with unsafety, it may be beneficial to determine if other teams are experiencing similar levels of psychological safety. If a pattern exists, the issue may need to be escalated. Scrum Masters and Agile coaches are well equipped to handle this and may need to band together to raise awareness (i.e. power in numbers). This goes back to Practice 3.2 where it was identified that Agile leaders (which can include Scrum Masters and Agile coaches), need to understand their greater role.

3.4        How can you increase psychological safety?

  • Moving the team to a new location may reduce/eliminate fear.
  • Changing the style of communication may allow others to be more vocal. Instead of asking the three questions at every standup, try “walking the board” [5].
  • Reinforcing the fact that it’s ok to make mistakes. Add information radiators where applicable (e.g. posters stating “Fail fast, Fail often”).
  • Having an open discussion when team members are removed from the team (i.e. explain ‘why’).
  • Sending a clarifying email to the stakeholders.
  • Suggesting a different perspective on a conference call (e.g. priority of the backlog).
  • Soliciting feedback from a team member/Product Owner/Scrum Master.
  • Admitting that the sprint goal won’t be met.
  • Holding offsite retrospectives. People are much more willing to speak up when they’re physically out of the office.
  • Identify where you’re at and add improvement items to the backlog

3.5        If the CEO is creating an unsafe environment, what can be done?

Possibly start with gathering specifics about what the CEO is doing that promotes an unsafe environment. For example, the CEO may have mandated a transition to Agile but has done nothing exhibit Agile behavior. If one person is taking notice, chances are others are seeing this as well (see Practice 3.1, “scrum of scrums” and Practice 3.3, “power in numbers”). Forming a guiding coalition can pay dividends in the long run [8]. The next step could be to measure the current state of psychological safety. One possibility is to conduct this by eliciting feedback via a survey. Eventually the CEO will need to be notified of the current state of affairs. Practicing the conversation before it takes place can be an immense benefit. It can start off by explaining the concept of psychological safety and why it is important (see Practice 3.2). From there the discussion can incorporate the current findings. Some CEOs will be receptive, and others will not. If the CEO is not receptive and change is unlikely to occur, it may be time to consider employment elsewhere.

4.     THE BENEFITS OF PSYCHOLOGICAL SAFETY

Encourages speaking up: All too often people refrain from speaking up because they don’t want to be seen as ignorant, incompetent, negative, or disruptive [1]. Agile teams need to operate without fear of speaking up. While keeping quiet may keep us personally safe, it can put the organization at risk [6]. When the team feels safe, they’re able to articulate their concerns without the distress of negative reactions. For example, when conducting story estimation, it can be tempting to fall into groupthink and just agree with everyone else. The consensus may be that the story is 5 points. However, one individual may feel that the story is much larger based on previous experience with similar type of work. When psychological safety is present, the individual communicates their opinion without hesitation. The rest of the team may not agree, and the team may ultimately decide to proceed with the 5-point estimate. The point is that the individual was heard, and a discussion occurred. Furthermore, the individual is likely to continue to speak up and they will likely encourage others to speak up. It may seem that psychological unsafety is analogous to groupthink. However, that is not the case. Groupthink can occur in teams where psychological safety is present. Also, psychological safe environments can endure groupthink. The main difference is that groupthink isn’t based on fear.

Enables clarity of thought: Simply focusing on the task at hand rarely produces the best result. Unsafe environments restrict free flow thinking. Agile teams need to “think outside the box”. For instance, the team may be faced with a story that is unlike anything they’ve ever encountered. A psychologically safe team may respond by vertically splitting the story and then identifying a spike (or exploration) that would commence prior to the vertical slices. In this scenario the team actively engages in exploration, analysis, and design. Whereas an unsafe team may respond by accepting the story at face value and proceeding without even knowing how they will test for “doneness.” The lack of clarity typically results in the story carrying over from sprint to sprint.

Supports productive conflict: Intra-team and inter-team conflict will occur. In unsafe surroundings, this conflict can be hostile and can sometimes escalate to a “win at all costs” mentality. Agile teams need conflict of a different kind. They require healthy conflict. The presence of psychological safety allows teams to express their differing opinions in a way that leads to better decision-making. For example, two team members may disagree on refactoring. One team member may have the opinion that while refactoring is a worthwhile technique, it can be taken too far which can result in exceeding the original estimate and possibly introducing unnecessary risk. Another team member may have the opinion that refactoring should be applied relentlessly, regardless of the situation. Without a feeling of safety, the team member that advocates for refactoring may just proceed with the changes and hope that it goes undiscovered. In this situation, the changes are eventually discovered, and an unhealthy/unproductive conflict is likely to ensue. When there is a sense of safety, a team member will not try to operate from behind the scenes. Instead, they’ll have a discussion with another individual or the team at large. Not only will they work together to solve the problem at hand, but also they’ll likely discuss process or protocols for when the matter occurs again in the future.

Mitigates failure: The word ‘failure’ typically has a negative connotation. Most of us have been taught from a young age that failure is a bad thing and should be avoided at all costs. The reality is that we all make mistakes whether it be in our personal or professional lives. And pretending that we’re perfect puts us at a disadvantage. “A lack of psychological safety can create an illusion of success that eventually turns into serious business failures” [6]. Psychological safety not only makes it safe to make mistakes but more importantly it makes it safe to admit mistakes. That is not to say that we never want to succeed or that psychological safety encourages failure. The idea is that instead of punishing people when things don’t go as planned, we should try to learn from the experience [1]. Ideally, Agile teams should feel little or no anxiety when reporting errors. For example, during a retrospective a team member may report that the build failed because they did not apply proper due diligence during the code merge. The other team members may then suggest opportunities to prevent that from happening again. They may suggest that more frequent merging should be the new norm, or possibly performing “pair merging” when merge conflicts arise. In an unsafe environment, the team member (and others) probably wouldn’t even mention the broken build or the fact that it was a result of a bad code merge and just hope that it went undetected. When these practices continue, they tend to add frustration and reduce quality.

Promotes innovation: When people feel safe to suggest novel ideas and possibilities, amazing things can happen [1]. Organizations that have this sense of safety are able to provide products and services they never would have imagined. Agile teams require psychological safety so they can make recommendations to Product Owners or Product Managers. That is not to say that all recommendations will be added to backlog and eventually implemented. But there are times when an idea comes from the team that can revolutionize the product or service. For example, a team may build an in-house tool that helps them to work more effectively. Eventually they may realize that Agile teams around the world are faced with similar problems. It is not uncommon for Agile teams to commoditize an in-house tool that provides another source of revenue for the organization. Without psychological safety, innovation is not possible, and without innovation the possibilities are extremely limited which makes it difficult for organizations to compete.

Removes obstacles to pursuing goals for achieving performance: Unsafe environments can impose barriers towards achieving ultimate performance. While most Agile teams want to deliver as many story points as they can, they may be impeded by the perceived (or real) backlash of speaking out. For example, an Agile team may realize that another team with whom they have lots of integration efforts with, is bringing lots of toxicity to the work atmosphere. In an ideal situation, they might speak with the other team or escalate if necessary. When psychological safety is not present, the team not only choses to live with the toxicity, but they’re unable to perform at their best. Not only do the integration efforts take longer than they should, but it will likely be of lesser quality. The relationship with the customer may start to deteriorate as trust starts to diminish. This affects morale and leads to frustration. “Without psychological safety, it is difficult for expertise and ingenuity to be put to good use” [6].

Increases accountability: Ideally, organizations have high psychological safety and high accountability [1]. When both are present, learning and collaboration can happen seamlessly. When neither is present, people typically put in minimal effort and do just enough to get by. Agile teams require a high degree of both. This allows them to reach out to other team members when they’re stuck. In fact, some Agile teams impose a rule (as part of their working agreement) that they must ask for help after being stuck after x number of minutes. In this type of environment, people welcome increased accountability. When Agile teams lack psychological safety, they may feel embarrassed to ask for help. The end result is that they deliver their work extremely late or not at all. This not only reflects poorly on them, but also the team.

Figure 1: Psychological Safety and Accountability [6]

 

When there is low accountability and low psychological safety (i.e. Apathy Zone), Agile teams are less concerned about shared goals [1]. They typically complete their work in siloes (i.e. lack of pair programming) and are not invested in achieving sprint goals. In high psychological safety but low accountability environments (i.e. Comfort Zone), Agile teams generally get along with one another, but they don’t feel challenged. Their velocity doesn’t really increase because there is little to no learning or innovation. High accountability and low psychological safety (i.e. Anxiety Zone), puts a lot of pressure on Agile teams. Teams may respond by putting in lots of overtime, which may seem favorable. However, that type of action typically results in stress and low quality. Defects that are discovered late can be the norm for this zone. When both accountability and psychological safety are high (i.e. Learning Zone), Agile teams work seamlessly to complete their work. They are often seen practicing XP techniques or looking for ways to improve.

5.     What Can Leaders Do?

Be accessible and approachable: Agile teams should not have to go through multiple communication barriers just to be heard. Leaders need to be available and they need to create an environment where people feel safe to approach them. Imagine if the CIO that was leading an Agile transformation decided to give up his/her office and sit with the teams. Open and honest conversation would surely happen. In fact, in this situation there would also be a side benefit where the CIO would learn quite a bit through osmotic communication, which would allow them to remove barriers sooner. Additionally, leaders need to recognize that psychological safety will differ amongst the various Agile teams and they may need to focus on some teams more than others.

Acknowledge the limits of current knowledge: So often, leaders refuse to say “I don’t know.” This act of perfectionism can create distrust between leaders and Agile teams. Instead, leaders should be willing “to publicly express the fact that they don’t have the answers to every issue or challenge” [1]. When Agile teams see their leaders acting in this way, they are more likely to act in the same way. In fact, leaders can improve the dialogue by responding with, “I don’t know, but I’d like to hear what you have to say.” Envision what would happen if that conversation were to take place in a Sprint Review, for example. Leading by example can be extremely powerful. Author Simon Sinek underscores this importance in his book Leaders Eat Last: “The leaders of companies set the tone and direction for the people. Hypocrites, liars, and self-interested leaders create cultures filled with hypocrites, liars, and self-interested employees. The leaders of companies who tell the truth, in contrast, will create a culture of people who tell the truth. It is not rocket science. We follow the leader.” [9]

Display fallibility: Most people want feedback and leaders are no exception. When creating psychological safety, leaders are more than willing to request feedback from Agile teams. You may hear them say, “what can I do better,” or “what’s one decision I made that you’re not happy with,” or “I made a mistake…” By doing this, leaders are showing respect for the opinions of others. When Agile teams feel respected, they’ll be more open to making suggestions for improvement, not just at the team level but also enterprise wide.

Invite participation: Leaders need to find ways of explicitly requesting input from Agile teams or possibly individual Agile team members. Not all Agile teams are software development teams, but many are, and they are typically staffed with highly skilled people who may be introverted and have a reluctance to speaking up. Leaders can create opportunities to temporarily remove job and time pressures [1]. For instance, they can take individuals or an entire Agile team out for coffee. During these coffee breaks, leaders can probe by asking powerful questions, versus leading or rhetorical ones. When people feel their input is valued, they’re typically more responsive. For instance, during one of these sessions an Agile team may express that off-site retrospectives were highly valuable and are disappointed that the organization decided to eliminate that option.

Highlight failures as learning opportunities: Celebrating failures is not something you see very often but it can be quite powerful. Agile teams make mistakes all the time. In fact, we need them to make mistakes. It’s how they learn. It’s also how they innovate. Leaders should not be punishing mistakes. Instead, they should recognize it. Great things come from Agile teams that aren’t afraid to fail. Unfortunately, many teams have a fear of admitting failure because they don’t want to be seen as incompetent or they don’t want to be reprimanded. “Fear inhibits learning,” furthermore “fear is not an effective motivator for jobs where learning or collaboration is required for success” [6].

Use direct language: Many people steer clear of direct language because they want to avoid conflict or avoid appearing rude. However, in many situations direct language is required otherwise a lot of time is wasted. Leaders should use direct language with Agile teams while being respectful at the same time. This can be especially beneficial when priorities are changing. Leaders need to articulate how the team has performed and praise their efforts, but they also need to explain the change in direction and also indicate ‘why.’ This starts to build trust. “Trust begins to emerge when we have a sense that another person or organization is driven by things other than their own self-gain. With trust comes a sense of value—real value, not just value equated with money. Value, by definition, is the transference of trust. You can’t convince someone you have value, just as you can’t convince someone to trust you. You have to earn trust by communicating and demonstrating that you share the same values and beliefs. You have to talk about your WHY and prove it with WHAT you do” [4].

Set boundaries: It may sound counterintuitive but psychological safety is more present when leaders establish and clarify boundaries. Boundaries that are subject to guesswork result in unsafe environments. Agile teams are well versed in boundaries. Iterations have a specific duration (e.g. two weeks) and daily standups are timeboxed (usually 15 minutes). But leaders can take this a few steps forward. For example, they can insist that everybody undergo Agile training on a regular basis. In some organizations, employees are offered severance packages if the employee decides they don’t want to participate in the Agile transformation and would rather find employment elsewhere.

Hold people accountable: There are situations where people do need to be fired or punished. What is typically missing is an explanation of ‘why.’ When there is no justification, others immediately begin to think that the same thing could happen to them. Leaders need to acknowledge that “competent professionals make mistakes and … even develop unhealthy norms (shortcuts, ‘routine rule violations’)” while maintaining “zero tolerance for reckless behavior” [1]. As such, leaders need to hold Agile teams and individual team members accountable. There are situations where people attend all the Scrum ceremonies but refuse to operate in an Agile manner. Sometimes, people choose to work in a negative way. “Anyone who causes emotional chaos, inspires fear or dread, or demeans or diminishes people needs to be stopped cold” [3]. Leaders need to decide what is acceptable and what is not (see Set boundaries). And when the boundaries are not being respected, they need to be decisive and be willing to rationalize their decision.

6.     Acknowledgements

A special thanks to my shepherd, Niels Harre, I could not have done it without you!

REFERENCES

[1] Edmondson, Amy C. Teaming: How Organizations Learn, Innovate, and Compete in the Knowledge Economy.  John Wiley & Sons, Inc., 2012

[2] Delizonna, Laura, “High-Performing Teams Need Psychological Safety. Here’s How to Create It” Harvard Business Review, 2017. Web page: https://hbr.org/2017/08/high-performing-teams-need-psychological-safety-heres-how-to-create-it

[3] Sutherland, Jeff and Sutherland, J.J. Scrum: The Art of Doing Twice the Work in Half the Time. Crown Publishing Group, 2014.

[4] Sinek, Simon. Start with Why: How Great Leaders Inspire Everyone to Take Action. Penguin Books, 2009.

[5] Fowler, Martin, “It’s Not Just Standing Up: Patterns for Daily Standup Meetings” Web page: https://martinfowler.com/articles/itsNotJustStandingUp.html

[6] Edmondson, Amy C. The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth. John Wiley & Sons, Inc., 2019.

[7] Scaled Agile Inc. “Lean-Agile Leadership” Web page: https://www.scaledagileframework.com/lean-agile-leadership

[8] Kotter, John P. Leading Change. Harvard Business Review Press, 2012.

[9] Sinek, Simon. Leaders Eat Last: Why Some Teams Pull Together and Others Don’t. Penguin Books, 2014.

About the Author

No bio currently available.