When I talk with other coaches about teams, I hear a lot about “creating safety” and “safe teams”. I don’t hear much about how to do that. While debriefing a coaching simulation the 2010 AYE Conference we listed things coaches did and models coaches might use. Someone said, “Create a safe environment”. I replied, “And how do we do that?” And out came ideas and suggestions on how to do that!

I’ve been flipping through my agile books looking for discussions about teams and safety. Many of the general books such as Succeeding with Agile by Mike Cohn and Agile Software Development: The Cooperative Game by Alistair Cockburn have sections on teams that contain very good information. But not a word about safety, at least by that word, “safety”. Maybe I don’t have the right books.

Somewhat confused by how important it is, and how little I can find, I’ve decided to explore the topic based on the suggestions from the participants at the AYE session. One question I forgot to ask was “What does safety mean?”

The Wheelbarrow Test

The dictionary definition for safety (noun): the condition of being protected from or unlikely to cause danger, risk, or injury

Since I can’t put a pound of safety in a wheelbarrow, this definition needs work to reduce the level of abstraction to something that can be measured. Most software development workplaces don’t involve danger or injury but we encounter risk, the possibility that something unpleasant or unwelcome will happen. For example:

Long ago my manager and I decided it was time to de-fragment the RA81 on the production Vax 11/750. At that time, the process involved making a tape back up, reformatting the disk, and restoring from the tape back up. The operators had the tape backups, so I just needed to wait until production completed for the day, reformat the drive, initialize the drive, and let the operator restore from tape. Things went to plan, until the operator told me, “Don, we don’t have a restore option available to us. Suddenly, I realized the risk involved.

More recently a team I worked with needed to restructure a class that most of the application used. This required studying how the other 5 teams had used the class, refactoring the class and then testing the result to verify the application worked as expected. Certainty didn’t exist it could be done, or we should be the team to do the work, but if we didn’t deal with the risk now, it was going to grow and become more difficult to deal with in the future.

Safety – Take two

How about: Safety means people can take risks and their coworkers/management will support them, especially if setbacks occur.

The above examples had happy endings. Other than me losing a lot of sleep that night, the disk was restored and functional when production started the next morning. The team successfully refactored the classes and met their sprint goal. Not all risks have happy endings, and that’s when we need support.

Extending the thought that we can take risks means we can express our opinions. Esther Derby talks about this in Workplace Safety (and We’re Not Talking OSHA). There she defines safety “as the ability to speak your truth without fear of ridicule, rejection, or retribution.”

Combining the two we arrive at: Safety means people can take risks and speak their truth without fear of ridicule, rejection, or retribution.

Safety doesn’t automatically happen. It requires support, practice, and patience. Having a common definition for safety with examples provides a starting point.

What does safety mean where you work? Leave a comment …