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.

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.

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

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!

This time around I wanted to add a new element to the gameplay: risk

So how do risks work? Well, a risk is something that you can decide to address at any time, so you can pull one from the deck at any turn. After all, risk is always there, right? If you pull a risk from the deck, you will find it has a cost to mitigate the risk. That cost is expressed in the number of spaces you give up in order to “buy” or mitigate the risk. What is the benefit of mitigating a risk you ask? Well, if you have a risk that you have paid to mitigate, then you can avoid the next impediment that comes along. In effect, you are taking out insurance against a future impediment. My view is that there is a risk lifecycle where:

An unmitigated risk can become an impediment which can (perhaps) become a lesson learned

It is a progression of sorts that I believe takes place in the project management world. Fail to deal with the risk, and you are more likely to encounter an impediment. Fail to deal with an impediment, and you now have an opportunity to suffer (and hopefully learn).

I also thought that aside from the role of the dice, there ought to be an additional level of uncertainty. Everybody knows that bad things can happen on projects, right? Major setbacks can come out of nowhere. So I borrowed a notion from the game, “Chutes and Ladders” and created “slides” where a team could slide backwards on the project and lose ground if they just happen to land on the wrong space.

The “slides” are the black bars on the board that connect two spaces (OK, I stole some hair ribbons from my daughter).

OK, so how does this actually play out in practice? Well, once again I started with my two players: this time it was Green and Red. Red would take a strategy of addressing risk, and Green would take the strategy of ignoring risk and simply dealing with impediments. Here’s how each turn of play worked:

1. Roll the dice to see how far you advance
2. Roll the dice again to see if you encounter an impediment (you found an impediment if you roll 1-3 otherwise you dodge the bullet) Take an impediment card if the roll dictates
3. Optionally, take a risk card

On the next roll for advancement you get to do one of three things:

1. If you have an impediment card you must subtract the impediment from the roll in order to “pay the impediment tax” and move on. This can take more than one roll (causing you to lose multiple turns).
2. If you have a risk card, you can pay for the risk card before moving on. Again, you subtract the value on the card from your roll. The practical cost is that you lose turns while you address the risk.
3. If you don’t have an impediment to deal with (Lucky you!) or a risk to mitigate (eat your veggies!) then you are free to advance further on the board.
4. If you have a previous risk card that you have purchased, you can use it to skip paying for an impediment you have discovered.

So how did this all play out? Well, the player (Red) that took the strategy of paying for risk up front. Sure enough, they started off slow, but then they raced around the board, and even with a few unfortunate slips on my “slides” they still managed to easily outpaced the Green player and won the game. Lesson? Address your risks early and you will avoid future impediments, but are still subject to the vagaries of project circumstance.

OK, so I’m feeling a lot better about the game now. This second iteration was pretty interesting. It’s not quite so trivial and seems to allow (me) to explore some interesting trade-offs in risk and impediment management. Now, I’ll know I have something great on my hands if one of my kids walks by and offers to play. Who wants to play? I’ve got a few more ideas, but I’ll save those for iteration 3.

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.

Call me a jerk, but these are the product owners that I least like to deal with. I almost prefer an actively hostile product owner – at least then I know that they care! Instead these ghost product managers do nothing to engage the passions and the commitment of the team. Soon I find that the team is coming to me and saying, “We don’t see much value in the work we are doing…” This is a very bad sign for a team. When you hear this from a team you can rest assured that you have a product owner who at best is distracted or at worst just doesn’t care.

Of course part of the problem is that I just haven’t worked with that many really good product owners. I think they are a rare breed. However, I saw something the other day that gave me pause. I was watching a coordination meeting for a big program that was getting started. The meeting was being run by a talented facilitator and there was a very charismatic product manager who was conveying a very obvious air of “being in charge”. You could tell that he had an ego the size of Texas. He was comfortable with public speaking, he used terms that were dramatic and conveyed a sense of purpose and commitment. He also conveyed the sense that he was confident an knew what he was talking about. People would defer to his knowledge of the business domain. He was brash, arrogant, had a full head of hair, and I almost instantly despised him. I know that type of guy all too well. He was just like me – with hair. What a jerk!

I saw him again a couple of months later and he was still selling the hell out of his program. I remembered thinking to myself, “Does this guy ever quit?” There he was in front of the team. He was basically reaffirming the value of the product that they were all trying to deliver. He was still selling the heck out of it! At the time I’m afraid I must confess I did not recognize the value of what he was trying to do. It all seemed a bit too “high school cheerleader” to me. So instead I settled for quietly loathing his presence.

So lo and behold, there I am a month or so later working on my own program. And I don’t happen to have a product owner who is charismatic, energetic, or at least has a face. No, instead I’m working with some guy I’ve only met once who lives on the east coast and who has not shown up for a planning meeting in recent living memory. The project is stumbling along, like many of them sometimes manage to do. Schedules are slipping, impediments are being worked around rather than being resolved, and we all pray for the day when we get to work on another project. And then it hits me.

I need to sell this baby. Well, somebody does anyway. It’s probably more suited to the product owner’s role, but in their absence somebody’s got to do it. Otherwise this project will just quietly fade into obscurity. Perhaps it should be put out of it’s misery. If you can’t get the product owner to care, then maybe the best thing to do is to let it die. But there is another school of thought here. Leadership on projects is not always clear. By that I mean that sometimes the product manager is a strong leader, sometimes the project manager is a strong leader, and yes, sometimes that giant dork, the development manager is a strong leader too. Sometimes, but not always. In fact the chemistry has been a little different on nearly every team that I have ever worked on. The fact is that the leadership may be hard to find, it may lie in different, even unexpected places – but it must be there somewhere.

One thing to keep in mind is that your leadership needs are going to vary based on the size of the group you working with. If the project you are working on is a nice little single team project with just a couple of iterations to it, then you probably don’t require much in the way of overt and active leadership. In that case it’s probably enough for the team to be well functioning and trusting each other. The commitment is small enough that it doesn’t require any particular skill of vision or any additional requests for re-commitment. The value of these small projects is often small enough that everybody usually feels that they are easily achievable and they don’t require much additional motivation to achieve.

Then there is the more complicated project, really more of a small program. These projects might have two or three different phases, milestones or releases to them. They generally take longer than your typical individual project and they require more commitment on the part of the organization and the team. The added risk and uncertainty, simply due to that introduced by the increased scope and the concomitant unknowns make these projects more worrisome to all involved. We’re not talking major fear, uncertainty and doubt here, but we are talking about the kind of program where, with just a few things going wrong, the mood can swiftly change from, “We think we can do this” to “We’re all going to die!” These are the types of projects that require someone, an engaged product owner – someone who will consistently paint a clear picture of the overall goal and help the team understand and appreciate the value that they are delivering to the customer and the organization. It may not take all that much, and you may even find that you can get away without it, but like I said, it’s much more likely in these situations that you will find that life goes a lot smoother with someone who is willing to actively rally the troops.

Finally, there is the genuinely large program – to me this is any program that has 3 or more teams, each of whom has multiple overlapping milestones that they need to hit in order to deliver the program successfully. Often times these teams are also distributed/dispersed teams as well. These are the programs where you need one hell of a good salesman. You need someone who is good at bringing people together and helping them feel like they share a common goal. Someone who is good at working with large groups of people – this can’t be the kind of person who will shy away from a room filled with 50 people. They need to be fairly energetic and be able to tell a compelling story. And they need to know the business really, really freakin’ well. They have to have some sort of very real respect within the group. For the really big programs, you probably need more than one person like this. Or maybe not. When I have worked with the multiple leader scenario I have also see a lot of infighting, which can be death for any project, large or small.

These are just some observations and speculations. They aren’t based on any kind of empirical data. To a certain degree they are based on observations of things that I have seen missing in myself as I work with teams. They are also what I often need from a product owner. Teams really need leadership as much as anything else from the product owner. However, leadership is one of those intangible skills that is very difficult to impart in some sort of training class. Certainly it is not the kind of thing that you will find in any sort of product owner certification course. The point is, I think teams need it from the product owner, some more than others, but they all need it.

Of course I suck at things unless I find some sort of way to formalize it into a set of things that I find easy to remember. So how would I formalize what I am asking for here? First I would bring back a much stronger emphasis on the project kick off meeting. This is the first opportunity to sell the project/program to the team and it is very important that you do it well. Second, I would put together regular status updates with the group, perhaps along the lines of key milestones that would serve to bring the group together and reinforce that original commitment to the project. Finally, I will treat impediments very aggressively and review them with the product owner and make sure that not only are they aware of them, but that they are taking an active role in resolving them as well. The team needs to see that the product owner is just as committed to removing project impediments as anyone else – perhaps more so.

There was a short video made back in the 80’s that made a huge impression on me called, “Bambi meets Godzilla” Maybe you’ve seen it. It’s epic. There’s Bambi in the meadow looking all dewy eyed and innocent and munching on daisies. Then you are treated to that iconic Godzilla roar and Bambi looks up, alarmed. You see one giant lizard foot descend out of nowhere and Godzilla stomps on Bambi.

The end.

The first time I saw that film as a teenager I think I laughed so hard I cried. I’ve always had a soft spot for the big rubber beast. There is something about the classic Towering Terror of Tokyo that has always turned me on. He sort of reminds me of “Uncle Bob” Martin.

Fast forward to today where I find myself roaming the complacent halls of corporate America. I must confess there are times when I look at a room full of cubicles and crave a little of that Godzilla action. Yeah, you heard me right, I want to rage right in there full of radioactive terror and unleash a little destruction! I want to turn up the Blue Oyster Cult to eleven and breath a little radioactive fire and and smash a few cubicles with my mighty rubber tail! Gazing down over the typical cubicle warren, I think I know how Godzilla felt looking down on an innocent fishing village just before smashing it all to bloody oblivion.

You see I have a confession to make: Godzilla and I have a lot in common. I call it my “Godzilla complex” Here’s why:

Godzilla hates tiny little walls. So do I! You know how villagers are. Living quietly within the confines of their narrow little cubicle walls. They’d all be going about their daily drudgery, testing, writing code, filling out TPS reports, and generally just bowing down to the man. But as anybody who has watched Godzilla movies will tell you, Godzilla will lay waste to anything with walls. You see, he’s actually a huge fan of transparency, and nothing defeats transparency like cubicle walls. Fortunately, nothing defeats cubicle walls like a hundred foot long lizard tail and the aforementioned nuclear breath. That breath just melts ‘em right down to the designer berber carpet.

Godzilla hates meetings. Me too! Picture yourself at a typical ghastly corporate meeting. Some dork has called you in to a meeting with no agenda and genius couldn’t find a consensus if you clubbed him over the head with it. You know the kind of meeting I’m talking about. There you are thinking, “Oh great, Just 5 more of these meetings before I can go home and get some work done.” That’s when you need Godzilla. You know Godzilla doesn’t like your meeting when his dorsal fins start to glow red. He’d let out one of those monster, mind bending shrieks of his and then he would bite the head off the bozo who called the meeting. He wouldn’t stop there either. He’d probably use his radioactive breath to melt the face of the marketing guy sitting next to him. Then he’d smash the conference table into splinters with his mighty rubber tail and storm out of the room. Meeting adjourned. Oh God that felt good…

Godzilla hates architecture. What a coincidence! Me too! Nothing spells doom for a decent, well run project like architecture. Now I’ve seen enough Godzilla movies to know that if there is one thing that the Rambunctious Rubber Raider does well is destroy architecture! He takes out most of downtown Tokyo! That speaks to a serious…no, pathological hatred of architecture. That’s because Godzilla knows that architecture is the enemy of simplicity. There! I said it. I feel much better now. It took a giant rubber lizard to teach me that lesson. And a fifth of vodka.

Godzilla hates impediments. Nothing brings out the Raging Radioactive Rubber beast in me like impediments. Nothing. The thunder lizard and I share that in common. Nothing stops Godzilla either. Not robots. Not aliens, not a two headed dragon thing. Or a moth creature…or a retarded looking turtle…Nothing!

So what are you? Bambi or Godzilla?

I discovered the other day that I have apparently gone over to the dark side of Agile. It’s unfortunate, but understandable given the circumstances. You see I’m a manager now. The minute that happened there were some telltale signs that I really should have noticed earlier. I caught myself telling people that I mentor things like, “I am your father…” I’ve noticed that line gets me a few puzzled expressions in the office. It seems to work better with the kids. Then one day the color of my light saber changed from green to red. I’ve seen the movies and everybody knows what that means. Still, I didn’t suspect a thing at the time. Even when I took to wearing a floor length black cloak around the office like some sort of pudgy corporate goth, I just told people I was wearing it because I was chilly. I didn’t fully comprehend the full power of the dark side until I started to deflect impediments.

Deflecting impediments is like a drug. There is this feeling of satisfaction you get when you manage to deflect dealing with an impediment holding up a team’s progress that is like nothing else I’ve ever felt. Well, actually it’s a lot like strangling a puppy. Yup, we’re definitely on the dark side now people. However, deflecting impediments is not as easy as you might think. Just like being really lazy, it is more work than it first appears. In the interests of furthering the evil methods of the Agile dark side, I will share some of my diabolical impediment deflecting techniques with you.

Minimize the problem. The key here is to dramatically downplay the significance of the problem. The team has come to you for help. It’s your job to convince them that it’s not really a problem. It’s really not that bad. That issue won’t slow you down that much. You can work around it. It has always been that way. If you can master this technique you will become the Jar Jar Binks of management effectiveness.

Delegate to the Team. If you can’t get them to acknowledge that it really isn’t that big a deal, don’t worry. The fallback position is to look at them with an appraising eye and say, “Don’t just bring me problems, I respect people who bring me solutions. So what do you propose?” Let them stumble about and come up with some lame idea. Then smile and say, “Perfect, you know how to solve this yourself!” They have thrown the problem toward you and it has whipped about full circle and ended up right back in their laps! I call this the boomerang impediment. This is worth doing just to see the expression of indignant outrage on their faces. Feel free to combine it with some sort of dramatic gesture (a closed fist works well for me). The coup de grace? Tell them you’re going to hold them accountable. Trust me, at this point the evil laugh just comes naturally.

Reject the problem. Take a tip from Obi-Wan. Just wave your hands and say,

“These are not the impediments you are looking for…”

There are couple of strategies that you can use here. You can plead that it’s outside your control. Sorry, not my department. It’s those bastards in accounting. The point is, there’s nothing you can do. You’d love to help, but you can’t. Every time you manage to do this, somewhere in the world a Scrum Master loses its wings. Or if you are feeling really evil, just tell them to take it to the scrum of scrums – nothing ever gets done there.

Together, using the dark side, we can halt the forward progress of any team. Does my voice sound deeper? Repeat after me: “Come over to the dark side and together we can bring the corporate world to its knees!” Now, does anybody know where I can get a black helmet? How about some platform shoes?

“Practice isn’t much fun.”

No wonder people don’t like to practice! It’s a grind. It’s hard work. It puts you in a place where you fail. Why would anybody practice under those conditions?

While doing my research on practice I came across an interesting book on music practice called “The Art of Practice” When I cracked the cover I was quite surprised to discover that a good portion of the book was given over to the discussion of how to prepare for practice before the practicing even starts. That was a revelation to me. You mean there are ways we can prepare ourselves for practice?

That got me thinking about how I might prepare to practice things that are important to me. Take writing for example: sometimes I’m able to be very prolific, writing with relative ease. Other times it’s a relentless slog. What do I do to prepare myself to write? Short answer? Absolutely nothing! Does drinking count? Hey, either the magic is there or it isn’t, right?

Well what if I were to treat my writing more like practice and less like some fickle magical process that I have no control over? What would preparing for practice look like? Here are a few ideas I’m trying out now:

1. Set the location. Rather than try to write while I’m sitting in front of the TV (a recipe for almost guaranteed failure) I’m only going to write in my office.
2. Set the tone. I’m going to crank up iTunes whenever I write. I’ve discovered that I feel much more productive with certain kinds of music. It really helps. I don’t try and explain it, I just turn the dial to eleven and groove to my SuperTramp. According to my wife, SuperTramp doesn’t work for her. You’ve been warned. Learn from my example and buy some earbuds.
3. Do warm ups. Your going to laugh, but I’ve started using a typing tutor. Here’s my theory: Writing means typing. typing requires some dexterity and that dexterity requires some warming up. If the fingers are ready, then the brain might just be too.
4. Time box it. I will only commit to writing in short bursts. Right now I’m using pomodoro’s. If that doesn’t feel right, I might use (10+2)*5 instead. The idea is to lower the threshold of commitment for myself. I want to take what is often a too daunting task and turn it into something that is easily approachable and achievable.

That’s what I’ve done so far. Here are some additional items that I’m considering adding to my writing warmup repertoire as well (in those outlined above don’t do the trick):

1. Going for a brisk walk before writing.
2. Meditation
3. Hand stretches – don’t want to aggravate the ol’ carpal tunnel now do we?
4. Reading a short story or poem before starting to “prime the pump”

I’m sure this is well explored territory for writers. The idea is that using these strategies I can better prepare myself for the practice that I’m engaged in (in this case, writing). There are a lot of other practice areas that I bet you could apply warm up strategies to. Some examples:

1. Coding
2. Testing
3. Facilitation
4. Public speaking
5. Conflict Management

I’m pretty sure this is just a tiny start. Pick anything that you can practice and I’m sure there is a set of warm up routines that you can use to help make the practice easier to engage in. In a very real sense, knowing that real deliberate practice is hard shouldn’t scare us away from it. We need to prepare ourselves for a good practice session so that we can succeed.

I’ll make one other observation on the results of incorporating this warm up into my writing practice: my writing exercise has become exhausting work. That’s another common attribute of deliberate practice – it’s exhausting. You can’t keep it up for long. I think the warmup helps me get myself into a fairly high state of performance before I begin the practice. I’m already going 100 miles an hour when I cross the starting line rather than 25. I start practicing closer to the peak of my strength, rather than still trying to warm up. Give me 20 or thirty minutes of non-stop hammering away at the keyboard and I’m starting to get tired. Really tired. After an hour I’m totally wasted. I don’t mind. I seem to be extremely productive this way, so I’ll take it. Give it a try. You might find it makes a big difference.

Lately I’ve been living in a strange world. It’s a world where everything is all turned around and inside out. Bad things are good. Good things are bad. In this world things seem to play out the reverse of the way we might normally expect in the real world. For example, in this world impediments that threaten a project’s success are a good thing!

That’s right, in this strange realm impediments are the very best thing that could happen to a project! Let’s say you have a normal project – one that is struggling. Maybe the team really isn’t performing all that well, quality is pretty poor, and things just aren’t going that well. Important issues have not been escalated to management for fear of reprisal…in short, it’s just another mediocre enterprise project drowning under the weight of it’s own mismanaged expectations. As a scrum master for a project like this you might think that your prospects are rather bleak. Perhaps, but not in my world.

You see here we have a tool that I like to refer to as the Convenient Impediment. They’re the project management equivalent of a scapegoat. All you have to do is drum up a few vague ideas for impediments and blame the inability to resolve those impediments for the failure to deliver. A lot of the success in this approach lies in the delivery. You need to start mumbling indistinct references to the impediment early on. No specifics, just make allusions and then refuse to elaborate until you can, “get more solid information.” Then you go quiet for a while and just keep that lethal little bunny in your hat, ready to be revealed when the time is right, preferably close to a key project milestone. Then you whip that baby out and declare that you have an impediment that everyone has known about, and nobody has done anything to resolve. I find it helps to strike a pose of indignance when making such pronouncements.

Unfortunately, the project won’t make the milestone, which is really too bad. It was that dang impediment that got us. At this point it is not considered overacting if you raise your eyes heavenward and cry out, “Why me?” Again, delivery is everything. No, not product delivery, I mean your acting skills, silly!

I’m seeing more and more of these impediments and they seem to have a few things in common:

1. Initially they are quite vague. When pressed, people tend to avoid specifics or even distract you by mentioning a second impediment rather than answer the question (I call this second impediment the “piggyback impediment”).
2. They tend to refer to hard to address cultural issues. You know the one’s I’m referring to: bureacracy, miscommunication, conflict avoidance – it’s those so-called “soft” behaviors that nobody can address with any expediency. Guaranteed project killers.
3. They have the unmistakable odor of bullshit.

Fortunately this isn’t the real world, it’s just the strange world that I live in. In my world, agile people and projects fail…frequently. In this odd place people don’t really see failure as a good thing. Ever. It’s a peculiar place where you see things that were never described in the books. Everything is turned on its ear, people do weird things, and sometimes even the impediments are convenient.

Note to self: I should probably lay off the ‘shrooms for while…