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

What Is It

Prioritisation is a key process in trying to focus on building useful stuff first. It could look like:

Prioritisation relies on not delivering all the functionality in one go. But it tends to be a spectrum:

Usually, risk is mitigated by Prioritisation. But sometimes, it’s not appropriate: When Finland changed from driving on the right side of the road to the left, (in order to be in line with the rest of Europe) the changeover had to be Big Bang and the whole country changed overnight.

How It Works

There are several ways you can prioritise work:

By prioritising, you get to Meet Reality sooner and more frequently and in small chunks.

Feedback Loops & Risks Mitigated

Review

This one way in which a particular prioritisation Meets Reality

Production Risk

Breaking a large delivery down into lots of small releases has an impact on Production Risk:

Schedule Risk

If you’re able to do Continuous Delivery, and have de-risked the release process, then you can eliminate some Schedule Risk, because you’ll know you can hit any date with something. The risks of what you deliver on that date are then Feature Risk rather than Schedule Risk.

Attendant Risks

Dependency Risk

The biggest risk to phased delivery is that you try and build functionality now that actually relies on things scheduled to be built later.

Schedule Risk

Sometimes, releases have a cost associated with them in terms of time and bureaucracy to perform them. Obviously, then, the more releases you’ll do, the less time you’ll spend doing other stuff, like building functionality. The trick to doing frequent releases is therefore to ensure they are low cost, and this means automation. But, building automation adds schedule risk too.

Complexity Risk

If you are replacing an old system with a new one, incrementally replacing functionality is a good way to go when the system is complex. However, this means that you’re going to have two systems running at the same time, which is inevitably more complex than just one system.

PLanning

Discuss the tool Duncan and I used to determine whether a release date was feasible.

https://en.wikipedia.org/wiki/Planning_fallacy

– estimating: holding the risks in your hand and saying, which is heavier?

Risk-First planning: break down the goal into the biggest risks3

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