Fork me on GitHub
Risk First Logo

Home of Risk-First Software Development



Start Here


Home
Contributing
Quick Summary
A Simple Scenario
The Risk Landscape

Discuss


Please star this project in GitHub to be invited to join the Risk First Organisation.

Blog


Consuming Hacker News 14 May 2019
Twitter Cards 22 March 2019
Next - Scrum? 7 March 2019
Available On Amazon 25 February 2019
New Proof 10 February 2019

Publications



Click Here For Details


Under Construction

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

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

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.

Found this interesting? Please add your star on GitHub to be invited to join the Risk-First GitHub group.