In this previous blog the concept of risk as an area was introduced. The area is the product of ‘severity of undesired effects over time’. The reason I choose to call it ‘risk’ is because the software I’ve seen so far contains more or less undesired effects and there is always a probability that these can cause harm rather than good. The reason it is an area is because it is made up of two dimensions: the severity and the duration of the exposure of these effects.

When a new version of software is released, what its creators usually refers to as ‘deploying’, the creators deliberately expose the system to its users, that is take a risk, and hope that the desired effects outshines the undesired. Hopefully they’re well aware of the fact that the system contains parts that can cause trouble and the release should be preceded by a conversation about this.

Impact management

These pre release conversations are often an attempt at reasoning your way to precautions that reduce the undesired effects from the left. My experience is that we spend far to much time reasoning and far too little time in attacking the area from the right flank. There are also efforts that focuses on ‘amplitude’ and before we go any further I’d like to clarify a bit. Do remember that this is a model, not reality itself.

From the left

Let’s start with activities that tries to reduce the area from the left. Here are some examples: 

  • Release planning
  • Documentation
  • Education

The common ground here is that these activities try to reduce the effects before the release, or rather delay it. I.e attacking from the left.

From above

Another approach is to reduce the amplitude, or what I call ‘severity’. There are several ways of doing this. Here are some examples:

  • xDD, all kinds of x-driven development (BDD, TDD, ATDD and such)
  • All kinds of testing
  • Usability studies/tests

The above activities share the characteristic that they focus on delivering the right stuff and making sure it performs as expected. You can argue that these fits equally good in the next category, but I like to keep them separate.

From below

The line between attacking from the top and the bottom is a very fine one, but I like to keep them apart because it is easier to reason them that way. I put ‘whens’ and ‘whats’ in the latter category and ‘hows’ in the ‘from above’ category.

In the ‘Attacking from below’, I normally place the following:

  • Limiting the number of features released, that is managing scope
  • Raising the bar of what’s acceptable, mentally and maybe even ‘data wise’
  • Removing or limiting existing functionality

Attacking from the right

It’s only recently I’ve seen some serious attempts at attacking the ‘risk area’ from the right. Automatic updates or the possibility to ‘push’ fixes to the end users was a start but my favorite attempts has been made possible mainly because of the introduction of cloud based services. They have made things like fast rollbacks a whole lot easier with virtual servers etc. If you take a look at the stuff I place in this category, I think you’ll agree:

  • A/B testing
  • API versioning
  • Fast deployments/rollbacks

These are not new ideas by any means and they’ve been around for at least as long as I can remember. What I see though is the possibility of shifting the focusing. We can step away from the huge emphasis on getting things right the first time to, getting things right eventually and not breaking stuff in between. We can go from not making mistakes to, making mistakes in a safe way. I am pretty sure that in some areas getting it right the first time is highly desired but I’m equally convinced that in most cases there would be a lot more room for mistakes if there was a fast way of fixing them.

Attacking from all flanks

In short I’m advocating that you look at your own situation and see how much time you spend on each flank, not just the height or the width. If the area is bigger than desired, one dimension is probably neglected. My advice then is to start by looking at what can be done to reduce the area from the right, because there’s a lot to gain from that.

Start from the right

Quick recovery is a precursor to safe experiments and safe experiments is the fastest way to quicker learning. When we realize this, the natural starting point of our efforts becomes reducing the time a system behaves in an unwanted way. This can be done by employing any of the techniques mentioned above but seriously effective ways start by attacking from the right.

If undesired effects can be rolled back quickly, safe experiments are possible. These safe experiments can be used to make the environment even safer or getting feedback even faster. Faster feedback, more information, even more feedback and more information. This is a good example of a self reinforcing loop of the good kind, a positive spiral. And that is why it is a good idea to start working from the right. Safe experiments everyone …


About Ola Ellnestam

Agile Coach, Systems developer, Agile Practitioner and father of three.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s