The nature of agile makes for a style of management that is well suited to handling risk in comparison to other styles, however this does not mean that risk management does not come with its own unique challenges that can often trip up a development team. According to Alan Moran of ISACA, many agile project managers are “seldom able to articulate the impact their work has on overall project risk or how they are contributing towards its management”.
An agile project manager should ensure that any risk management plan encompasses three separate concerns:
Recognizing threats and opportunities for each project
The ability to prioritize and enact appropriate risk management strategies
Ability to judge whether each risk is being handled appropriately
Due to the nature of agile development, an agile team should engage in a degree of risk management during every stage of the project. During the beginning stages of an agile project, a team should first look at the initial requirements and analyze the potential risks involved in undertaking the project and in delivering each of the requirements. Risks should also be identified with each user story. The larger the user story, the greater the risk the project may potentially undertake. Team members should also discuss any problems they have been facing during each meeting so that it can be incorporated into risk management strategies, while also clarifying them with any stakeholders in the project. Finally, upon reflecting on the project, team members should discuss anything they encountered so that it can be incorporated into the project’s risk management strategies.
While the risks involved in any project are numerous, agile projects can be susceptible to a number of rather common risks:
Budgetary risks: A project goes over budget due to failure to properly estimate costs towards the beginning of the project. A team ought to work to manage costs at every stage and accurately assess them
Scope creep: A project’s scope goes beyond its ability to handle them
Risks of deadlines shifting leading to client dissatisfaction.
Technical debt as a result of changes in a project mid-development. This can be managed through proper planning and high acceptance requirements for all user stories.
A change in the market resulting in a project being forced to stop work. This can be managed through constant communication with project owners and a thorough discovery phase
A potential strategy that an agile project can use to assess risk is what is known as the what-why approach. This is a brainstorming approach where team members attempt to figure out what might go wrong in a project while figuring out why such a thing might occur. This approach is particularly useful for new teams that may not be fully familiar with risk management practices. In a team driven approach such as agile, this is a massive advantage. It is important to keep in mind that during risk assessment, team members should also be open to discussing potential opportunities. Agile in particular often produces a tendency to focus purely on the negative aspects of risk, without also considering the potential of positive opportunities.
A team should also be encouraged to perform risk treatment, otherwise known as “risk tagging”. These track the areas of risk that the project has identified as well as the steps that are being taken to avoid it. The below chart, for instance, showcases a user story map modified for risk. The risk tags in question, pair programming, signify one particular risk management strategy that will be performed.
(ISACA)
Risk can also be tracked through risk censuses, risk boards, and risk burndown charts. A risk census tracks the probability of each potential risk that a project may encounter, and counts them in terms of days, allowing a team to get a solid understanding of a project’s overall risk by tracking both probability and potential impact of each risk. A risk board similarly tracks the various risks that a project may undertake in a way that can be shown to investors. Finally, a risk burndown chart can be used to track the project’s current risk factors and updated week to week. By incorporating these into the normal workflow, a team can better understand the risks facing the project and also fine tune any risk management strategies.
It is crucial that an agile project has a risk management plan in place, and that a risk management plan is adapted to the structure of agile development. After all, agile development is not the same as disorganized development. When first developing a risk management plan, a project manager should consider which tools are already in place. The diagram below showcases how a kanban board can be modified to include a risk management plan. Each step is tagged and incorporated into a separate risk tracker that allows the team to more easily understand and track the risks involved in each current task.
(Source: ISACA)
There are several steps that can be taken if a risk is identified. The first possibility is to simply avoid the risk entirely. If a user story is too risky for one reason or another, it may be wise to avoid undertaking it for the current cycle, until the risk is deemed small enough to be undertaken. This should be discussed with the project’s current stakeholders, and may not be possible if a user story is simply too important to a project’s success. An alternative strategy is mitigation, which aims to reduce the amount of risk that the cycle will face. Another possibility is to ‘transfer’ the risk, outsourcing the risky task to an outside organization that is better equipped to handle it, though this also may not be possible. Finally, a team may choose to simply accept the risk. Which strategy is best undertaken depends entirely on circumstances. An agile team should learn to use their best judgment when deciding which risks are acceptable and which are not.
References:
https://www.isaca.org/resources/isaca-journal/issues/2016/volume-2/risk-management-in-agile-projects
Comments