A few years back, I experienced what I will call “the true cost of a non-safe team environment”. I was working on a program-level initiative and had worked up an email (names changed to protect the innocent) to a remote member of our team that reads something like this:
“Barb – we really need a Product Owner Sync meeting for our larger programs. I can start documenting this tomorrow. Your thoughts? Thanks, Mike H.”
Total time: 1 minute (hey, I type with two fingers only!).
Right before hitting the SEND button, I was hit with a jarring set of recollections…
I recalled instances in which my words had been misunderstood within our team, and times where my words were met with retribution and ridicule. I remembered getting halfway through my first sentence and being cut off once the listener figured out what point they thought I was going to make (they were wrong). I remembered struggling to get a word in edgewise because as a team, quite frankly, we were poor listeners.
Then there was that time when I offered up what I thought was a helpful suggestion and the idea was misinterpreted causing a long circuitous conversation for clarity. There was that feeling of assumed negative intent.
Then I recalled a time where I made a polite casual comment for everyone’s awareness and was immediately labeled “negative”.
After a few minutes of pondering the lack of safety amongst our team, I yearned for a team environment where safety and courage were first-order values. I thought about times in the past where I had been part of high-performing Scrum teams where team safety was the norm. Then I crash-landed back to reality.
If I hit SEND:
- She may think I am complaining.
- She may already be aware and think that I am obtuse (with apologies to Shawshank Redemption)
- She may think I am trying to show off my knowledge
- She may think I am pointing out the deficiencies of the current team for not recognizing this previously
- And finally, she may think I don’t have enough to do (the horror!).
So, what to do? I began a laborious edit on my email to ensure that (hopefully) nothing could be misconstrued or taken the wrong way. My newly crafted email ended up like this:
“Barbara – thank you so much for all you do. I just love working on this team!
Yesterday’s discussion on the scaling aspects of our Agile transformation was great. As the resident expert on scaling Agile, how do you think it went? As I investigate the different scaling approaches out there (SAFe, Nexus, LeSS, etc.), I am noticing a trend towards maintaining synchronicity between all team Product Owners involved in the program. Do you notice the same? I have experienced this in the past, but since I am relatively new to this team and don’t yet have the full picture of the program context here at <business name withheld>, I’m not sure if it applies or not. I am very curious about your experiences.
If your experiences are similar to mine, then how would you recommend we convey this information? Should we do an update of our Program Synchronization artifact, or a lunch & learn, or a small class segment on the topic? How are these situations typically handled? Or, is it even worth pursuing right now given the challenging situation of our current priorities?
As you can see, the intent of this email is to explore the possibility that there might be a potential need for our program managers managing the larger programs. I’m not sure at what point the size issue tips over into this need, but I thought I would check with you first. I am aware that you have worked closely with many/most of these large program leaders in the past, so hopefully, you will be able to provide me with some directive guidance.
Please advise. Have a great day, and I am looking forward to our next face-to-face discussion.
Thanks, Mike H.
Total time: 2.5 hours due to wordsmithing and imaginary role-playing to reduce anxiety. From 1 minute to 150 minutes. If my math is correct, that is a 14,900% increase in waste. Lean purists are rolling over in their graves right now!
I finally pressed the SEND button. Several of the Scrum values came to mind as I heard the swoosh of a successful send, most notably:
- Courage – the willingness to create an environment of psychological safety where team members can speak their minds without fear of retribution
- Openness – be open about the work and our interactions with others, no hidden agendas
- Respect – every team member is capable and deserves our respect, always assume positive intent
I like to think of my work team as an extension of my family. The best work situations occur when there is a family-oriented environment embodying the Scrum values mentioned above. In families, we have courageous and difficult conversations every now and then. Feelings sometimes get hurt, but we mend it. Our intentions are understood to be honorable. We rely on love and mutual support to move forward – for the greater good of the family.
Scrum teams should feel more like an extension of our families. One way to achieve that is to ensure that your team is safe.
If you are an Agile leader or influencer, you can help your team embody safety by:
- Making your team values both visible and compelling
- Embracing diversity of thought – it leads to better decisions
- Requiring respectful listening skills
- Making sure retrospective topics about team safety are prioritized very high
- Removing the fear quotient – demonstrate (again and again) that this is a safe team
- Demonstrating vulnerability – admit to your own mistakes and preconceived notions
- Viewing failure as a learning event – celebrate each in a small but meaningful way
- Calling out situations where someone is not assuming positive intent
- Understanding that healthy conflict is good – it grows our team
- Publicly thanking team members for constructive feedback.
Do you have some additional insights into the topic of team safety? If so, please share them with us!