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

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!


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 ( 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.

Letting them build it

February 27, 2019

Agile methods like scrum and XP are very exciting, especially when you are first introduced to them. There is something very common sense about the ideas in them that seems to resonate for a lot of people. I know it was that way for me. I’d looked at a lot of different project management methods before settling on XP (thank you Steve McConnell). A lot of those methods looked interesting, but XP was the first one that just made sense. For a young project manager looking for a new way to do things, it was an easy choice. 

Now when you look closely at a method like XP you learn very quickly that it is actually a collection of practices, many of which have been around for a very long time. The thing that makes XP work, is the way that this particular set of practices or, as I like to think of it, this big agile bag full of cats works together. For instance, iterations by themselves have been around for a very long time under a different name: time boxes. Pair programming on the other hand, was a relatively new innovation as far as I know (although not entirely unheard of). And while continuous integration had actually been around in some form or another for a while, it was certainly best articulated and demonstrated by the proponents of XP. On their own I would argue that each of these ideas had plenty of merit, but the real magic happens when you combine them together. Each of these practices, and in XP there were roughly 13 of them, complements and overlaps one or more other practices in the set. So as a whole, you have a system of related ideas that have some redundancy and interconnection. You can see this in Ron Jeffries’ diagram of XP.

Now this gives you a package offering of interrelated ideas that many, including all XP practitioners I’ve ever met, say you need to adopt as a whole. You can’t just pick and choose the bits you like and expect to get great results. Why not? Well, I would go back to the redundancy and interrelated ideas. Let’s suppose for just a minute that you adopted all 13 XP practices, but you found that continuous integration for one reason or another was “too hard” or “not a good cultural fit” or for some other reason wasn’t going to work for your team. What might happen? Well, in all likelihood, in the short term you might not see any immediate effect. In fact, you might find that the team goes a little faster because they aren’t struggling to build continuous integration into their process. But hang on, we’re not done yet. You see there are practices that depend on continuous integration in order to work. For example, test driven development (TDD) and continuous refactoring. TDD relies on CI to give the developers quick feedback on their tests. That can’t happen without CI. So, developers are going to lose feedback on their tests, which means they aren’t going to get as much value from doing the tests in advance…and therefore they aren’t likely to keep doing TDD. Quality may start to suffer. And if they don’t have CI and TDD, then they don’t have the safety net of tests that they need to do continuous refactoring…so they are going to be less likely to try refactoring because it feels too risky.  By removing CI we have undermined quality and the resilience of the system we are developing (because we’re no longer refactoring). 

The impact of removing practices, especially in a pre-packaged set of methods has some rather insidious consequences. Things don’t immediately fall apart. Instead there is a gradual erosion of benefits that causes a cascade of related and also seemingly unrelated problems. You may still be getting some benefit from the remaining XP practices, but the system is now much more fragile and less resilient. You have removed some of the reinforcing mechanisms from the method that helped insure it is robust. When the team encounters a crisis, some sort of emergency in production where they need rapid turnaround and depend on high feedback, they aren’t prepared. They are slow to respond, introduce more defects and likely to struggle. At which point someone is liable to point out that this process sucks. Congratulations! Of course it does, you made it suck.

This is the reason that adherents of pre-packaged methods tend to sound so religious about the unequivocal adoption of all their practices. You have to adopt all the practices, otherwise you aren’t doing XP, Scrum, Kanban, and so on. I want to pause for a moment, because I don’t think that’s the end of the story. 

If we were to stop for a moment and look at development and management practices (agile and otherwise) we might find that there are practices that tend to have similarities that might cause us to group them together. Testing and QA practices like TDD, BDD, and others do share many similarities. Estimation practices like story points, ideal developer days, and others also share similarities. My point is that for any given meme or idea that we have in XP or in agile in general, there are multiple supporting practices that may fit. In addition, some practices are sophisticated enough that adoption can be measured by degree rather than in absolutes (we are 30% toward CI rather than all or nothing). My point is that there are multiple options for many of the key elements of popular frameworks. And even within many of those options there is a matter of the degree of adoption. After all, as so many agile advocates often say, it’s a journey, not a destination. Therefore, if I’m 30% of the way along the path, that must be worth something.

All of this is to say that we can substitute our own practices with some judicious caution. We’re allowed to do that, despite what the more religious might say. In fact, we can mix and match to find the elements that work for us. Now this is really hanging our toes out on the radical edge. Ivar Jacobson has something he calls essential methods. Basically, it is a catalog of development methods that you can combine and recombine to build your own framework. Now, you can still screw up. Remember that the reason that frameworks like XP and scrum have been successful is that they have concepts that are interlocking and support each other. The DIY approach is much riskier (practices may or may not support each other), but for some groups that may be the best way to go.

The important thing is to understand why these frameworks work as well as they do. They are composed of a series of practices that support each other, making them robust in the face of a world full of disruption and challenges. You mess with them at your own risk. Or…you build your own. Just know that you need to understand what you are building. If you do it poorly, it very likely won’t work.

Time Machine

February 26, 2019

OK, Mr. Peabody, where are we going today?

Well Sherman, Any time I explain what Scrum or XP is, I start with time boxes. The time box method has been around a really long time. The earliest record I can find in a casual search is where they were used at DuPont in the 1980s. I suspect that time boxes are much older than that. The time box basically applies a constraint to the system. It creates an arbitrary start and end date, usually on the smaller side. You commit to a fixed amount of work and when the end of the time box is reached you are done, no matter what the completion state of the work. Work that is complete is counted as done within the time box, work that still remains to be finished is either scope that gets dropped or perhaps that work is continued in the next time box.

This technique has some benefits:

  1. Deadlines, even arbitrary 2 week time boxes, help keep everyone focused.
  2. Deadlines force the question of prioritization. Not everything will fit in the box.
  3. Small time boxes create a short heartbeat or pulse that is useful for measures of capacity and throughput.
  4. It forms a useful skeleton for the OODA improvement cycle

There are also some challenges:

  1. Small time boxes demand that you figure out how to break work down into smaller, but still valuable pieces. Many teams find this hard to do.
  2. Small time boxes means that it is almost inevitable that scope won’t be delivered sooner or later. How the business manages this scenario says a lot about how the benefits of time boxes are perceived.
  3. Much of the angst of estimation is due primarily to the fact that teams are struggling to fit work to their limited capacity in ways they didn’t have to prior to the time box.
  4. It doesn’t work if you can’t break the iron triangle of scope, schedule, and quality. Scope usually has to be compromised in some form or another in order for time boxes to work (it’s kind of what they are based on)

Like so many other things, a time box is useful in the right context, but not all contexts. I’ve seen a few projects where a time box would not work (hardware constraints, legacy mainframe applications, an organization that wasn’t willing to give up the iron triangle, etc.). All too often we force the time box on the team and tell them that they suck if they can’t overcome the challenges. Sometimes that’s true, other times it isn’t. It’s a judgement call. Beware, and don’t let yourself get caught forcing a round peg into a square hole (I’m looking at you Scrum).

The Zombie Cure

February 25, 2019

So, pretend for a minute that you’ve been asked to consult for a company. You do a little research on them: they’re a name brand, their products have names your parents might recognize, and there are a bunch of hot startups providing the same service for free. Basically, they have a distinguished history and a lot of resources, but they are already on the wrong side of the disruption wave. In short, they’re getting their butts kicked in the market.

These companies are sort of the corporate equivalent of zombies. They still stumble about making product, and occasionally eating the brains of another company (and a consultant or two), but they really haven’t realized that they are dead yet. From an outsider’s perspective though, it’s pretty clear from the moaning noises coming from within, that the undead are indeed walking the earth.

Oh…and did I mention that they want you to help them transition to agile?


So what do you do? I’ve watched enough zombie movies that I know what the high survival strategy is: pound some nails in a baseball bat to defend yourself with and…run away (rule #1: Cardio). However, I’m told that’s not a very dignified look for a management consultant. That’s a pity. I think the Mad Max Consultant look just might work for me. So what are we to do for these zombie companies?

Well, first, the wrong answer to the agile transition question is “Yes.” You see, agile isn’t really their problem. In fact, I’m fairly certain there is no compelling evidence that agile cures zombies (or helps with zombies in any useful fashion). If the market has left you in the dust, because you have been outmaneuvered by faster, more nimble companies, then making your teams fast and nimble after the fact is too little, too late. Besides, everyone knows making zombies faster is a really stupid idea. You’ve already lost the product battle. No amount of prioritization, estimation, or retrospectives will restore life to a dead product.

The fact is, that with the increasing pace of change and disruption, if you wait to change until after the wave has passed, there is no catching up. You really only have two options:

  1. Pivot: Go back to whatever pale shadow of a customer base that remains after your zombie apocalypse and see if there is a peripheral, closely related market that contains a significant opportunity to capitalize on. I remember doing this when the printing software business was nearly wiped out by the introduction of the web. Everyone saw that train coming. We did a pivot and tried to move into packaging software. It was a good idea: the web couldn’t replace the need for packaging and it was a big business. Unfortunately, we didn’t quite do it fast enough, and a bigger company ate us. That company? Kodak. Welcome to Zombieville. (Mmmm…brains!)
  2. Prioritize innovation over everything: Give up notions of productivity and efficiency, those ideas are for healthy companies with viable products. You’re basically a startup again, and you need to find another market – FAST! It won’t be pretty and it won’t be easy. People need to be rummaging through garbage bins looking for the next product. Anything goes. It’s risky taking a bet like this, but keep in mind what the alternative is – an unquenchable thirst for brains. You decide.

Now I confess that I’ve had a lot of fun writing much of this with my tongue firmly planted in my cheek. However, I believe that the question is a serious one: How do we answer a struggling company that from all appearances is doomed? As consultants we are faced with this question from time to time. I know that some would run away from a company like that. There are those in our business that just want to work with winners. I can’t disagree that working with successful companies is rewarding. However, if I’m honest, I also don’t think it’s very impressive.

I must have a thing for the underdog. My motto should probably be, “If your company doesn’t suck, I’m not interested.” Or, according to Google translate, “Si lac filio societas non est: Ego non quaero.” You see, if your company is awesome, you really don’t need me. There are a host of mediocre consultants who I’m sure are eager to help. However, if your company sucks, then there is the real possibility that together we can make a significant difference, and save the world (OK, I got a little excited there, just your company). That’s what I find exciting. That means I’m probably either a really good consultant or an ambulance chaser.

Phew, time to watch some zombie movies and brush up on my technique. I’d like to thank: the Academy, George Romero, the entire cast of The Walking Dead, and those strange people lingering at the Hotcake House after 3:00 AM.

Does Your Company Suck?

Then we should definitely talk. I provide innovative agile coaching, training, and facilitation to help organizations transform to deliver breakthrough products and performance. I do this by achieving a deep understanding of the business and by enabling the emergence of self-organizing teams and unleashing individual passion.

To learn more about the services that I offer or to arrange for an initial consultation, please see

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…

Just Go Touch the Boat

February 23, 2019

A few years ago, I set out to build a boat in my garage. It was a pretty substantial project. Frankly, it was a lot more than I think I was really prepared for. Nevertheless, I did it. It took me about three years to get done, but I finally realized that particular dream and went sailing on a boat I had built myself. Pretty cool, right?

Well, one of my biggest frustrations was this weird phenomenon that happened right before I got started on the work. I can remember it happening in a very specific place: in the garage doorway. Full of good intentions, and ready to get down to cutting some wood, I would pause at the entry to the garage. There was this moment of uncertainty. Often it wasn’t just a moment though, this could turn into a 10-minute-long, what-in-the-hell-was-I-thinking pause. Often it could completely derail me. I’d spin right on my heels and head back to the couch where a beer and Netflix (and blissful determinism) awaited me. It got so bad that I had a rule: just go touch the boat. I figured doing that much would get me close enough to the problem to create the momentum to figure out the next step.

That pause…what was that?

It was a real killer. Here’s what I think it was: it was realizing that I really didn’t know what I was going to do next. At a high level, I knew I wanted to work on the boat. But the specifics – what part of the boat was I going to work on, what did I need to do specifically? That often wasn’t fully thought out. I had an instruction manual, but that really only described the high-level activities that I had to do. The devil was in the details. I suspect that the delays came down to a few different categories of problem:

  • Setup– Are the requisite materials, tools and plans ready for the next step in the process. Are these preparations in a state where I can easily get started or is there some work I need to do before I can even touch the boat. Often this would be cleanup activities. Often, I had left my workspace a mess after the last session, so I couldn’t get started or find tools until I cleaned up the place. Or perhaps my wife had the audacity to park the car in the garage, thereby blocking my access to my precious…sorry…my boat. 
  • Comprehension– Do I really understand how to solve the problem at hand? I’ve learned that much of woodworking is a series of problems. At a macro level, the work is straightforward, but when you get right down to it, you discover that the tools you have don’t work right. Or you are missing a tool. Or you have no clue how to get the geometry of two pieces right in advance.
  • Drive– There were times when I had things set up, and I knew what to do, but…I didn’t want to. Sometimes the prospect of turning on the table saw, braving the spinning blade of death, and filling the garage with a fine layer of sawdust (over absolutely EVERYTHING) was just too much. Huh…there, I said it. There were these moments when I just couldn’t face the effort after a long day at the office or sometimes even on a Saturday.

I mention all of this because I find myself in a similar position now. I’m not building a boat. Instead, I’m building a business. Just like a boat, there are plenty of instruction manuals. The problem is, just like with the boat, the details are often different from what they describe in the books. And I find myself eager to get started. And yet I pause…

So, I’m re-using a mantra that served me well when building the boat: just go touch the boat. I’m not sure what to call this pause. This moment of uncertainty before committing. But I’m willing to bet big money I’m not alone. 

Open Space Refined

February 22, 2019

A few years ago I started the Agile Management Conference here in Seattle. I organized it as an Open Space conference. I had seen how other open space conferences worked and it all seemed pretty straightforward:

  • Opening Orientation to OS and how it works
  • Introduce the Theme
  • Open the Marketplace
  • Magic Happens
  • Closing Circle

Easy, right? At least that’s what I remember. I’m sure Harrison Owen felt a disturbance in the force as I described it. Anyway, you do a few of these and they can fall into an easy to recognize pattern. Sometimes it’s not very good. It goes like this:

  • Opening Orientation – One hour of everyone desperately avoiding eye contact as the facilitator relentlessly orbits the room
  • Introduce the Theme – Which we all immediately forget
  • Open the Marketplace – In which we face the terrifying prospect of speaking in front of 200 people
  • Magic Happens – Maybe? Let’s face it, that’s what we all hope will happen, but you never know…
  • Closing Circle – The attendees who weren’t quick-witted enough to leave early are corralled into the circle where they have to hastily make up appreciations for the sessions they can’t remember attending

That’s a pretty cynical and snarky way to put it, but I think it’s OK to point out that the baby may have some ugly spots if we can learn from it. Let’s face it, not every open space is equally successful. I think there are two ways to try to approach this and each has some trade offs.

First, we can attempt to change the structure of Open Space. For example, I can tell you from personal experience that the first time that you try to run a new open space, you may very likely feel pressure to try and provide a keynote speaker of some kind. Why? Basically because a conventional conference sells itself based on its fabulous speaker lineup, where an open space can’t do that. You have no idea who’s coming, let alone who is going to talk. As an organizer, that makes selling the event a little bit harder. Why come to my open space? Because it’s just going to be awesome! Who’s going to be there? I don’t know! That right there is a recipe for some sleepless nights as an organizer who has to pay for the caterer, venue, etc. in advance.

Now using a keynote speaker is one well known way to attract people to your conference, but it’s definitely not part of Open Space. Open Space is intended to be self organizing and by its very nature is designed to avoid situations where everyone just comes to listen to some appointed expert. It’s really founded in community conversation, so bringing in outside experts and giving them a special place in the conference potentially jeopardizes ability of others to bring their own voice to the discussion. Again, this is an example where we attempt to change the structure of Open Space by adding something new or removing an element.

While I appreciate how tempting this is and even tried it to some modest degree, I’ve come to realize that there is another way to ‘customize’ open space that is perhaps more in the spirit of what Harrison Own intended. It wasn’t until I saw a few recent examples that the light bulb finally came on for me. Instead of changing the structure, we really need to zoom in on the theme and the experience.

I saw this recently with the AONW 2019 conference in Portland, where the organizers and facilitators made an extra effort to reinforce the theme and asked the participants very explicitly to address the theme in their conversations. They asked someone from the community to share their perspective on the theme, which brought home the message with some real personal impact. And they repeated the theme. Every. Single. Day. That definitely changed the experience of the conference. I saw another example of this in the Play4Agile conference. I wasn’t there, but apparently they used illustrations and quotes from The Little Prince on posters throughout the conference. I love that idea and it reminds me that we can use the way we decorate and structure the space to reinforce the theme. Is there food that would compliment the theme? We can invite people from the community related to the theme. It seems to me that there is ample opportunity for enhancement and richness within the framework of open space as it is. I just didn’t know that that might look like. Now I do.

There is one more thing that I think may be important. Size. I’ve been in small conferences where I can name everyone in the room. I’ve been in large open spaces where there are hundreds of people in the room. To me, knowing the participants is important. There is a level of intimacy and shared experience that I feel can get lost when we have really large groups in open space. I lose the feeling of diversity and start to see everyone as relatively faceless. Maybe it’s just me and I’m easily overwhelmed, but I struggle more in larger groups. As a conference organizer, I was definitely of the bigger is better variety. But lately, I’ve started to reconsider that emphasis on size. I’ve found that I kind of thrive on the energy in small groups. I know that open space can be big. But I’ve started to lean toward small. Small is beautiful.

It’s becoming clear to me now that like with many self-organizing systems, the rules are simple, but using them well is complicated.

Pernicious Escalation

February 21, 2019

I found this lovely pairing of words in Yves Morieux’s book, Six Simple Rules. He was talking about the corrosive effect that problem escalation can have on teams and management. I’ve seen this before and I know how hard it can be to deal with. On the one hand, as a manager you are there to help and you may feel somewhat flattered when the team comes to you with a problem. On the other hand, as Morieux suggests, an escalation represents a failure of the teams to find a way to arrive at a solution themselves.

First, an escalation often reflects an inability to cooperate on the part of the parties involved. The problem with cooperation is that one group or another usually has to give something up in order for the problem to be successfully resolved. And the thing they are being asked to give up or forego is usually something that they really want. I see this all the time in product management decisions. Two teams are working on features that have been stressed as of the highest importance to the organization. One of the teams falls behind and asks the other for help. It is clear that a choice has to be made. There are three options, Feature A, Feature B, or both (we’ll just leave neither out of the picture for now). One team or the other has to either work extra hard, or drop a key feature. All too often, both teams throw up their hands in frustration and escalate the problem. Why? Because they can’t find a way to solve the problem together.

Second, escalation defeats attempts to empower people and teams. If you give teams the power to make their own decisions, what you have really done is give them the power to make their own compromises. Compromise is hard and my observation is that it’s just human nature to try and avoid it if we can. Of course escalations’s just putting the power back in the manager’s hands. So it defeats the very purpose of pushing decision making power down in the organization – to move the decision closer to the people doing the work.

That brings us to our third and final reason that escalation is harmful. Escalation removes or distances decision making from the source of the problem. This is based on the premise that the best informed people to make a decision are the people who are closest to the problem. The further that you remove someone from the work or the source of the problem, the less likely the decision is to be well informed and useful.

So Morieux recommends that the first thing a manager should do when they receive an escalation request is to lock the two parties in a room and explain that they have to work it out together. They need to learn that the correct answer is some form of cooperation. If they can’t cooperate, then the manager should let them know that cooperation is essential to their performance and as such she/he will keep this in mind when reviews come around. That’s pretty tough…but I like it.

Eliminate Fear, Create Safety

February 20, 2019

Often silos within an organization are based on fear. There can be many different justifications for such fear. For example, the fear is expressed as territoriality, “This is my turf, no outsiders allowed.” You see this with teams who will not allow others access to whatever it is that they control. They use all sorts of justifications to support this (compliance, regulations, etc.), those reasons are often just smoke screens for the fact that they are afraid of opening up and letting others in. Outsiders are a threat. If you let someone in they get to see how you work, and maybe they will recognize areas of weakness (change, improvement). Sometimes they do not fear the outsiders as much as they fear their own management. This is typically manifested as a pattern of C.Y.A. (Cover Your A**) behavior. When this happens, you find resistance to letting others in because it may expose them to criticism by others.

How does fear manifest itself? If you are trying to talk to someone in another group and they start whispering to you so they can’t be overheard by others, that should be considered to be a strong indicator of a culture of fear. This is someone who feels that they cannot say certain things without some sort of punishment. On the other hand, the fact that they are willing to take a risk and share with you at all is a sign of trust on their part – trust in you.

What can we do about it?

First, we need to acknowledge that there probably is not much we can change in their environment. Whatever is causing the issues with fear hopefully has little to do with you. That means that all you can do is make sure that you do not aggravate the situation further when you are in their domain. The last thing they need to do is fear you too. That means that you have to be willing to deal with them in a fashion where they do not feel threatened. If they think you are going to escalate issues to their management, then you are not going to have a chance to build any trust with them. On the other hand, if they believe that they can bring difficult issues to you and that you will do everything you can to help them out, and then you have a shot to build a better relationship.

How can we create safety?

Ultimately, what we are after is the kind of relationship with the other group that can be open an honest. That does not mean everybody is happy all the time. Quite to the contrary, a healthy relationship, a safe relationship is one where the two groups can get upset with each other and express grievances. Signs of safety?

  • Disagreement
  • Emotion
  • Reassurance
  • Laughter
  • Good-natured teasing

Some of these things may seem contradictory. Emotion, especially strong emotion can seem very threatening. Disagreement and conflict can also be seen as a threat. However, in an environment where people feel safe, these things are part of healthy interaction. You need someplace where people can feel passionate (strong emotions). You need someplace where people can take a contrary position and debate alternatives (disagreement).

Cooperation vs. Collaboration

February 19, 2019

I was working for a small company that was acquired a few years ago. Soon after the acquisition was finalized, our senior VP invited his new boss to come visit us and meet with some of the leaders of our organization. I was invited to that meeting and introduced as someone who had been leading the agile transformation within our group. I remember shaking this guys hand and thinking he was probably some sort of ex-college football player. He was enormous, sporting a giant smile, and he did what he could to set us all at ease. He exuded confidence and power. After all, he was an exec with a fortune 10 company.

We were all given a chance to ask him questions. I wasn’t feeling very smart at all that day. In fact I was a little intimidated if the truth be told. So I asked what I thought was a pretty lame, if harmless question, “How can you help to promote collaboration between our two groups?” Like I said, weak stuff. His answer was priceless,”Collaboration? Isn’t that what they shot people for in World War II?”

Right then, I knew I was in for a rough ride.

I’ve been reading a book by Yves Morieux and Peter Tollman called “Six Simple Rules: How to Manage Complexity without Getting Complicated.” Yves Morieux first caught my attention in Ted Talk that he gave a few years ago. In that talk he made a compelling case for the over-complexity of today’s large organizations. His argument was that you needed fewer rules and constraints, not more, in order to improve. It turns out, he is speaking from experience. He has tried his approach out with multiple European organizations with some success apparently.

One of the things that he emphasizes early on is the importance of establishing and reinforcing cooperation rather than collaboration. Collaboration is good, he argues, but it’s too limited in scope. It can mean a little as we talked together, but perhaps didn’t actually do much. Cooperation, he argues, implies that at least one side had to give up something, and actually accomplish some work together. So he sees cooperation as a stronger statement than collaboration. Perhaps it is.

Do they shoot people for cooperation?