Addressing risks in agile projects

A few mechanisms in agile projects help us reduce risk. For example sprint reviews of spring results allow us to make adjustments when solutions do not meet the user’s expectations or if the project’s parameters have changed. Quantative metrics like the burn up charts even help during sprints to identify problems. But are these options enough for effective risk management or do you perhaps need a systematic approach for identifying and minimizing risks?
As a project manager you take on the task of carrying out initial risk appraisals for the project. A risk is a potential problem that one should take preventative action against. Anything that could negatively affect the project in terms of costs, time and quality of solution poses a potential risk and consequently endangers the entire project’s success. To be clear: we are talking about the project risks, not business risks which the company faces if it fails. The first step to identify the risks. Then you need to evaluate them and decide how you are going to protect yourself against them.

risks even in agile projects

Risks, even in agile projects

Where could risks be looming? If you cannot see the risks your project faces immediately then you need a systematic method for identifying them. We would recommend the following:

Identifying Risks

Begin, very broadly initially, by investigating the potential sources of risks. Then figure out what kind of risks could come out of the risks sources you have found. That sounds easy, but how does one find the risk sources? You could use a risk table to do so. It can help you to get clarity on the kinds of risks that are relevant to your project. The table discerns four potential types of risks:

  • System-/product risks. These refer to the software under development. They mainly arise due to complexity.
  • User related risks. These are technical considerations, they pertain to the circumstances in the user areas.
  • Technology related  risks. These are connected to the hardware, system, software, network or communication technology etc. The more unfamiliar or untested they are, the higher the risk.
  • Team related risks. These can spring from the combination and interactions among the team members.

List possible risks sources for each risk type in the table. Tick off the property per risk source that applies to your project. You will then be able to see immediately if a low, medium or high risk is present. For your overview you will find four tables for the four potential risk types. A table for system-/product risks might look like this:

Total System/Product simple average complex
Functionality simple average complex
Procedures simple average complex
Data structure simple average complex
Income / expense simple average complex
Interface with other systems/products simple average complex
New/adjusted business processes zero several many
Qualitative goals normal high very high

The table for the domain related risks contain the following risk sources:

Technical tasks simple average complex
Significant features/epics known and quite stable partly known unclear
Users’ future IT- expereience large average null
Support by management large normal low
Degree of technical innovation low average high

Of course there are technology related risks too:

Technology (hardware, network, system- and software, libraries and frameworks etc.) simple average complex
Goal environment known and tested partly unknown still unclear
Development environment known and tested partly unknown still unclear
Degree of technical innovation low average high

And risks related to your team:

Team size 1 – 5 6 – 10 more than 10
Project duration 1-3 months 4-6 months longer than 6 months
Team’s experience with technology large average null
Team’s development experience large average zero
Team’s knowledge about users deep average null
Client involvement full-time part-time sporadic
External or only partly engaged team members zero several many
Conflict in potential in the team low normal high
Working environment and technical infrastructure very good satisfactory poor

This project risk is just the beginning. You should definitely expand on them, ideally together with your requirements engineer.

Identifying and evaluating risk

Requirements engineering is useful for creating value for your stakeholders in your project development. What are your stakeholders’ goals? What requirements can you derive from that information? Which relationships exist between individual requirements and various technical components? This knowledge about relationships is important for identifying and evaluating risks. Requirements engineers can help a lot in identifying system-/product risks by continually entering into discusions with stakeholders about features and epics, and asking questions like: What main risks do you foresee this feature facing for this project? The result can be recorded separately, for example in the feature’s forms or Epics if you use tools in your requirement engineering.

Evaluating the risks for a feature

Evaluating a risk

Of course the requirements engineer can formulate a risk evaluation immediately, making suggestions for defensive action.

Focus on the top risks

After your risks have been identified keep the following in mind: not every potential risk is an actual risk. And not every risk is equally threatening. Analyze and evaluate the cited risks. We recommend giving up on trying to address every single risk. Trying to respond to every single risk is the reason why risk management ends up not taking place at all in stressful periods in the project. Costs and benefits should be reasonably balanced within the risk management framework. Develop a top ten list of risks. Define the ten most important project risks. Bear in mind that it is a rough estimate. Of course the real number could be eight, eleven or 14. But not 50 or 200. Concentrate on monitoring the most important risks and defining defensive action. Decide exactly how you would deal with every one of the top risks. You have the following basic alternatives:

  • You can try to avoid the risk or to reduce the probability of them materialising.
  • You can try to reduce their potential damage.
  • You can try to combine risk avoidance and risk reduction.
  • Or you can accept the risk and forsake the planning of measures. If the risks materialize, then you can determine your approach from then on based on the current project situation.

So how should you determine the top risks and the defensive action? Make them visible for all the interested parties in the form of a risk board.

Risk board as communication method

Risk board as communication method

These estimates will not remain constant. Risks will be added and subtracted as time goes on. Once the team has begun with the development work and the requirements engineer has started adding more features to user stories everyone has more responsibility for developing a solution and maintaining a functioning risk management system. The risk board is a tool that is meant to benefit everyone in the team. What should happen if the solution cannot happen as planned? What happens when the purchased control functions differently to what the provider promised on their website? What happens when the most important knowledge source for a specific area in the team is no longer available etc.? Technological and personal risks must be ascertained within the team, evaluations must be planned and carried out. That could happen using sprint planning, for example.

What makes a successful Project Management process? How do I find the right business process? Which methods are useful? Ursula Meseberg is a graduate mathematician and co-founder of microTOOL. She is fascinated with current trends and has made a name for herself as an author of professional articles.

EN Subscribe to our newsletter
0 replies

This discussion is missing your voice.

Leave a Reply

Your email address will not be published.