Encourage your Scrum team to take more risks

I was reading a blog post from Mike Cohn where he made a point of the dangers for an organization (Scrum team?) failing due to the ability to not take more risks.

I completely agree and offer a tool – a slide really – to help teams take more risks.

Risk adverse Scrum teams

In my experience, software development teams tend to consist of people who really want to get it right… preferably the first time.

I see this firstly when they want to have all the possible scenarios or paths covered in the Story. The level of detail gets to be overwhelming even if they attempt to split/slice the Story (which is another practice I encourage).

And once the Sprint starts, adversity to risk appears in the form of over engineering and gold-plating which I believe is due to a few traits:

Pride: “I want to make sure it’s the absolute best code I can deliver because my name is on it”
Fear: “I don’t want the others to criticize my work”
Trust: “I’m afraid the others will…”
… and likely others

The result is over burdensome discussions, slowed progress and general frustration.

Encouraging risk taking

Done well, Scrum is great at managing risk: the risk that you don’t deliver what is really required by your customers and the risk that you miss your deadlines.

To help encourage risk taking, I use the following slide:

There are several points I’m trying to make here:

Not all questions need to be answered before we take a Story into Planning or the Sprint
The Definition of Ready/Done are tools the team can use to help manage the risk and set expectations
I’ve suggested some percentages, but the team needs to agree on what their acceptable level of tolerance is
It’s OK to take risks and there is a certain level of uncertainty in what we are doing
We’re expecting to fail due to a an acceptable level of uncertainty, but we’ll do it fast and adjust.

I tend to briefly point out the different areas of the slide and then ask the team for comments or input: “What thoughts does this trigger in you?”, “Which challenges do you see if we don’t have a common understanding of this?”.

I want them all – including the Product Owner – to get the same message directly from the Scrum Master: it’s OK to not be 100% sure.

Just having this slide up and speaking out loud gets the team to start having another mindset and eventually taking more risks.

What’s needed

Trust is needed for this to work because you are likely asking people to change their behavior and to move their comfort level. There may be a organizational tradition of consequences for failing. In the extreme – careers may be affected. So keep this in mind if you decide to work with taking more risks.

Building trust is another article, but just taking this subject up during a Sprint Review or Retrospective, can get the ball rolling. Reminding people that it’s OK when a risk was taken and it bites back (risk is realized). Reassuring when you can see people struggling to take the leap (“Is this Story really Ready?”).

I also think it’s valuable to consider the impact of taking a risk. Often times, people don’t take risks because they can’t imagine or fully comprehend the impact if the risk is realized. By addressing this head on – “What is the impact of taking this Story in you don’t believe is Ready?” – you help them put words to their concerns and feel comfortable taking that step into the unknown.

Note: If you’re a Project Manager, I’m not suggesting to replace your existing risk management process – something I consider more strategic or long seeing. This is for the individual Scrum team members to work with.

Your experience?

So what do you think? Do you struggle with taking risks on your team? I’d be interested in hearing how you help encourage risk taking, if at all. Maybe you don’t think a team should take risks?

Whatever you think, I’d be interested hearing from you.