Under agile, risk mitigation is a very key concept. Instead of talking about and being aware of risks, the first thing we try to do is to eliminate the risk.

When starting a project take a look at overall project risks and attack them so they are no longer a risk for your projects success. A possible example is: will WPF work as a technology for us? The first thing the team should do is create a quick prototype application to see if I can get WPF to work for our situation.

With every iteration take the time to look for risks at the outset. This might be something like: “We don’t know how to talk to system X”. For this case the first thing that should be written in the iteration is the integration with system X. If we can do it then everything is great. If not then we need to find a new approach and we still have time to do it.

If we tackle a risk and it takes 20 hours then we know we have 60 hours left in our iteration. Because all the other items we are going to do are easy (by comparison) and therefore should have fairly reasonable estimates, we can now see if we will hit our goal for the iteration or if we need to move some of the less important work items to the next story. Contrast this with doing all the easy items up front. We get almost all of our goals done for the iteration but then hit a spot that stumps us. So either our deadline gets missed or we code through the night to make the deadline, potentially writing buggy hack and slash code.

By tackling risks as our first priority we can eliminate the risk of having something bite us at the last minute. This helps with estimates, costing, and deliverables of our projects.