Where Do You Keep Your Risks?

June 12, 2019

I’ve got a question: Where do you keep your risks? If you’re doing a project of any significance you have risks, right? That just comes with the territory. Anything that is significantly challenging or meaningful has very likely got some risk associated with it. And let’s also clarify that we’re asking about agile teams. Because we all know that traditional waterfall teams would have some sort of risk register. Risk is just built-in to the waterfall model, so we don’t need to bother those folks.

But if you are an agile team, where do you keep your risks? I’m not trying to be deep about this. Simply put, if I asked, could you show me your current risks? Yes or no? Most agile teams that I ask this question say “No.” Some tell me that they ROAM their risks once a quarter. That’s nice, but looking at risk for 30 minutes every quarter hardly qualifies as effective risk management. And then guess what I ask? Where do you keep those risks you ROAMed in your last PI planning? Uh…we didn’t.

So where are your risks? Now this is the point where some people might get defensive and say that risk management is build into the agile process (insert your flavor here). To which my answer is, if risk management is built in to your process then it should be trivial to show them to me. To that, they answer that risks are always resolved immediately rather than waiting in large batches. OK, there are certainly some risks that are trivial to resolve, but there are many risks that are long term and require more than a little effort to manage. What about those risks? Can you show me those risks? No? Huh.

So what do you do with your risks? If you own them how do you know it? If I asked you what risks do you have today, could you show me?

Agile Risk and the Business Landscape

March 7, 2019

Simon Wardley does a marvelous job of highlighting some of the essential requirements for understanding and defining strategy. There are five key elements that he describes in his book:

  • Purpose – why are we trying to do something
  • Landscape – the map of the business domain
  • Climate – the weather
  • Doctrine – the rules of the game
  • Leadership – decisions we make

The underlying premise is that you can’t have meaningful strategy without a map. All of these elements support that contextual understanding of strategy and the decision making necessary to interpret and navigate the business landscape. Otherwise, without a map you are flying blind. Wardley’s book does a wonderful job of explaining this much better than I can.

So as I’ve been trying to digest and understand strategy and the need for a map, it occurred to me that this might also apply to risk. Can we understand risk without an understanding of the landscape? Is Wardley Mapping not only useful for strategy but risk assessment as well? I suspect some might argue that strategy and risk are inextricably linked. That could be the case. Perhaps all strategy is really a very high level of risk management? Or perhaps it is just one element of strategic thinking. Because I would assume that accounting for risk is part of all good strategic thinking. Food for thought.

Risk Mapping

March 1, 2019

Recently I’ve been reading Simon Wardley’s book on strategy mapping. I’m finding it to be some of the best writing on strategy that I’ve ever come across, so I really recommend it if you have the inclination to learn more about strategy. Simon is a very vocal critic of the typical tools that we consultants use to ‘do strategy’ with. In particular, he is especially critical of the use of 2×2 diagrams and SWOT analysis. His central observation is that strategy as we do it today, does not take into account the landscape, climate and doctrines that should be applied. Instead, many, if not most of us, are guilty of talking about strategy while completely ignorant of the landscape, climate, etc. In fact, most strategy is usually a series of gut feelings backed up by the opinions of the highest paid people in the room and nothing more.

That’s quite a damning indictment of modern business strategy as it stands today. Unfortunately, I think it is a rather accurate critique based on my own experience. This reading on strategy has gotten me thinking about risk and how it relates to strategy. When we attempt to use a SWOT matrix to talk about strategy, one of the things we are attempting to do is address risk, at least indirectly. When we are talking about strategy, risk can be something that we run toward to take advantage of or run away from or try to guard against. In that sense, risk is a key consideration in the discussion of strategy.

I find that relationship of risk to strategy fascinating because risk is a precursor to many of the impediments that organizations face. If you haven’t seen it before, I have a model for how risks evolve in an organization over time. It works like this:

Risks => Impediments => Lessons Learned

According to this model, risks are a possible impediment that we may or may not encounter. Once we have encountered an impediment (assuming we have done nothing to mitigate or manage the risk), we may learn from the experience after the fact. So, this is a model for the evolution of risk for agile teams. The cool thing about this model is that we can use risks to detect upcoming impediments (think of finding risks as possible impediment detectors). 

Given that this model might hold true, how does strategy impact risks, and ultimately, organizational impediments? I think that strategy may be our first opportunity to understand the big risk picture. I suspect that in many organizations, this view is not widely shared, which is a shame. Also, if understanding the business landscape and climate is critical to understanding strategy, then isn’t the landscape and climate critical to understanding business risk as well? Perhaps we need to be using Wardley maps when we discuss risks too. It’s interesting food for thought.

When Impediment Management Won’t Work

September 6, 2014











I stumbled across Pawel Brodzinski’s blog on Software Project management. In “Why Kaizen Boards (Typically) Don’t Work” he talks about the importance of having the right culture that will support using and taking full advantage of the tools (Agile, Lean or otherwise) that people try to introduce to organizations. He notes that when the culture doesn’t permit experimentation without permission, introducing any kind of continuous improvement effort is almost always doomed to fail. He makes a good point. I’ve seen this pattern myself and it applies just as much to managing impediments as it does for any other kind of improvement.

Some signs you may have a problem introducing a change:

  • Taking action requires getting permission (this is straight from Pawel)
  • Stating the desired change is too risky
  • Action can’t be taken because projects are too important
  • Only certain people can take action

I’m sure this could be a much longer list. The take home message for anyone who is interested in initiating this kind of change: Make sure that you have the buy-in from your organization. Talk about these sorts of examples and discuss how you might deal with them. Use the feedback from that dialog to inform what changes you try to make.

Developing the Impediments Game

January 16, 2012

I was inspired recently by a twitter post from Elizabeth Hendricks where she said she was working on an impediments game. I thought that was an absolutely wonderful idea, so I wanted to take a swing at it myself. Once I finally managed to summon the courage to try I sat down and put together a preliminary set of rules. Here is my first attempt (first iteration):

Overall the game is organized as a straightforward racetrack, first-to-finish objective. Gameplay is in rounds, where each round consists of a capacity roll and an impediment roll. Capacity is the number of spaces a given team may advance. A roll of 1-3 means a team must take an impediment from the impediments deck. Impediments are subtracted from the teams capacity each turn and have a fixed cost that must be paid in order to remove them. In each turn a team can decide to spend their capacity on forward advancement toward the project finish, or apply some or all of that capacity toward resolving impediments. The team that reaches the project finish line first wins the game.

So there you have it, a set of rules to begin with. They’re pretty simple, but I don’t know anything about designing games so simple seems like a good approach for me. Next, I raided the kids game chest for some dice, playing pieces and a few ideas.

To make a board, I took some 3×5 cards and cut them up and laid them out in a pattern that was inspired by Candy Land. I cut up a few cards and made myself a deck of impediment cards. So now, I had a board, some playing pieces, impediment cards, and a 6 sided dice.

Not a bad start really. It looked like this:

OK, sorry about the table cloth – I know it’s atrocious. So I tried playing out a simple scenario to see how it felt. I had two players, blue and green. Blue was going to take the strategy of always investing in resolving impediments, and red was going to try and plow along without paying the impediment tax. So we started with round one, with both players at the start:

Green goes first and rolls a 5. I moved him five spaces forward and then rolled the dice again to see if he encountered an impediment. That’s two rolls each turn for each player: the first roll determines how many spaces they may travel forward, the second roll determines whether or not the player encounters an impediment (a roll of 1-3 means you draw and impediment card, a roll of 4-6 means that you didn’t encounter an impediment). Green rolls a two, so he pulls an impediment card off the deck:

This impediment card had a value of 2. This means that from now on, when Green rolls the dice to see how many spaces forward he can go, he will have to subtract 2 from the value of each roll. For example, if he rolls a 4 he can only move forward 2 spaces (4-2=2). Now in this case Green is just going to suck it up and try to keep going forward without eliminating the impediment.

Blue’s turn is next. He also rolls a five right off the bat. For his impediment roll, he rolls a 1, so he also pulls an impediment card. His has a value of 4 (that’s a pretty steep impediment). So at this point in the game, after one turn each, our players are at the exact same place on the board, however we haven’t had a chance yet to play our strategies out.

Green has the next roll and  gets a 6 so he moves forward 4 spaces, taking into account his unresolved impediment of 2. He then makes his impediment roll, and wouldn’t you know it? He gets a three, which means he just earned himself another impediment. This impediment is a 5. OUCH!

Blue takes his next turn and gets a 4. Instead of moving forward, he uses those 4 to pay off his impediment and resolve it. I arbitrarily set the price to resolve the impediment as equal to the impact of the impediment. So for this turn, blue doesn’t get to go anywhere, but at least he doesn’t have any impediments to deal with. Nice!

So then it’s Green’s turn again…but wait…Green has accumulated 7 points of impediments! There is no role of the dice that will overcome that (six sided dice anyway). So Green is completely blocked. He rolls a five, but because of his unresolved impediments he’s not going anywhere (5-7= no forward progress).

And so it goes, blue ends up racing to the finish line, resolving the occasional impediment along the way. Green remains trapped, completely impeded and unwilling to resolve the issues blocking forward progress.

At the end of the game I realized a couple of things. First, I had impediment values that ranged randomly from 1 to 5. For green, this meant that they accumulated pretty fast. Green only made it two rounds before he was stopped completely. You could argue that this makes sense. Any team completely unwilling to address their impediments at all is likely to have serious problems. On the other hand, I might argue that in reality, most of the impediments that I encounter on projects tend to slow it down rather than stop it completely. So I’m considering lowering the impediment values in the next iteration.

Perhaps more importantly, I’m not sure that this particular scenario offers a significant learning experience or not. It seems a bit too simplistic to me. Perhaps I need to add some additional elements that might better reflect the chaotic nature of the typical project? I’ve created a set of Risk cards that I’ll also try out in the next round. What else should I try? Next stop: iteration 2.


May 28, 2010

I was watching a presentation on risk today and I saw a symmetry between risks and impediments that I had never realized before. With both, the hard part is awareness. Once you’ve discovered a risk or impediment, half the battle is over. Seeing risks before they become impediments is hard. The discovery step is the part where I tend to fall down.

How many times has someone pointed out a risk or impediment and you find yourself palm slapping your face in embarrassment because you missed it (and it was SO obvious)?

When it comes to managing risks and impediments, seeing is often the hardest part.

Risks, Impediments, & Lessons

May 21, 2010

I was talking to a group the other day about impediments. We were debating the temporal relationship between risks and impediments. We arrived at the following conclusion: Risks are potential threats to our projects that lie in the future. Once they manifest themselves in the present, we call them impediments. And once impediments are resolved and we move on, they become lessons. I’m intentionally not referring to them as “lessons learned” because I’m not sure we always learn from the experience.

So risks exist in the future, impediments exist in the present, and lessons exist in the past. I like the relationships and the terminology – it helps me to understand how to deal with these creatures.

A Few Resources On Agile Risk Management

May 18, 2010

I’ve been spending some time researching impediments and risk management – two topics that I believe are intimately related. I wanted to take a brief moment to share some of the great resources that I have found along the way:


The Project and The River

May 2, 2010

I’ve had this idea bouncing around in my head for a while that I haven’t quite been able to articulate. Let me see if I can use an image to explain it…let’s pretend that your project is a river. It moves, sometimes rapidly, sometimes slowly, working its way downhill toward some sort of goal. Along the way, the river encounters obstructions in it’s path. Some are large obstructions, perhaps a beaver dam, others are relatively small obstructions like a boulder. The river may be slowed by these impediments, but it finds its way around them. Some obstructions it is even able to move out of it’s way – logjams break, trees are undermined and give way.

Our projects, like our metaphorical river, are shaped by the obstacles that they encounter. Our projects have obstacles that they can remove, and others that they can’t – and we have to work around those. If we could visualize our project’s progress over time, we might describe them as a winding river. They bend and twist, they rush and go calm.

What if you were to take away all of the obstructions in our river metaphor and just look at the water by itself? You would see this snaking tube of water that behaves in all sorts of strange ways for no obvious reason. If we follow the path of this watercourse (I visualize it as hovering in the air) we would have many questions: Why does the water suddenly turn into a hectic spray here? Why does it slow down and turn into an enormous slow pool there?

Without seeing the obstacles, you would only be able to speculate what the causes of these phenomenon were. I believe that we treat our development work in the same fashion as this river. We ignore the obstacles and only look at the work (the water). We don’t see the boulders (impediments) that we work around every day. We wonder why the project is moving so slowly, or we marvel at the sudden, unexpected rush that we never saw coming. If only we could see the obstacles before or even as we reached them. That’s what the good teams do.

We and our projects are shaped by the obstacles that we encounter every day. If you want to understand what shapes your projects, you need to understand the risks and impediments that impact it. If you are aware, and able to manage these issues, then you move from reacting to the obstacles to anticipating and mitigating their impact. You are able to change the shape of your project/river. You move from participant to architect.


April 10, 2010

I’m reading Ellen MacArthur’s book, “Taking on the World”. She is arguably one of the greatest sailors around. It’s her story of her life leading up to and including her amazing race in the Vendee Globe.

Before she ever got to the Vendee, she spent years working on other people’s boats. She would prep them, repair them, and otherwise set them up for the big races. She had to know the systems of these amazing race machines inside and out.

These were largely solo racers that she was working with. Once they left the harbor and crossed the start line, they were on their own with no outside help for weeks, even months. Preparation for these racers was critical. Any undetected flaws would very likely come back to haunt them somewhere in the middle of the ocean. Not an attractive thought.
She would spend hours, days, weeks reviewing, inspecting these boats for weaknesses. She would be looking for the telltale warning signs of problems, like rust on the connecting terminals, minute cracks in the paint around areas of stress – anything that would indicate a possible problem.

She was engaging in a form of risk management. The inspections she was doing were designed to uncover the risks that might jeopardize not only the race, but perhaps even the sailor’s life. This sort of assessment goes on all the time in the sailing world. When you go to buy a boat, you get a survey. The point of the survey is to uncover risks to the buyer. Have you ever watched a surveyor in action? They use a lot of checklists.

I’ve watched some great sailors prepare for races too. You can see them wandering over a boat, running their hands over every inch, opening lockers and sticking their head in, tugging on lines – looking for risk. I imagine they have a mental checklist that they are using too.

When we are managing our projects, how do we inspect them? We can use checklists. We can ask others for advice (something that Ellen did very well). We can make things visible – the equivalent of sticking our heads into lockers and looking around. There are a variety of things we can to to look for risk. Being a good project manager, like being a good sailor, means being aware of and constantly on the watch for risk.