Culture Eats Impediments Too

March 3, 2014

hippo

I stumbled across Pawel Brodzinski’s blog on Software Project management. In “Why Kaizen Boards (Typically) Don’t Work” he talks about the importance of having the right culture that will support using and taking full advantage of the tools (Agile, Lean or otherwise) that people try to introduce to organizations. He notes that when the culture doesn’t permit experimentation without permission, introducing any kind of continuous improvement effort is almost always doomed to fail. He makes a good point. I’ve seen this pattern myself and it applies just as much to managing impediments as it does for any other kind of improvement.

Some signs you may have a problem introducing a change:

  • Taking action requires getting permission (this is straight from Pawel)
  • Action can’t be taken because projects are too important to risk
  • Only certain people can take action

I have a great example of this happening recently: The group I was with raised an impediment. I had a nifty new impediment display that I wanted to try out (impediments displayed on a big monitor that everyone in the company could see). I sat down to add the impediment to the list, and then I had to pause…because the impediment called out something that might upset some folks. It might REALLY upset some people. I ended up not displaying that impediment. Why not? Was I just a chump? Was I too scared to make an impediment visible? Maybe…

Or perhaps I understood the culture well enough to know that certain things were acceptable to display as impediments, and others weren’t. That’s just the way it works at some places.

The take home message for anyone who is interested in initiating this kind of change: Make sure that you have the buy-in from your organization. Talk about these sorts of examples and discuss how you might deal with them. Use the feedback from that dialog to inform what changes you try to make.

 


Developing the Impediments Game

January 16, 2012

I was inspired recently by a twitter post from Elizabeth Hendricks where she said she was working on an impediments game. I thought that was an absolutely wonderful idea, so I wanted to take a swing at it myself. Once I finally managed to summon the courage to try I sat down and put together a preliminary set of rules. Here is my first attempt (first iteration):

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.


Getting Attention

April 21, 2011

I heard a story once from Jeff Sutherland about a team that didn’t have a backlog. Their product owner had checked out for one reason or another and the team was left at loose ends with nothing to do. Rather than tolerating this state of affairs, the scrum master decides to send the whole team home! That’s right, everybody go home until we have some work to do. Go surfing! Have a great time! I’ll call you when the company has work for you to do.

Of course, this was a brazen act that caught the attention of the company executives and they jumped right on the problem and fixed it right away. Nobody went surfing.

At the time, I didn’t fully appreciate what was happening in this little story. There is almost no way that I could see myself telling an entire team to go surfing! The absurdity of the idea was just too much for me to entertain it seriously. Now Sherman, let’s spin the dial forward on the wayback machine to a few years later…

I’m on a project that is going down in flames. It’s bad, really bad. Teams encounter impediments that bring development to a complete stop. We can’t resolve them ourselves, and dutifully escalate the impediments to executives for help. We meet with the executives, explain the problems and the proposed solutions…and get nothing. It’s like reliving the titanic disaster. Somebody shouts “iceberg!” and the executive team continues to drive the ship right into the berg. We’re all going down together and some asshat is playing a violin the whole time.

As a scrum master I screamed, I hollered, I made noise. I did everything I could to draw attention to the problem. However somehow I failed. I went over it time after time trying to work out what I could have done differently. I felt like Robin Hood Daffy, “Ho! Ha ha! Guard! Turn! Parry! Dodge! Spin! Ha! Thrust!” …and then there is that bit where Daffy Duck gets the quarterstaff right in the kisser. Every time.

Recently I was dealing with another project in trouble. The backlog was empty. Again, the team and the scrum master did a terrific job of identifying the problem and escalating the issue to management for help. Again, it was acknowledged and ignored. Yes, thank you very much, now go back to work. However, this time, after the first pass didn’t fly I had an inspiration: I announced that if the team didn’t have a backlog ready for them by Friday, then I’m sending the whole team home.

Now, did I actually have the authority to do that? No. It didn’t really matter – everybody completely freaked out! Why doesn’t the team have a backlog? This is serious! The problem was sorted out in very short order and the team had their backlog.

I’ve decided that there is something about the common ways we communicate in some companies that makes us deaf. If you need help you can’t just tap someone on the shoulder and ask, because you will very likely be ignored. Dramatic actions like threatening to send the team home can serve a useful purpose within a company by getting everyone’s full focus and attention on an issue. Something about that kind of drama punches right through our collective apathy. That’s what happened in this case. It required a little boldness, a little courage, and perhaps a dash of mischief, but it got the job done.


Silo Busting Strategy #1: Understand the Problem Deeply

January 7, 2011

All too often, when we are working with another group their behavior can appear mysterious and difficult to explain. Frequently this is an indication that they are grappling with issues or problems that are not immediately visible to you as an outsider. One classic example is goal setting. While goal setting within groups or divisions is quite common, those groups do not share division specific goals with other groups within the organization. The failure to reconcile the often different and frequently competing goals between different groups in an organization is often the source of many misunderstandings.

So what can we do about this sort of misalignment? First, we can attempt to find out what the goals of the group are. Knowing group goals will help you understand what is motivating the decisions and processes that a group uses. It will also reveal opportunities to support those goals. That kind of understanding will carry us a long way toward building the kinds of organizational bridges that we need to create in order to begin breaking down silos.

We must understand the struggles that the group is dealing with. Is the group short-staffed? Do they have problem people whom they constantly struggle with? Are they learning to cope with a new system? Are they struggling to carry out a complex project? These sorts of issues are the types of problems that cause teams to change their processes and behaviors, often in a defensive reaction to the challenges that they face. Understand the problems, and you can often better understand the behavior surrounding it. Better yet, by understanding the problem you might be in a position to help them address the issue. Help them address the issue, and you will have gone a long ways toward opening new doors between your groups. It is actually a case of impediment removal applied to the organization as opposed to just the team.

If you are looking for a tool to help you accomplish this sort of organizational archeology, I have had some good success using root cause analysis. The application of structured thinking and problem solving techniques can help to sort out areas of opportunity for helping another group slay the dragons that plague them.