Proactively addressing risks is one of the major strengths of Agile methods. Not only do Agile teams have “spikes” to try to eliminate technical risks, but effective Agile teams have a mindset of eliminating a wide array of risks.  Here are some examples of ways risk is proactively addressed in Agile environments:

If a technology approach is of concern, we do a design spike and find out quickly if the approach isn’t feasible.

In Scrum, the retrospective is an explicit opportunity to look for ways to continue to improve, not resting with “we’re good enough”.

The “test first” approach is a proactive approach to quality.*

If the budget gets cut, we have working software created, not merely the requirements document, design document, and a pile of untested code.

The description of “Be Proactive” in the 7 Habits is “Proactive people take responsibility for their own lives. They determine the agendas they will follow and choose how to respond to what happens to them.” I don’t think I’ve seen an Agile book put it more succinctly. This excerpt could easily be rewritten for Agile teams: “Proactive [agile teams] take responsibility for their own [work]. They determine the agendas they will follow and choose how to respond to what happens to them.”

The Agile Manifesto’s 12 Principles has three in particular that stand out to me as having proactive risk mitigation components to them. These three are:

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

So, what do you do if you are on a team that has not embraced their responsibility to be proactive? Here are a couple of suggestions:

Consider whether or not your team has the trust necessary to be comfortable identifying risks. I suggest reading the book “Overcoming the Five Dysfunctions of a Team: A Field Guide for Leaders, Managers, and Facilitators (J-B Lencioni Series)“. This book is a follow-up to the book “The Five Dysfunctions of a Team”. The “Overcoming….” book offers specific activities  and suggestions that help address the dysfunctions identified in the earlier book.

Is the team able to communicate in a high bandwidth mode? If risks are getting lost in low-bandwidth communication, consider moving to a collocated room. Eric Landes authored a DevX article entitled “Team Rooms Breed Highly Productive Agile Software Development Teams“.  FYI: You will have to register to read the article.

Model proactive behavior. One of the best ways to show that something is important is to do it yourself.

 Encourage your teams to be more proactive about their work, and I believe you will find that good things follow.

*See the “Being Proactive – Getting to the Triangle of Happiness” blog about testing as it relates to happiness on a blog by Daniel Wintschel and humandoing software.