Impediment Spotting

April 8, 2013

wolf in sheeps clothing

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!

Leadership Practice #3 – Envisioning

April 22, 2011

If you are going to be a leader within an organization, then you need to be able to clearly communicate a compelling vision. The communication part is relatively easy to practice, but the vision part is worth practicing too.

There are two primary mechanisms for team communication that we can practice easily: Speech and Writing. We can practice speech by participating in groups like Toastmasters. We can practice our writing by using tools for text analysis and review.

Both mechanisms have the benefit of providing very rapid feedback and the feedback can contain lots of fine-grained detail. These are two critical attributes of practice. The feedback needs to be almost immediate(the sooner the better) and the feedback needs to be very detailed and specific so that we can fine tune our performance in a meaningful fashion.

When it comes to vision, one reliable place to start is with a clear statement of the problem you want to tackle. Coming up the problems is the easy part: ask the customer, ask the team, ask the project stakeholders. If you get that far you should have a list as long as your arm. Here’s a pro tip: keep those customer problems at the top of the list. Coming up with that list of problems is an important skill that can be honed and refined. There are places that you can go to look for problems that may be hiding in plain sight: recent communications from customers, defects, impediments. Keeping an updated list would be great way to practice.

Now unless you are very lucky, most of your problems will be vaguely stated and unclear. One of the best things to help you clarify the problem is to actually see it and experience it for yourself. Go to where the problem is. In the lean world this is often referred to as “Going to the Gemba.” The Gemba is the place where the work gets done.

Seeing for yourself will give you the rapid, high quality feedback you need to assess the nature of the problem. You can use techniques like The 5 Why’s to help get at the underlying causes of a problem. Often times the refined problem statement that you end up with looks nothing like the problem statement that you started with. Now these techniques are great for refining the problem statement, but what we are really after here is a vision – the possible solutions to the problem.

Fortunately there are a wealth of different brainstorming strategies that you can use to help discover a set of possible solutions. Here’s one technique that I use (taken with some minor modifications from the wonderful book Thinkertoys by Michael Michalko):

  1. State the challenge
  2. List your assumptions
  3. Challenge your fundamental assumptions
  4. Reverse each assumption
  5. Record differing viewpoints that might be useful to you
  6. Ask yourself how to accomplish each reversal

What you end up with at the end of this exercise is a list of potential solutions to your problem. Pick one. Now all you need to do is to communicate it!

The thing that I really want to convey is that many of these techniques can and should be practiced. With practice we will improve our communication techniques and our problem solving techniques. Put the two together and you have the recipe for someone who can communicate a compelling vision.

What If the Problem Just Isn’t Yours to Solve?

April 18, 2010

I was listening to Ken Schwaber once and he was talking about someone who had a really hard problem. I mean wicked hard. As Ken put it, they racked their brains and sweat bullets, but they just couldn’t come up with an answer. He looked at us and asked, “So what do you do at that point?”

He paused, then continued, “Sometimes the problem may not be yours to solve. That’s when you take it to someone else.” Such a simple statement, but to me it was a revelation. You see I’m the kind of person who, when given a problem will attack it like a caffeinated pit bull on steroids. I give it everything I’ve got. Unfortunately, sometimes that’s not enough. That’s when you need to let go of your personal ownership of the problem and collaborate with someone else. That’s the part that was the epiphany for me. The letting go bit is hard for me. But we have to realize that we are not responsible for solving all of our problems by ourselves. There are problems that are best solved by a group. Problems that are best addressed by inspection from a variety of different perspectives.

Once I realized this, I was on my way. I just take the problem to the team, or the scrum of scrums, or my stakeholders. It’s OK to let them take a shot at it too. Who knows, they might see something that you don’t.

Piercing the Veil of Uncertainty

March 31, 2010

Sometimes when I talk to people about impediments, it feels as though the conversation gets pulled down into despair. It’s particularly acute with the “big” impediments – the ones that it seems we have no hope of solving. Sometimes the conversation dies right there.

But I’ve learned that it doesn’t have to.

There is a different set of moves that we can use in this dance. We start off exploring the boundaries of the the situation. How pervasive is the problem? how extensive is the damage? But we don’t stop there. We continue until we get that signal, that feeling in the pits of our stomaches that says, “I’m not sure we can fix this.” Then we switch gears (I’ve learned this is the hard part). We go into elaboration mode. We describe the problem in as detailed a fashion as possible – the very act of describing the problem helping to reduce uncertainty. We start to brainstorm all of the options that we have for dealing for that problem (or in many cases what is actually multiple problems). Now, not only are we looking at a problem, but we also have an array of solutions.

What if you have no idea how to solve the problem? Google it. If you can articulate an impediment, you can bet that someone has proposed a solution.

Finally, once you have a set of alternative solutions to the problem, pick your favorite and create an execution plan. Flesh it out in as much detail as you can. The more vivid you can make it, the more likely it is that you will be successful.

You see, if you use an approach like this, then for any given impediment, you have a strategy. By doing so you have eliminated a great deal of the uncertainty and have set yourself on the path to executing a solution – that is a much better place to be. Whatever you do, don’t stop half way.

Agile Teams Better Found Than Made?

December 22, 2009

I’ve been dabbling with the idea of swarming and how it might relate to team organization in software development for a couple of years now. There are some great resources out there that provide tantalizing hints toward how we might create self organizing teams that are capable of “swarming” and solving problems rapidly.  After a while I realized that I wanted to find a way to create one of these self-organizing teams using principles similar to those we find in nature. What would you do? How would you organize a team that you wanted to behave more like a swarm than a traditional top down entity?

Lately I’ve realized I may have gotten it all backwards. It may be impossible for one person to organize a self-organizing team. On the face of it, it’s an obvious contradiction in terms. You really can’t tell the team how to act and then say, “self organize guys!” (as we so often do in Scrum). So is it even possible to “make” a self organizing team? I think that a really good self organizing team is a much more subtle and elusive beast than that.

Maybe we need to take Peter Gloore’s approach and instead of trying create self-organizing teams, we should try to discover self organizing teams that already exist within our organizations?

Problem Solving 101

December 21, 2009

I have a confession to make: problem solving tools and techniques are probably the weakest part of my product development skill set. I don’t think I’m alone on that score. As I watch other teams work, I see them jumping to solutions without even entertaining the idea of understanding a problem well. It seems like a knee jerk response for many teams. It’s peculiar that it should be that way. After all, product development could be defined as nothing but a series of problems and challenges that stand between us and the successful delivery of a product. How we solve each problem has a direct impact on the eventual success of our products.

So when I stumbled across “Problem Solving 101: A Simple Book for Smart People“, by Ken Watanabe, I was looking for a guide that might help me remedy my problem solving deficiencies. There were a few things that attracted me to this book:

  1. It’s short – 111 pages
  2. It’s written for Japanese school children – If they can do it, then I just might have a chance too
  3. It has lots of pictures

Each of the problem solving tools that is introduced is illustrated by a story. This helped to keep my extremely short MTV attention span locked in just long enough to absorb a thing or two. That and I suppose I relate well to the problems typical of the average 12 year old. That’s my wife’s theory anyway.

Moving on, Watanabe outlines the framework for a problem solving process (p.14):

  1. Understand the situation
  2. Identify the root cause of the problem
  3. Develop an effective action plan
  4. Execute and modify, until the problem is solved

of course this reminds me of another 4 step problem solving cycle, the Shewhart Cycle:

  1. Plan
  2. Do
  3. Check
  4. Act

They’re not quite the same, but they both contain many of the same elements. The PDCA cycle is at the heart of lean continuous improvement or Kaizen. Some argue that PDCA is also built into some agile methodologies like Scrum, where in each iteration you Plan (sprint planning), Do (sprint), Check (retrospective), and Act (incorporate changes into the next sprint). So you could argue that the bones of a problem solving framework are built into some of these agile methodologies. However, I would contend that PDCA is not enough. It’s the problem solving toolbox that Watanabe describes where we get the real problem solving power. And the last time I checked, aside from some examples in lean development, you won’t find techniques like these anywhere else in agile development.

Watanabe introduces logic trees as a tool for problem analysis. They are a handy way for breaking down a problem into smaller pieces (slicing the elephant, so to speak) so that you can better identify the root causes of a problem. Then he introduces what he calls a “Problem Solving Design Plan” which is basically a matrix of the identified problems, and the proposed solutions and outcomes for each one. This tool is useful for really starting to think deeply about a problem. Understanding the problem well, creating a hypothesis, and proposing multiple solutions for a given problem are all part of the problem solving design plan.

Another strategy he describes is doing Gap analysis. I’ve heard of it before, but to be honest, I’d never really seen an example. Not in my PMP training, not in my Scrum training, I don’t even think I was introduced to this technique in college. Nope, I found this one in a book for Japanese grade school kids. Yikes!

Now, I don’t want to sound like the most clueless guy on the planet (too late!), but if a guy like me can go through primary, secondary, and college education without even the simplest problem solving skills under his belt, isn’t that a little alarming? I can solve a math problem just fine, but if it’s anything more abstract than that, I don’t know that many of us have a structured set of tools that we can use for problem solving. That’s where this book comes in handy.

I was part of a project recently where a solution was proposed to the team without even allowing any discussion of the underlying problem. It was probably one of the most dysfunctional meetings I have ever witnessed (and let me tell you, when it comes to bad meetings I put the “fun” in dysfunctional). The people proposing the solution were so defensive that they couldn’t tolerate the idea that they might have got it wrong. Of course, as things played out, the project was a complete failure. The inability to ask questions and examine the problem undermined the team’s morale and guaranteed that viable alternative solutions were never discussed.

Understanding the problem is part of what developer’s need to do. It’s what they’re supposed to be good at. Any attempt to stifle this impulse is almost guaranteed to end badly. Rather than do that, a good leader should be able to act as sherpa for the team, and help guide them through the analysis process. That means doing good root cause analysis, and being open to wide range of solutions. If you are one of those leaders, do yourself a favor and read “Problem Solving 101”.