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

IMG_2191

 

 

 

 

 

 

 

 

 

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 Games Fosters an Experimental Mindset

January 21, 2012

So, for the past week or so, I’ve been developing the Impediments Game. You can see some of my efforts: interation 1, iteration 2, Interlude, and Iteration 3. Now I have no experience or expertise designing games, so as you might imagine, there has been a great deal of trial and error involved in this process. Whenever you add a new element or change an existing rule or component of the game play you are doing it with some sort of hypothesis in mind. For example, If I add “Accelerator cards” it will give the players a way to overcome the negative impact of impediments. That’s the kind of hypothesis I’m talking about. How do we actually run an experiment to test the hypothesis? We play the game!

Game play gives us the tangible feedback that we need to validate our hypothesis. Playing the game gives us both subjective and objective data. How does the game play feel? Was it fun? How long did the game take? How many cards did you use? Which strategy won out?

What I’m experiencing as I play the game is a lot of different questions – questions that can form the foundation for the next experiment:

  • How would the game work without cards (I could try using points…story points? The person with the most story points wins?)
  • What could I add to the game to promote teamwork? Would there be some sort of benefit accrued by helping your opponent?
  • Should elements like risks, impediments, and accelerators have a limited lifespan?

Of course the real joy of games is that you can run your simulations over and over and tweak things until you are happy with them. That’s what I mean by an experimental mindset. I see all too many teams that seem unable to come up with meaningful experiments to try and modify their performance. They have a hard time coming up with the “What if…” part of the mindset. Perhaps they should be playing, or even better, making their own games.


Developing the Impediments Game – Part 4

January 20, 2012

So today was a day to make a few changes and take stock of where things are at. The first change I wanted to make was to double the length of the game from 20 spaces to 40:

Changing the board like this actually raised a few interesting questions about the game for me. First, what does each space on the board represent? It could be:

  1. A square, just like on the sidewalk, just a position to advance to…
  2. It could represent a unit of time, like a day, or a sprint
  3. It could represent a position in a queue or a backlog

In this case, for right now I’m going to just keep it simple. I haven’t assigned any particular meaning to the spaces (although the astute observer might notice that they are now arranged in rows of ten, just like some sprints…). All I really want to do right now is insure that the game is sufficiently long enough that I can guarantee that whatever strategies each player of the game uses has a chance to fully play itself out in the duration of the game. In the first iteration of the game, with only 20 spaces, the game could play itself out in 4 rolls of the dice. That seemed too short, so I’ve switched to 40 spaces.

The other thing I felt it was important to do was to spend some time just playing the game and question the value that I was getting out of it. So I played this longer version, but just with the impediments, not with the risks. I learned that if I played two players with equal strategies – in other words both doing the best they could to win given the circumstances of each roll of the dice, the game felt a little frustrating. You spent your time trying to move toward the finish and were constantly being assaulted with impediments. It felt pretty tedious.

That brings up an important point: in most board games there are both positive and negative things that can happen to a player, even if they all just occur by chance. The classic “CandyLand” is like that. Playing with just impediments is kind of depressing. Especially when you can’t do anything other than pay their price. That’s where adding an element like risks to the game allows you to start doing something to proactively avoid impediments. Integrating risks into the game makes it feel much more interesting. Apparently dealing with impediments doesn’t feel nearly so bad when you have a strategy to deal with them. I think there might be some keen observations on learned helplessness lurking under that observation someplace.

What else can I do to give the player ways to deal with impediments? How about some Accelerator cards?

What would accelerators be? Here are some examples:
  1. TDD
  2. Pair programming
  3. Continuous Integration
  4. Continuous Deployment
  5. Automated testing
  6. Retrospectives

Each one of these things are the types of activity that a team can use to mitigate the impact, or even completely avoid some kinds of impediments. Time for more cards! I’m going to have to hit the office supply store soon!


Developing the Impediments Game – An Interlude

January 18, 2012

I know what you’re probably thinking by now: MORE on this silly game? Well, yes (I’m so embarrassed). You see, it just gets more interesting as I continue to play with it. Today I decided that I needed to improve the impediments cards in the game. In previous iterations, the cards had the word impediment printed on one side and the impact or cost of the impediment was printed on the other side. I thought it would make the impediments much more interesting if I used some real world examples. So, using the list of 100 impediments that was compiled by William Wake, I added an impediment description to each card. Now they look something like this:

What I like about having actual examples of impediments on each card is that players now get familiarized with different kinds of impediments while they play the game. Players actually might learn about different kinds of impediments! That’s kind of a nifty idea.

You see I have a confession to make: so far the game has been a way for me to try and model my own hypothesis about how impediments and risks impact teams. For example:

Hypothesis: A team that deals with impediments will have a higher velocity than at team that doesn’t address their impediments.

Hypothesis: A team that deals with Risks will have fewer impediments to deal with and subsequently higher velocity.

I confess that these are not complicated hypothesis, but they pose the kinds of assertions that I would like to validate. It turns out that constructing a game with rules that define the boundaries of the problem is a really fun and engaging way to test the validity of those assertions. But as I build out the game further, I’m starting to realize that games can also have learning objectives as well. Perhaps I ought to define some of those. For example:

  • People who play this game will learn about different kinds of impediments – some that they may not have ever considered before

Well, that sounds like a pretty good thing to me!

So now I’m thinking about the game a little differently. I’m looking at the games not only validating my own hypothesis about how impediments and the way we manage them (or fail to) impacts teams, but also providing a tool for teaching others about what impediments are and how they work. I think more people should create games!


Introducing Change in Stable Environments

August 31, 2010

Introducing change to an organization can be very challenging. This is especially true when the organization is quite stable to begin with. For example, if the teams have been working together, on the same product, in the same roles, for years at a stretch, then you are very likely going to find that change may not be received well at all. It’s pretty obvious really. We all get into our comfort zones, learning to do the things we all do best, and we dismiss change with a, “No thanks, I’m just fine. I like it this way. This way works.”

Frankly, from a certain perspective, change can just look like a whole lot of risk, with only marginal reward – if even that. So what do you do if you are someone who is trying to get some change out of a very stable, well established group with no obvious inclination to change? Well, I’m glad you asked:

First, create some instability in the environment. Oh boy, that ought to make you popular! The fact is, that without some sort of instability in the environment, it’s very hard to effect change. Without the instability, there is no perceived need to alter our habits. We need to create a situation where we leave our comfort zones. The best way to do this? Mix things up. Move people between teams. Put them into domains they haven’t worked in before, working with people they haven’t worked with before.

Nobody in a stable organization is going to like this, but it may be just what it takes to get people learning again. If we can get them into learning mode, then we can start to experiment with different ways of solving problems, and that’s when new practices look a whole lot more interesting.


Inspection

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.