Undoubtedly project management is a discipline that requires many projections, forecasts, analysis, assumptions and other elements that help us formulating our plans. Nowadays, agile project management has been growing popular among the project managers and organizations. Methodologies such as SCRUM and Extreme programming are positioned as means of delivering value to organizations.
The second principle of the agile manifest states: «Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. » (Agile Alliance, 2001)
This approach has been working out good, however some questions are starting to arise: Why do I need so many plans? Why risk projections are needed? Is an explicit risk management methodology in agile projects really necessary?
These questions are due to a misconception in which we feel that planning occurs only in the initial stages of the project and that we should adhere to this rigid way that cannot be changed. After all traditional project management provides us with a formal and structured integrated change control process, acceptance criteria and quality tools to minimize changes and to get it right the first time.
Risk management allows us to increase the probability of positive events and reduce the probability of negative events, of course at the light of the misconception I just mentioned, it’s easy to think that the traditional project management approach requires the PM to be a perfect seer who is aware of everything that can happen and has a plan for every situation before it happens from day one.
The truth of the matter is that risk management is like a child and the project manager must deal with it, take care of and develop it. In other words, the administrator should not let it die, risks are not isolated or strange to agile methodologies, each of the processes that the PMBoK presents are iterative.
I think this is an interesting topic to debate, as the agile processes are also iterative and risk management can be part of the life cycle of a project, there are daily follow-up meetings, planning meetings for each iteration, planning meetings for each delivery and meetings for review and feedback in which we can perfectly identify, analyze and even plan a response for the risks, after all, cycles are short and they must have constant revisions. Again, up to what point is an explicit risk management methodology in agile projects really necessary?
The risk could be used as a factor for prioritizing stories, in fact, risks could become themselves into stories without using a formal risk register, in the first case the main person to manage the risk would be the leader of the project and in the latter it would be the product owner.
So far everything is going well, however agile methodologies, because of their nature require the team to be focus only in the project work, which means that the risks related to changes in scope, new requirements, communication and performance project team members, can be perfectly managed with this approach. But what happens with the risks that are external to the team (not necessarily to the project)?, the gaps between the technical language and functional, interfaces between projects and dependencies of outsourced teams, the availability of resources such as hardware, software, machinery, rentals, tools; funding needs, competing interests and goals of stakeholders and so on.
In my opinion the project team should not be isolated from these topics since a successful risk management approach requires all parties to be actively involved in the iterative processes during the project life cycle, including: persons of the operation, senior management, the project team, suppliers, and all the persons who are going to be affected either in a positive or negative way by the project.
In conclusion, although agile methodologies have tools that allow a good risk management approach, there are elements that are out of the scope, so an explicit and formal risk management methodology is required for any project in which we are working, either a traditional or agile approach. Moreover, the iterative nature of the processes within the area of knowledge of risk management, allows the risks management process to be adapted in agile projects without going against the principles inherent in the methodology.
Bibliographic References:
Agile Alliance (2001). Manifiesto ágil. Recovered from http://www.agilemanifesto.org/principles.html
Project Management Institute. (2013). Project Management Body of Knowledge (5th ed).
By Jorge Trejos Gutiérrez, MAP, PMP, PMI-RMP, CSM, SPOC, ITIL, COBIT.
Professor of the 
Risk Management course in the Master in Project Management Program at the University for International Cooperation.
Deja tu comentario