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.


The Poor Neglected Impediment

February 28, 2019

I wrote a book a few years ago about dealing with impediments on agile teams. It’s right there on the upper right of the page (I’ll give you a minute to make your purchase). Well, the industry has continued on since those heady young days, and two things are still true: people still underestimate the impact of impediments, and impediments are bigger than ever. 

Where agile was largely a team level affair not much more than a few years ago, now it is much bigger. Scaling is all the rage. Now we work in teams of teams or in things called release trains. Entire divisions of major corporations undergo mind-bending enormous agile transformations. We now have many different kinds of frameworks that we can use when making those transformations. One of the most popular is SAFe. If you haven’t seen it before, you should check it out scaledagileframework.com

The first thing you will see is the “Big Picture.” It is an enormous diagram that attempts to portray all of the processes and practices that you can apply to use the framework. They’re not joking about the ‘Big’ part either. That diagram is downright intimidating. Go ahead, grab a magnifying glass (you’re going to need it) and let’s take a closer look. You see all sorts of things that we are familiar with in the agile world in that picture: user stories, features, scrum, kanban. All of my favorite technical words are in there. It’s a process management smorgasbord! Did you notice anything missing in that diagram? I don’t know about you, but it seems like they threw in everything but the kitchen sink! Oh…wait…hold on a second…where are the…impediments!

THEY FORGOT ABOUT IMPEDIMENTS!

I’m outraged! Shocked! Shocked I tell you! The nerve of some people. Oh, I’m sure they make some passing mention of impediments deep in the smelly bowels of their documentation. Someplace dark, where no one will find it. Impediments are certainly not a first-class citizen in SAFe’s world. I’m so depressed. Well, I guess that’s it: SAFe sucks. 

But then again, If I go look at some of the other scaling frameworks, surely, THEY will have impediments, right? Let’s go take a peek at LeSS (less.works). AAAAARRGH! Again, no impediments! But…maybe one of those more disciplined frameworks like DaD (Disciplined Agile Delivery) will make some passing reference to impediments. OH NO! Not again! None of these frameworks makes mention of impediments. They all suck.

Well, fine. Be that way. Go ahead. Ignore impediments (You fools!) See how far you get. I’m not bitter. Go ahead, call me when your precious value streams are tied up in knots. When your teams are blocked from delivering to production. You see, now, perhaps more than ever, impediments are increasingly relevant, especially when we start talking about scaled agile development. Risk management doesn’t go away just because your agile got bigger. 

In all seriousness, I think that it’s worth considering where risk management does fit in the popular agile frameworks (or perhaps why it doesn’t). All too frequently I think it is lost. To some degree that is not a surprise. Many of these frameworks are so top heavy with processes and practices that it’s a miracle they don’t collapse under their own weight. Why pile on yet one more practice to the mountain that is already there? It’s just one tiny little process. Wafer thin mint anyone?

Alternatively, perhaps it’s time some of those frameworks went on a bit of a diet. And rather than trying to cram in the latest fad like continuous delivery, devOPS, etc. perhaps we should toss out a few things and try a little risk management. It could be a real lifesaver.


Impediments vs. Constraints

February 24, 2019


I was describing impediments to a friend last night over a couple of beers. Hey, that’s what happens when you give a guy like me a beer. So this poor friend of mine, he’s a really sharp guy with a lot of experience with operations management and as he patiently listened to me, he said, “You mean impediments are constraints?” To which my immediate answer was, “Yes!” Impediments can and often do create bottlenecks in value streams. Anything that causes delay is an impediment, or alternatively, a constraint on the system. Therefore, we can deal with impediments and explain them using models like Goldratt’s Theory of Constraints (ToC). 

Very cool!

So, later on, in a more meditative moment (and with a conspicuous absence of beer) I asked myself the transitive question, “Are all constraints impediments?” To which, I suspect the answer might be, “No.” There are definitely some constraints in systems that interfere with the flow of value and are fundamentally not serving the goal of helping maintain rapid delivery of value to the customer. However, there are some constraints in a system that are necessary to keep the system healthy. For instance, in some businesses like health care, finance and others, there is an audit and compliance constraint that act as constraints on the delivery of product or value. Those are constraints that are necessary to insure the ongoing health of the value stream. Otherwise, without these constraints in place, the value stream (or organization) is exposed to substantial real-world risk. We’re talking about the kind of risk that can destroy a product or company, which is unacceptable. So, I think there are some constraints that are not impediments – they are necessary for the ongoing health and performance of the organization. 

Or perhaps I just found a constructive use for impediments? Oh my…


Agile2016 is Coming!

July 9, 2016

hands-people-woman-meeting-large

“This is where the Agile tribes meet.”

Agile2016 is swiftly approaching. I’ll be there in Atlanta doing a couple of talks this year. If you are going to be there you should definitely come check them out:

The Self-experimentation workshop is something that I originally developed a few years ago for XP2013. It is very hands-on, each attendee contributing their own experience to the workshop. To date it has been very popular. Some attendees have described it as one of the most invigorating talks they have ever attended. That’s pretty high praise – it’s probably my all-time favorite workshop.

If you are interested in getting a bit of a sneak preview of what this self experimentation stuff is all about, you can check out the experiments that I have run on the onestandardman blog. There is also background material here and here.

On the impediments front, there is a lot of material that you will find right here in this blog. For example there is this, and this and this. And then of course there is The Little Book of Impediments. There will be copies of the book at the bookstore for purchase at the conference. Catch me and I’ll be happy to sign one.

There will also be an Agile Management Conference meetup that will be held in the Open Jam area (time & date at the conference is TBD – check the Open Jam Board) so please join us for that if you are interested.


Make Resolving Impediments a Habit

October 17, 2014

David_City_Rey_grocery_store

I’ve talked a lot about the rigors of finding and resolving impediments for a team. There is one thing that I have left out: the people part. I learned this lesson at a conference that I was co-hosting. I had been in charge of setting up the food for the event. Getting the caterer, arranging for meals, that sort of thing. As you might imagine, it’s a pretty tough job to satisfy the dietary requirements for a very large group of people. I learned of whole categories of food allergies and needs that I had never even imagined existed! There was a little bit of every imaginable combination. Everything from your standard gluten free diet all the way to lacto-ovo-pesca-leguma-veganitarians (OK, I made that last one up).

We did the best we could to satisfy the needs of most folks and pretty much called it good. About halfway through the conference, someone mentioned that there was no food that fit in their dietary needs. I expressed my sympathies and referred them to the grocery store around the corner. I really didn’t give it another thought. A few minutes later, I heard the same complaint made by the same person, but this time the reply was, “I’ll get you something, I’ll be right back” And that person ran off to the store themselves. Wow!

I was humbled. The difference between my reaction and theirs was the difference between someone who could empathize and take action to resolve the impediment, and someone who couldn’t. The lesson I learned that day was that in order to help people with their impediments, it takes empathy. You have to feel their need, and be receptive to doing anything to help them out. I think I had missed that before. That willingness to serve the needs of others is really important. All the strategies in the world for resolving impediments won’t help anyone if you don’t care.


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.


Those are Not MY Impediments!

September 5, 2014

Army Boots Stand Out in a Crowd

 

 

 

 

 

 

 

 

When trying to find impediments there is a trap that awaits those of us who are outside of or observing the team. Often, when you are observing a team as an outsider, you may think you see patterns of behavior and obvious disfunction. Naturally enough, not being part of the system often gives us a fresh perspective from which to see problems within a team. Often I have found myself able to rattle off a list of issues that I see a team dealing with after observing them for only a few minutes. Some patterns of team disfunction are suspiciously easy to detect. But wait, here comes the trap. So you make a list, maybe write up a few recommendations and share your “gift” with the team. What team wouldn’t appreciate someone kind enough to share a list of all the ways they suck?

Nobody.

It doesn’t matter if you are right (and you probably are at least 50% of the time). Best case, the team thanks you for your honesty. Worst case, they kick you out of their standup and tell you never to come back. In any case, they aren’t very likely to take your suggestions seriously. The thing about impediments is, in order to really own them and take them seriously, they need to be something the team genuinely care about – and most likely they should be the team’s idea. Ownership is important, because often impediments are pretty tough to deal with, so you need to be really committed if you expect to resolve them.

Often, what I think I see are two different lists of impediments: the scrum master, coach or manager’s list, and the team’s list. The scrum master is scratching their head wondering, “How can I get these guys to engage with these impediments?” Meanwhile, the team is thinking, “Do you really want to eliminate an impediment? Fire a scrum master!”

So I guess the lesson here is that often nobody is all that interested in what you think the impediments are. They already know what the impediments are. They’re just waiting for someone to really listen.