Measuring and defining risk with Cynefin

Measuring and defining risk with Cynefin

A common way of describing risk is using a likelihood vs impact metric. For example, there is a very low likelihood of an asteroid big enough to wipe out the earth actually doing so, however, the impact would be very high.

Many tools give you a lot of granularity when describing risk, one tool I used recently, called Kivue (which is a crock of shit), used integers. Likelihood = [1,2,3,4,5] (what is a likelihood 4, how is it different to a 3?). We used actual words and threw away two of the integers to make it more useful:


  • 1 – Unlikely,
  • 3 – Likely,
  • 5 – Definite

There were also integers for the impact, so we used actual descriptions for those instead:

  • 0 – No impact (why would this be important?)
  • 1 – Low Impact
  • 3 – Medium Impact
  • 5 – High Impact

Once you have your likelihood and impact, you can then work out your exposure:

Likelihood x Impact = Exposure

If you then rank your risks by exposure, with the highest at the top, this will give you a good idea of the risks you should be looking at first. However, having this still didn’t give us a real handle on how to assign a likelihood or impact to risk – one persons 3 might be a slightly more anxious and pessimistic persons 5!

I’d recently been reading (again, it seems to leak out of my head whenever I read about it) about Cynefin and it occurred to me that you can use it define risks. If you’re not sure what Cynefine is, this post may not be useful to you – you should start here and then here.  Basically, Cynefine is a decision making framework, where the problem spaces are known, unknown, complex and complicated. There’s a lot more two it than my pithy one-liner and I’d encourage you to take a look at the work of Liz Keogh to find out more.

Anyway, once you’ve up to speed…

Defining Risk


This risk is so obvious it might not even be a risk. We know the inputs and the outputs, it’s not complicated (as in, there are few moving parts and no dependencies) and it has two or fewer steps to complete the mitigation.

Impact: 1,3
Likelihood: 0, 1


  • Someone is on holiday. Someone else covers.
  • Hardware is needed. Hardware is bought.


This risk has more than two steps, but those steps are well known. The inputs and outputs are also well known. There may also be dependencies, these are also well now.

Impact: 0, 1, 3
Likelihood: Any


  • A team member doesn’t know how to use a technology. They need training from a peer.
  • Availability of a resource is unknowable. Seek alternate resource.


Multiple steps, multiple inputs and outputs, multiple dependencies. Some or all of which may be unknow. Work is required to move this kind of risk to “Complicated”. Although, this may not always be the case if we choose not to mitigate this risk, or there are simply too many unknowns.

Impact: 3,5
Likelihood: Any


  • A choice of technology is unconfirmed, work needs to happen to confirm the choice is appropriate.
  • Industry-wide definition of product format is changed.


Unknown steps, inputs and dependencies. More of a gut feel used as an early warning system. Chaotic risks should probably never be added to Kivue, although they could be added to a separate RAI register. A chaotic risk should be worked on until it can be move to complex or complicated.


  • Competitor is releasing a new, secret product.
  • Annual C-Level board meeting in which the entire company strategy is usually changed.

Impact: Any
Likelihood: Any


This worked for us and might work for you to. If not, then I’d implore you to come up with a common way of describing risk, it makes it easier to assess the relative “riskiness” of each risk and understand better where you should apply your mitigation efforts.

You may have other ideas on how to describe your risk impact and likelihood, and, if so, please comment below!

Butterfly Board

Butterfly Board

I was sent a product to review recently. This is the first time it has happened and I was delighted to oblige, as well, who doesn’t like free stuff? More importantly, it’s COOL free stuff.

The butterfly board is a whiteboard from the future. Now, you’ve probably either used, seen, heard of, or otherwise understand what a whiteboard is. If not, the internet is probably not a place you visit often. Either way, I’m not going to talk much about the whiteboard properties of a butterfly board as, well, they’re pretty self explanatory. But, if not, here is a picture of its whiteboard-y-ness.

This is not me, but it could be. It could also be you.

Whats this? A small, table-top whiteboard? What is this nonsense?

Oh, it’s more than that, it’s a portable whiteboard. WITH HINGES. MAGNETIC HINGES. Why has no-one thought of this before? You can make a whiteboard book, or simply make your whiteboard larger as it all snaps together. Did I mention the magnetic hinges?

Scalable (Snap Binding).jpg
Stick them together, make it massive. Have pretty nails.

Of course, the benefit of magnets is they not only stick to each other, they also stick to metal things, so you can smack the pages of your ButterflyBoard on a wall (or, another whiteboard, how meta). See:

Use case- brainstorming.jpg

This is so cool. Apart from the obviously fake marketing shot. “SCALABLE SUPER”

The pen is also pretty cool. It’s got an eraser on one end (which I never use, I just use the edge of my hand, then wipe my hand on my trousers like a five year old). It’s super thin, so you can make pretty pictures of butterflies.

You could also do other things with a thin pen.

Of course, you can use a regular sized whiteboard marker on it too. It writes just like a regular whiteboard, and smudges like one too. So, it’s handy that you can fold it up, one board of the ButterflyBoard can cover another, meaning that your beautiful butterfly picture won’t get ruined with it in your bag.

Talking of bags, it also comes in one. Which is good, as you don’t want to get marker all over the inside of your actual bag.

It’s sized just right – it’s like a large note book in terms of size, so plenty of writing space and not so big that it doesn’t fit in your bag or under your arm. It’s also light, but reasonably stiff, so you can write on it while it’s on your lap (just don’t get marker on your white trousers grandad).

If I hadn’t already been sent one, I would definitely have bought one, they fit nicely in your bag and so make a useful doodle/scratch pad and what self-respecting agile coach wouldn’t want a whiteboard with them at all times?

If you want to read more, watch videos or get yourself one, there’s an indiegogo thing running here:

Digital Detox

I read Documentally’s news blog post with a twinge of jealousy today: Rebalancing my relationship with technology. I’d read about the Punkt phone in his newsletter (which you should subscribe to, it’s very good) and my mouse pointer hovered over the buy button the Punkt website…

I would love to do this, but some things stop me. £230 is a lot for a ‘dumb’ phone, when the OnePlus 3 (which I own) is £329 and the OnePlus 2 is £239, sure I could use an old Nokia like Christian suggests, but where’s the fun in that? New tech drives me to try new things. But this is new tech driving me to do … nothing. Well, it’s not really “nothing” it’s just something else. Look at trees, skies, plants, be engaged in the moment. Be engaged in the people around me. Be engaged.

Mostly all of my communications during the day are text based. The only people I actually speak to on my phone are my mum and, occasionally, my wife (I don’t mean I only occasionally speak to my wife, just that we WhatsApp mostly and the odd call for clarity or high bandwidth). Most communication is fairly brief “Check this out: [youtubeurl]”, “See you later”, “Can you forward me the thing we spoke about?”.

Some of it is international – I work with a team in India, there’s a lot of text-based comms (email, slack) but also a daily chat.

So, without buying a Punkt (or resorting to an old Nokia) can I digital detox? Can I commit to only using the data functions of my phone when on the wifi?

Would it really hurt to call people more? Maybe I’ll enjoy it.


#offBoarding (or #alighting)

#offBoarding (or #alighting)

There’s lots of talk about Onboarding. Wikipedia sez:

Onboarding, also known as organizational socialization, refers to the mechanism through which new employees acquire the necessary knowledge, skills, and behaviors to become effective organizational members and insiders.

I love this idea that carefully curating and designing a process for new starters to get up-to-speed and be better integrated into your company can bring nothing but sunshine and unicorns, create better bonds, lower attrition and more engaged staff.

But what about when someone leaves? It’s usually a short process: leave is negotiated in private (either a jump or a push), it’s communicated to the wider team, some handover, perhaps there’s an exit interview, “clean out your desk”, eat a bit of cake, say goodbye down the pub and Mondays aren’t the same every again.

For everyone else in the company.

The leaver will be enjoying the delights of the next company and their onboarding process, but the people at the old company? Mourning the loss of an ally, a compatriot a peer.

And this is where I wonder whether we shouldn’t be paying more attention to the people around the leaver as they work out their notice period. There are thought processes:

The leaver was happy, weren’t they? Why would they choose to leave? Maybe I should leave? Is it better elsewhere

Or maybe

Why were they sacked? Could I be sacked? Maybe I should look for another job?

Or even

Who is going to do their job? Am I doing it now? How will I know I like the new person? Will we get on? Will they be able to do everything the leaver can do?

These thoughts all lead to a risk that those around the leaver, the peers (and perhaps the reports) will be feeling adrift, unsure, unsteady, things have changed and it’s resulted in someone I like/respect/admire/fear not being a such a big part of my life anymore.

I feel like we need to account for this somehow. To have a process of offboarding for the people around the team member – make sure they understand why the leaver is leaving, what that means for the future of the team, how they might use this upheaval, this change as an opportunity for improvement, or promotion or simply to realign themselves with their team, their company and their career. Use somebody leaving as a positive thing to promote … something good. My thoughts here aren’t clear and I believe that whatever the process is, it’s probably going to be specific to your company anyway.

(Hat Tip to @nefarioustim for the #alighting alternative)



I prefer interviews that are a conversation as opposed to me asking questions and listening to answers. I want the candidate to engage with me like they would a colleague – it shows they’re taking the process seriously and are interviewing me just as much as I am interviewing them. I love it when I leave an interview thinking “I really want them to work here, I hope we impressed them enough!”.

What I want to know about a candidate is what experiences have they had before and how they dealt with them. I want to hear about real world examples. Questions will usually take the form of “Tell me about a time that X, what did you do?”

“X” could be:

  • you had a difficult team member.
  • you had a ridiculous deadline.
  • you had some tough politics.
  • you worked with remote stakeholders.
  • things really went bad.
  • thing went really well for you and the team.
  • Etc…

Usually these will be a conversation rather than a question/answer session, but still based on the candidates actual experience as opposed to “What would you do if?”. However, it’s OK to say “Actually, I’ve never had to deal with that, but if I did, I would …”

I also want to know about actual projects themselves as I’ll be trying to get a feel for team/project size, the position of influence the candidate felt they had within the team. The language people use is important – are they talking about they/them or we/us?

I’m looking for PM style – are they command and control, or servant leader? Or somewhere in between? The language they use is as important here as the actions they took. Do they use people’s names from previous projects, or just “the developer” this is telling, although not conclusive.

Finally, I’m looking for evidence of autonomy and mastery. I want the successful candidate to be someone I can point at a problem and they’ll get on and deal with with little interaction from me.

Should you have a set number of acceptance criteria?

Should you have a set number of acceptance criteria?

A conversation came up today in which a statement was made about having a set number (three, in this case) of acceptance criteria per user story. My gut reaction was that I didn’t agree, how can you define that? But then I got to thinking that maybe it wasn’t such a bad idea.

I turned to the internet and asked twitter, the replies were heartening.

I agree with these replies, however, I’m not convinced on having a fixed arbitrary limit. I think it’s a case of being vigilant and for someone to say “Hey, that’s a lot of A/C, maybe we should split this?”

It’s also relatively simple to avoid the limit by loopholes. For example, your A/C could be described as Given, When, Then. In this, you could add “and then … and then… and then…”. It’s still one A/C, but has multiple steps.

As with everything in the world of building software, it’s about balance and discipline.

A great retrospective!

A great retrospective!

I’ve blogged before about remote teams where I am now and how well we manage to make it work, even with people in another timezone. Because we’ve got people remote, our retrospectives are, naturally, done over video chat (hangouts in our case) and we use webwhiteboard (by none other than Henrik Kniberg!) to make it as interactive as possible.

Today, we had just such a meeting and I really wanted to show you the output. Nothing much to learn from this post (except how we retro), but I thought the webwhiteboard worth sharing – just for fun.


Sunday Link Dump!

Sunday Link Dump!

First up, is this most excellent post from Joshua Arnold over at Black Swan Farming. Called “Standing Up Doesn’t Scale” it’s a comment on “false friends and local maxima”, that is having standups and kanban boards, without actually knowing why you’re doing it and what problem you’re trying to solve. Too many organisations are like this and it’s frustrating for everyone involved -especially those hired to help with the transition in the first place.

#noEstimates is a torrid love affair of biblical proportions and, by biblical, I mean magic pregnancies! Anyway, I liked this post from Glen B. Alleman over at Herding Cats because he’s, again, poking a stick at fanatic dogmatism. I don’t agree with everything he says, but it’s a good speech from the prosecution. The Problem With #Noestimates

One for the people people here. Hiring is one of the most important things you have to do in a business – no, seriously, it is. Hiring the wrong people (or, the right people for the wrong role) is hugely damaging to your company. This post talks about what it takes to hire hire an engineering manager. From Calille Fournier at Elided Branches, Hiring Engineering Managers: Screening for Potential

Nothing is immutable

Nothing is immutable

“But they’re the project goals!”
“So what? They’re not appropriate any more.”
“But they’re the project goals, you can’t change them!”
“Watch me.”

Challenge everything and remember, nothing is immutable. If you make your project goals redundant (and you should always try and prove the negative hypothesis), you’ve made a huge discovery.

Nothing is above the laws of science – hypothesise, test, learn.

Dancing to the wrong beat

Dancing to the wrong beat

It’s something we’re not going to get away from: mashing traditional projects and project management with agile. You know it as many names – waterfall, scrumerfall, scrumbut – each as bad as the last. It comes in many guises: time lines, gantt charts, milestones and my favourite, governance.

You can have timelines and milestones, they’re not too far removed from Release Planning, as coined by (and then retired by) Mike Cohn. Gantt charts are OK, if you turn them on the side and use them as a product backlog, but something I cannot really get behind is governance.

Now, there are a truckload of different types of governance, but what I’m talking about is “agile governance”. Brian Wernham talks about it an an APM blog post here and it’s an interesting read. Essentially, it’s a sponsored, empowered set of controls. You could argue that the blog post is over 18 months old and not relevant anymore, but my experience says otherwise.

Sounds crappy, huh?

The idea of governance is that it allows a group of key project people (think stakeholders and team members) to get together regularly in a room and talk about the project. Not altogether too dissimilar to sprint demo, except the governance meeting is future looking and the demo is a view of the last itertion.

The trouble with the governance meeting is that it tries to tie you into a plan, “What are we going to do next?”, “When can we have X thing?”, “What are our biggest risks and how do we avoid them?”

But the biggest and most troublesome problem with the governance meeting is compounded during an “agile transition/adoption”, you can bet your ass that before a company started being agile, they had governance meetings and so, after the adoption, continuing with the governance just helps to reinforce bad habits and out of date ideas on how “projects” should work.

The meetings cause anxiety – instead of going into it (as in a demo) with a list of things to show for your effort, you’re going in with a list of problems that, if you could solve them, you already would have, so they’re unsolvable right now and not worth talking about, they just make you more anxious. You’re going to talk about the future of a project with some of the wrong people and not all of the right people – afterall, it’s a team sport – why leave some of your A players on the bench? Many of the people in that room will not be in your team and not be accountable for the work that get’s done, the planning or the outcome.

Push to get rid of governance and provide everything anyone needs at your demo. It’s the only way we’ll make any real progress on a project. I think that the GDS has got it mostly right. It’s the government, so they’re going to have governance, but they couch it in these terms

GDS has defined 6 principles for governing service delivery. Following them should help you create the right culture within your service. They are:

  1. Don’t slow down delivery
  2. Decisions when they’re needed, at the right level
  3. Do it with the right people
  4. Go see for yourself
  5. Only do it if it adds value
  6. Trust and verify

See what it doesn’t say there? It doesn’t say weekly (or regular) meetings with the same people just to see what the status of a project is and complain when it’s not “on schedule”. Head through to the Governance Principles page, it’s an excellent and enlightening read.

It’s not often anyone can say “let’s be more like the government”.