Impediment Spotting

So there I was in a meeting the other day (saving the world…yawn). Everything was going smoothly (too smoothly) so I did a quick spot check for impediments. You know, “Hey folks, before we wrap things up, are there any blockers we should be aware of?” There was the usual pregnant pause and then:

• “The teams aren’t talking to each other. I think we should have a wiki page to share what we are doing.”
• “We need a common defect tracking system. I have to look in too many places to find bugs.”
• “We don’t do test driven development.”
• “Bob’s not helping.”

Oh brother…Me and my big mouth. Where to start? One of the first things that I often encounter when soliciting impediments is the dreaded vague problem statement. Some aren’t even impediments at all. They’re just statements of opinion. Let’s take the TDD one as an example:

“We don’t do test driven development.”

Really? No kidding? That’s too bad. Why should I care? Seriously, I know TDD is supposed to be good for you (like motherhood and apple pie), but why should I care if we are doing TDD or not? Why is not doing TDD a problem? Do the teams do any unit testing? Do they have a high defect rate? Is there a lot of staff turnover? Now where did I leave my tiny little violin?

Let’s pretend for the moment that the problem gets a little further refinement:

“We can’t quickly validate our code and spend hours in debugging. We should do test driven development.”

Ah, I see…that’s a little better. Now I think I understand your problem. You’ve even gone so far as to offer a solution (how thoughtful). In fact, what we’ve done is mix up the problem statement and the solution. Ugh! In one fell swoop we have managed to describe the problem and eliminate a whole world of potential solutions from consideration. Brilliant! How about we just limit ourselves to the problem for now, shall we?

“We can’t quickly validate our code and spend hours in debugging.”

Now THIS is a problem statement (OK…impediment) I can work with. I know who is affected. I know what they are doing, I know why it’s a problem. I know where they end up. There’s a lot of information here. So now that we have a decent statement of our impediment, what do we do about it?

Well, you have a couple of options:

1. Do some root cause analysis (dig into that impediment and find out what’s going on)
2. Skip the root cause analysis, because you already know the answer. (No, I’m serious, why screw around? When you know, you know – you know?)

From there we brainstorm a few potential solutions and then we are off to the PDCA races!

You can get all of this from a crappy problem statement. Well, actually you can’t. That’s why you need to take the time to refine the problem statement. Notice that I didn’t just throw out the impediment in disgust in the very beginning. Sometimes an impediment is a clue and we end up the detectives.

Happy sleuthing!

Announcing: The Little Book of Impediments

Impediments have long been a topic that is near and dear to my heart. I’ve just published the first draft of a book dedicated to managing impediments on Leanpub. It’s an idea that I’ve been thinking about for years and finally decided to execute on. The book is a collection of many of my ideas on dealing with impediments from this blog, as well as from presentations and tutuorials that I have done at many conferences. There is still a long way to go, but if you are interested, you can get an advance copy from Leanpub (https://leanpub.com/ImpedimentsBook). You can also provide comments and get updates on twitter using the hashtag #impedimentsbook

Developing Games Fosters an Experimental Mindset

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

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

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!

On Product Ownership

Recently I’ve been dealing with disengaged product owners. You know the type: they don’t show up for the stand-ups, when they come to the standup meeting they don’t bring any stories and instead simply review whatever the team has brought to them – and then leave early because they have more important things to do. When they show up for the demo, they obviously don’t recognize the stories and simply give tacit approval to the work that the team has done. And the scrum master marks the work as accepted. The only time they express any opinion about the project is if it is late. Otherwise they are off in other meetings for projects that seem more attractive to them.

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.

Bambi vs. Godzilla

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?

Going To The Dark Side

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?

Are There Convenient Impediments?

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…

Awareness

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

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

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