Having a plan mitigates risk.
Risk management is crucial to the success of all software development, enhancement and maintenance projects. Risk management at its basest level is avoiding problems that can be avoided and recognizing those that can’t be avoided. In order to recognize and avoid problems, every project must take the steps that need to be taken to consciously look outward and forward. The act of risk management requires both introspection and extrospection. Extrospection, a rarely used word in the everyday conversation, is even rarer in many Agile approaches. One important way to assess risk is to consider whether there are internal or external risks.
Internal risks are from within the organization and arise during normal operation. Internal risks are often forecastable, and therefore can be avoided or mitigated. Internal risks are typically generated by one (or some combination) of human, technical or physical factors. Many Agile practices naturally address internal risk. Practices like short planning cycles, retrospectives, flexible backlogs, and small teams are geared to addressing the delivering short-term value by addressing the risks that that team perceives to be controllable.
External risks come from outside the organization or project and outside of the team’s control. External risks tend to only be forecastable in retrospect, and therefore efforts need to be focused on recognition and reaction. Many external risks stem from legislative, environmental and political changes. The impact of a major earthquake on an organization’s supply is an external risk.
Recently, Steven Adams published an article on his blog titled, Seven Risks in Software Development. In his article, Steven the following seven risks:
- Risk of delivering little or no value to the customer or organization.
- Risk of missing the delivery schedule because of poor predictions.
- Risk of unplanned work disrupting the work process and schedule.
- Risk of poor quality in the delivery.
- Risk of work item becoming an outlier … way off!
- Risk of the team not working well together.
- Risk of end-users not using or liking the product.
Steven’s list is a powerful tool for facilitating a discussion of risks that are controllable at a team level. Steven’s are all internal risks. A lean approach practiced by many teams to identify and manage internal risks (mostly) includes:
- Identify knowable risks.
- Build mitigation for common risks into the definition of done.
- Generate stories for less common risks and add them to the project backlog.
- Review risks when grooming stories.
- Carve out time during planning to identify emerging risks.
Agile techniques at a team level are designed to capture and manage internal risks. No one believes in not managing risk because not managing risk puts the value a team delivers at risk or at the very least puts their weekend when a risk becomes an issue and had to be dealt with. Agile techniques tend to give teams a short-term inside the boundary perspective that is very delivery. External risks often lurk outside the short-term focus, which means our techniques need to be tailored to address both internal and external risks.
Next: Incorporating External Risks into an Agile Risk Approach
Software Process and Measurement 
September 14, 2016 at 2:44 pm
Thank you for the call-out on my recent blog (7 risks in software development)!
And, oh yes, those external risks! Duncan J. Watts book “Everything is Obvious(*) (*)Once You Know the Answer” certainly supports your statement “External risks tend to only be forecastable in retrospect”.
September 14, 2016 at 6:17 pm
An important step that I think often gets overlooked is the act of defining a risk tolerance.
While many teams (or organizations) may have an intuitive sense of their risk tolerance, I think it’s helpful to have an explicit, conscious discussion about risk tolerance.
By defining what the organization’s risk tolerance is, a more productive conversation can be had about which risks are out there, what their magnitude (i.e. how bad will it be if this risk actually hits us?) and what their likelihood is, the organization can make better decisions about mitigation strategies.
For example, it probably makes sense to mitigate the high-probability-high-impact events (Jerry is 73; he said he’s retiring soon – we should develop a plan for orderly succession), and it may be better to implement mitigation strategies for the high-probability-low-impact events (e.g. Jerry could get sick and we could get set back by a week on his portion of the project) than to worry too much about the low-probability-high-impact events (civil unrest leads to chaos in the streets and a total shutdown of the office for 3 weeks).
Just a handful of thoughts from a project manager outside of the software game who’s perhaps a little too used to telling other folks how better to do their jobs 😉
September 15, 2016 at 11:40 am
Excellent thoughts and ideas. I agree that risk tolerance should be defined. Are there criteria that you would suggest using to assess risk tolerance? I assume tolerance would vary based on context?
September 16, 2016 at 1:09 am
I think risk tolerance is very context-specific.
It depends in part on the organization – its size, culture, mission, etc. – in part on the project and its specific nature, and in part on the nature of the risk itself.
For example, a small start-up likely has more tolerance for risk than a large, well-established company due to the culture of the organizations. Start-ups are inherently risky, and founders unwilling to take big leaps of faith probably have no business starting a company. Although likely not universally true, I would bet that private sector organized are less risk averse than government agencies.
In the area of project-specific risk tolerance: If the project is an update to a well-established and successful piece of commercial software, then you’re likely going to be a little more risk-averse – you don’t want to muck up the confidence of your loyal customers and lose their business. If your project is is to develop the new drug that’s even better than statins, you might have greater tolerance for risk (you’ve got a big pharma R&D budget backing you up, the reward is potentially enormous, etc.)
Finally, there’s the risk itself. Railroads have a huge problem with pedestrians trespassing on their tracks, but have essentially decided that it’s a risk they have to live with (despite the hundreds that die annually), because effective mitigation is prohibitively expensive. On the other hand, the risks associated with staff turnover are much lower, reasonably predictable, and easy to mitigate – so your tolerance for those risks is likely low.
Just shooting from the hip here, but hopefully that all sounds reasonable?
September 16, 2016 at 10:31 am
I like Slowerbolts ideas on risk tolerance which fit my observations that every firm, project, and person has a different risk tolerance. Context is powerful however, there probably are a few common themes that can be used to direct a conversation about risk tolerance.
September 15, 2016 at 11:56 pm
[…] to be explicitly discussed and the horizon needs to be constantly scanned! Current Risk Thread: External and Internal Risks Incorporating the Idea of External Risk into Agile Efforts (Current) Risk Tolerance Future Telling […]
September 22, 2016 at 11:56 pm
[…] Internal and External Risks […]