Thinking is hard. And worrying about Risk constantly would be exhausting.
Life is too short to go around considering Risk Management over everything you do.
Luckily, our brains do it for us automatically and subconsiously: Sometimes a voice inside will cry out Wait! before we walk out into a road or try to pick up a hot teapot.
Habit and Experience
These subconsious reactions are borne of two things: habit (we drill our children from an early age in crossing the road to embed road safety) and experience (after picking up lots of too-hot kitchenware, you don’t do it again).
In this section (on Methodology), we’re going to focus on how habit can help us short-cut the Risk Management process, whilst in the next we’ll look at experience.
When it sticks, a methodology embeds a set of practices in a team to such an extent that they become habit: the team following the methodology from feature to feature or release to release without question.
A Pattern Language
It stands to reason that if all software is about risk management, then we can examine methodologies themselves in terms of how their practices mitigate risk, and change the balance of risk on projects.
With that in mind, we are going to examine several methodologies, and break them down into their key practices. For each practice, we will look at which Attendant Risks it mitigates, and what Attendant Risks it incurs.
Show similarity between pattern and practice
80 - 20 rule
Doing work up front, thinking ahead - see my evernote article
image in email
- always consider what risks there are
- try and mitigate the biggest risks first for the least effort (ie..e value)
Turning one risk into another.
e.g. planning mitigates one thing , gives you something else.
Sign offs mitigate communication risk - back to protocols and interpretation again.
risks beget other risks
So Methodology exists as a way
ceremony practices bureacratic overhead
a point of religion.
The questions we want to ask in this section are as follows:
-How do frameworks change the risk landscape?
What are the risks in choosing a framework?
How does choosing a framework (at all) modify our risk landscape?
How should we choose a framework, then?
Evolution of software
There are more methodologies than stars in the sky, and it’s not useful to look at all of them. Instead, we’re going to pick a few archetypes and leave it at that.
So, let’s start at the beginning then, with Waterfall.
It’s the same steps, but it’s Sizing those steps:
Agile is per-feature delivery, Waterfall is a bunch of features.
But, a lot of the practices end up being the same.
Part 4: Methodologies
A more in-depth look at software methodologies and how their chosen practices reflect their position on what the most critical risks are.
Add Your Star On GitHub to receive an invite to the GitHub Risk-First team.