Years ago I used a slide in my training class that said, “For an organization to be successful with Scrum, it needs to have a safe environment.”
I remember in one class, a few guys at the back of the room start laughing when I showed that slide. When I asked why, they said, “You can’t assume safety here! We do a layoff about once a month. There is no assumed safety or trust in our environment. Nobody shares information with one another. If I have the info and you don’t, then I will likely survive the next layoff and you won’t!”
As you might imagine, I was pretty worried about this organization’s ability to be successful with Scrum. And I was right. They had a difficult time reaching any reasonable level of agility; I attribute a good part of their difficulty to a lack of safety.
Agility Requires Safety
Safety is rarely or ever mentioned when discussing agile. It is not one of the official core values or a topic of many training courses; yet to me it is absolutely essential!
If an environment is unsafe, then people won’t speak or act on what they truly believe. In other words, they won’t be very transparent. And, transparency is the third leg on the stool that supports an empirical process (the other two being inspection and adaptation). So in an environment that isn’t safe, people won’t be very transparent, and the legs on which agile rests will be cut out from underneath them.
What do I mean by an unsafe environment? Here are some examples.
Agile Teams Feel Unsafe When… They Can’t Say No
If a manager comes over and tries to pull you out of your sprint to work on his or her pet project, and you feel compelled to say “yes” even though you know it is the wrong thing to do, then your environment isn’t safe.
If it were safe, then you would feel totally comfortable saying something like, “Hey that sounds really important! But, my time is committed to the current sprint where I am collaborating with my teammates to get done what we said we could at the last sprint planning meeting. If I pull off to work on what you’re asking for, I will put at risk our entire team’s ability to accomplish our sprint goal. Please route that request back through the product owner so that the necessary work can be prioritized and sequenced into a future sprint.” In an unsafe environment, this response could be a career-limiting move!
Agile Teams Feel Unsafe When… They Must Hide the Truth
Another example. If your CIO wants to attend your sprint retrospective meeting and the thought of him or her hearing what actually is going on during your sprint terrifies you, then your environment isn’t safe. Meaning, if the CIO’s mere presence in the room (even as fly on the wall) would substantially change the retrospective discussion, then you have a safety problem, and you should address that immediately.
A related safety problem probably exists if the development team members and the ScrumMaster don’t want the product owner at the retrospective. I know that some people don’t believe the product owner should attend the sprint retrospective. I am not one of them; I think the product owner should be there. Frequently when we explore for the root cause of why people don’t want the product owner to attend, it is because the team members want to complain about the product owner and they don’t feel it is safe to complain about the product owner with the product owner in the room!
Agile Teams Feel Unsafe When… Teammates Compete
If your organization sets up a measurement system that makes people on the same team inherently competitive with one another, then you have a safety problem. Stacked ranking is a good example of a collaboration-squashing system. In such an environment it is just not safe to work with other people since it is important that you look good and the other person does not, or at least that you look better! In such environments is it not safe to have a conversation in which the other person might come away better off than you!
Agile Teams Feel Unsafe When… Customers Are Off Limits
If your organization doesn’t feel it’s OK to engage customers (internal or external) in a transparent way, then you have a safety problem. Customers don’t like to be surprised. Let’s face it; in product development customer surprises are rarely good. Most of the time surprises lead to frustration and disappointment. If your organization doesn’t feel safe in keeping customers in the loop on how development is progressing so you collectively work to inspect and adapt in the presence of problems, then you will likely end up with the same surprised, frustrated, and disappointed customers that most of us have experienced at some point in our past.
Agility, Safety, & Transparency Go Hand in Hand
Companies that have a safety problem typically have a transparency problem (and vice versa). As such, they have a very difficult time being successful with agile. In any agile adoption or agile transition effort I have been associated with, one of the first things I gauge is the safety level of the environment. If people feel unsafe, I immediately bring this to the attention of senior management, since they will very likely be the ones that need to address the safety issue first.
So, how safe is your environment? Are you willing to share examples of where lack of safety is interfering with your ability to get the desired benefits from using agile?