What risk? This is agile baby!
Read many agile project manuals, guides or papers and you’ll struggle to find a meaningful section on risk management. Whilst it’s true that agile does inherently manage and mitigate a large number of the standard risks presented in a software development project, it’s a misnomer that risk management is something you can ignore.
I’ve spoken to quite a few ‘new to agile’ PM’s lately who’ve mistaken the dearth of guidance or instruction around risk management in agile to arrive at the conclusion that it’s not a major factor. Of course it is.
Unmanaged risks kill projects irrespective of framework.
In agile risk management is less brash and more subtle; but it’s of equal importance. For the ease of explanation I’ll split it into two categories – strategic risk and technical risk.
As a PM in agile I believe one of your primary duties is to create an environment in which the team can thrive, and shield that environment from Project churn and impact. Therefore accounting for and dealing with strategic risk (in conjunction with the Product Owner) is one of your primary concerns. Traditional methods of risk management work well here, and I wouldn’t suggest any departure from the norm. It’s all about getting risks identified, communicated and mitigated early.
I believe that the strategic risks should not impact the team until a requirements change is identified (if at all) and therefore the team should be unburdened with this information unless it impacts a user story/requirement or method of implementation.
Where agile really shines is the ability to identify technical risks and issues at a really early stage of the process; and if you’re following the agile maxim of failing early, often and learning from your failures, many of these items will be mitigated before they need to be escalated. However the point remains that serious technical risk should still be identified, assessed and communicated.
There is often the temptation in agile to store technical risk within the team, sometimes unknowingly. A good technical team will ‘often find a way’ and come up with a solution, and overcoming challenges is part of the natural ebb and flow of any software project. The trick is in being able to identify which items are genuine risks and which are not.
If unsure communicate all, it’s easier to discount a risk later than it is to deal with a late emergent issue. As you become more experienced you’ll be able to better identify which problems are challenges, which are risks and which are genuine issues.
The bottom line is: communicate the risks as you would with any other project framework.