When I was a kid, back in the twilight between the late 70’s and early 80’s, a bunch of us neighborhood younglings used to meet up after dinnertime at a small field to play together. Not a lot of planning needed, a couple of us would just agree to meet and then the word spread. One of us brought a soccerball and someone else brought a tennis ball and a bat for rounders. Most of us knew each other to some degree but every now and then a new kid had moved in or someone would bring a friend from outside. We were usually about 5-15 kids and we used to decide there and then on what to do; soccer, rounders, hide and seek or some other game. If we decided on soccer a couple of us would take our sweaters off and then we used them as goal posts. Someone would volunteer to be goalie or we’d decide to take turns. And then we played until our parents called us in for bedtime.

Last night I got to experience something similar once again. My good friend Daniel called a couple of days ago asking if I wanted to come along for night caching with him and some other guys. I like geocaching but for me it’s mostly about getting to be outdoors with the kids every now and then whereas Daniel and the other guys have made this hobby into an artform and a gadget sport.

Night caching

Anyway, we met up after dinnertime, but this time it was initiated by an email and then someone called someone else and someone brought a friend and we finally ended up being seven men in the rough range of 35-50 years old. Some of us knew some others quite well, other’s had met briefly and for me this was a totally new crowd except for Daniel. But we had one common goal; to follow three reflective trails in the woods and solve puzzles along the way that noone had managed to solve before us. We would do this in order to find a fourth trail and the final prize; the FTF (being the First To Find the cache).

Armed with head lamps, UV-light, cameras, pens, paper, GPS’s, smartphones and some candy we set off into the rainy darkness to find the solution to this riddle somewhere in a forest west of Stockholm.

Since everyone else were a lot more experienced than me in this area, I decided to observe and learn about this type of geocaching more than I would contribute to the solution. I did learn a lot about night caching but the self-organization and the self-steering that I got to observe and be a part of was beyond what I could have imagined.

The level of problem solving and cooperation needed to succeed was definitely comparable to building quite a complex piece of software (though more limited in size and time). Without anyone being appointed manager of this group, everyone quickly found roles to fill where they could contribute to the team. Not a lot of words where spoken regarding what to do, it just happened. A couple of the guys took the lead and started looking for the next reflective marker, a couple of us walked in the middle marking the ones we had found and a couple of guys followed after looking for clues that could help us solve the puzzle. Someone called out an idea, someone else went online to look for information. Someone tried out an idea, someone else was already working on the next hypothesis. Not a minute was wasted, and in what I would say was the shortest timeframe possible, without hurrying, we solved the puzzle piece by piece. Reiterating pieces of the puzzle where the first idea didn’t pan out but never getting too far astray since we were quick to put our ideas into practice.

Three hours later, after being the first people ever to sign the log, the seven of us could pat each other on the backs and go back to our cars and drive home to our families for a good night’s sleep.

When we were kids, we were united by the common goal of having some fun between dinner and bedtime. Last night we were united by the common goal of being the first ones to solve a complex problem. In both cases we succeeded very well with our missions, we had fun doing it, noone needed to manage us and we all found ways to be useful.

Do you remember what this felt like when you were a kid? That feeling of being creative, contributing to the game and not wanting to go home when your parents came for you. Do you want to experience it again? We should all be able to have that same feeling that kids have between dinner and bedtime. Every day. From 9 to 5.

I wrote in my previous post about the Scrum team I’m working in as a ScrumMaster and that we’re closing in on our first release to production. At this stage a lot of the work is related to getting production environments up and running and our user stories have taken on a more technical format and are formed more by the team than the Product Owner. Our PO had a story asking for a production environment but that one was way too fuzzy for the team to take in so they had to break it into smaller stories/technical tasks. A lot of this work was done on the fly during the planning session and we needed to find defintions of done for the stories as they were forming.

The task of finding good definitions of done proved to be harder than anticipated for these stories. After a while I realized that what we were specifying tended to be more of a list of tasks than acceptance criteria. So we backed up the value chain by asking “Why” we wanted to do something and started arriving at better definitions of done. However, the crown jewel was when we were discussing the job of getting outsourced operations to monitor our application. What was the definition of done here? Putting the order for monitoring services in the mail? Getting a reply to our order? Having a signed contract? We weren’t really getting anywhere until all of a sudden one of the team members spoke up:

“I want to turn off one of our services and when I see operations dancing a jig on our doorstep, that’s when we’re done.”

I damn near got a tear in my eye hearing this suggestion. This is the kind of thinking that we need when we measure things. Whether it’s a level of service, quality or productivity we want to measure we always need to begin by looking at what we want to accomplish. We can’t demo usability by showing a pretty UI, we need to put a user in front of the UI to demo usability. We can’t demo quality in number of bugs found, we must demo quality in a fit for use product that is stable under usage and over time. And if we want to demo our ability to handle problems, we can’t do that by waving a contract. We demonstrate our ability to handle problems by handling a problem.

This episode reminded me of a story an aquiantance told me ten years ago about his neighbor. The neighbor had a burglar alarm connected to a security company. The security company promised in their service to arrive at the house within 20 minutes of an alarm. Twice every year this neighbor set the alarm off. He then pulled out a lawn chair, put on ear protections and sat down with a timer in his hand and when the security company arrived after half an hour or fortyfive minutes, he filed a complaint and got the service for free for another six months. This guy knew what the definition of done was; he also waited for operations to dance a jig on his doorstep.

If you want to measure or demo some qualitative aspect, don’t settle for the easy way out and try to quantify it. Put it to the ultimate test, that is the only way you’ll ever know for sure that you’ve done something right.

A couple of days ago, as I was grabbing my bag out of the overhead compartment on the quite small plane I had taken between Newark and Raleigh/Durham, I noticed a sticker in the back of the compartment. Most planes I have flown with were bigger and I’m just not tall enough to see that far in so I don’t know if the sticker is always there but in this plane it was at least. The picture I managed to take is quite blurry but what it says is: “MAX. CAPACITY 60 LBS/27 KG”.

Great, they don’t want the compartment to fall down on the head of some poor schmuck sitting under it.

I don’t know what’s wrong with me but I immediately wondered why they put that sticker there. What is the difference between having that sticker and not having that sticker?

Let’s pretend you’re a passenger and you are the first one to put something in the overhead compartment and you actually manage to see the sticker. What goes through your mind? Probably nothing much. Most of us have a bag that weighs less than 10kg but that doesn’t really matter because we don’t know what it weighs anyway. So you put your bag up there. Next person comes along. If she can still se the sticker after you’ve put your bag in there, what will she think? Probably that her bag is lighter than the limit. She has no idea how much your bag weighs and she most certainly won’t take it out and try to estimate the combined weight so she puts her bag in there as well. If there’s still any room up there, no one will see the sticker because of the bags and jackets already there and they’ll keep loading their bags.

Let’s pretend that the airplane manufacturer put the sticker there because they were concerned for the safety of the passengers. Jerry Weinberg uses the expression that you should eat your own dog food, meaning that you should try your own products for yourself before exposing them to your customers. If the manufacturer had actually tried to board the plane and recorded how the sticker changed their behavior they would probably have come up with zero.

But what if the sticker wasn’t even the manufacturer’s idea. What if it is some government agency that is looking out for us, the passengers? Did they make a rule that says that the manufacturer must make sure that no one gets an overhead compartment in their head? Did they express it in such a way that no one will get an overhead compartment in their head? They might have said that the manufacturer is liable for informing the passengers about the maximum load. But they certainly did not say that the manufacturer is liable for making sure no one gets hurt. Because if they did, that sticker would not have been there.

Now I don’t know who decided that there should be a sticker there and for whom it was made and
Therefore, I send to know
for whom the sticker was made,
it wasn’t for me.

Enough of paraphrasing John Donne and back to the game. If the purpose of the sticker truly is to save people from getting an overhead compartment in the head and not just a way of keeping the manufacturer out of court when someone has been hurt, then I consider it to be an example of poor problem solving and I’m more interested in good problem solving so I’m asking you, dear reader:

What would you have done to prevent people from overloading the overhead compartment?

Making Decisions Tentative

October 14, 2011

Decisions, sometimes hard to make, but we do need to make them and we do need to live the consequences of them. Some decisions can be changed along the way and some are irreversible but almost all of them are made without full knowledge about the problem. Waiting for full knowledge would leave us stuck in limbo though, because we will never gain it.

When we make a decision, no matter if it’s irreversible or not, we should not make it final. We need to leave a backdoor open for learning to enter. Making a decision final is when we invest so much prestige into it that we’ll stick by it even when we know better, or when we refuse to accept better knowledge even to ourselves.

We need to keep making our decisions and to keep standing by them as the best we could do at the moment, but we should make them tentative in the sense that we’re willing to learn and admit that we’d do it differently the next time around when we’ve gained new insights.

Problem – the perceived difference between a current state and a desired state.

In my last post I discussed assumptions as a good starting point when looking for initial causes in a root cause analysis. Today, I will look at one more practical way of finding these hidden assumptions. I will make an assumption myself here and that is that you are already familiar with basic root cause analysis and know what an Ishikawa (or fishbone) diagram is. If my assumption is wrong you can find some good basics at Wikipedia before continuing.

I find that using brainstorming techniques such as working with Ishikawa diagrams in order to find starting points for causes, have a hard time bringing out unspoken assumptions and prerequisites. Usually the brainstorming is done first and then the results are mapped to the categories in the fishbone diagram or the brainstorming is done with respect to each category, but if we instead start by asking questions that combine the different categories in our Ishikawa diagram, we can find several of the failed assumptions. This can be done as a complement to what is normally done and should not be seen as an either or.

Let’s say we’re working with the 4, 6 or 8 M’s (Machine, Method, Material, Man Power, Measurement, Management etc). Try to combine the categories in questions that are relevant to your situation, e.g.:

  • What training will our Man Power need in order to understand our Method?
  • What limitations do we have on our Material considering the Machines we’re using?
  • What support will Management need in order to make good Measurements?
  • When will we need our Material if we’re going to follow the new Method?
  • What is required from Management for our Man Power to get the Machines or tools they need?

Doing this we might come up with a list of prerequisites or assumptions that were never made explicit at the outset:

  • If we assumed that everyone on the project was familiar with some basic technology, compare this assumption to reality.
  • If we assumed that our target audience belonged to a certain demographic group, compare this to our true audience.
  • If we assumed that people in adjoining departments would communicate with each other, check if this actually happened.
  • If we assumed that our instructions would be read by everyone, check if everyone actually read the instructions.
  • If we assumed that everyone knew where to find the background documents, see if everyone actually knows how to find them.
  • If we assumed that a new hire would be brought up to speed by the team within two months, check if that was the case.

If any of our key assumptions or prerequisites turn out to be false, investigate their impact on the process and problem statement and continue the root cause analysis from there.

As I mentioned in my previous post; validating assumptions is something that should be done all the time and preferably at the beginning of a new project or endeavor of some kind. Using the technique described above does not have to be limited to root cause analysis when the problem is already a fact. Perform this exercise or whatever works for you at the outset  of any new project, change program or other activity where you’ll be working according to a new process.

Problemthe perceived difference between the current state and a desired state.

At times when we find ourselves in the need of performing a root cause analysis (RCA) we have usually ended up at a current state that differs significantly from our desired state. When we embarked on the endeavor of trying to reach our desired state, we probably had a plan or process that we expected would help us get there. Now, most of us design our processes very carefully but we also often implement them on top of a number of loosely made assumptions that are more error prone than anything else in our process.

Depending on our selection of method for RCA we might or might not have the tools for looking at our new process in order to find flaws in it. My suggestion is that you select a method that will help you analyze your process, but that is not what this post is supposed to be about. What I find most methods for root cause analysis seem to lack, is a way to look at the assumptions that we base our process on.

Every problem solving approach that I’ve come across so far has followed a similar pattern of:

  1. Identify problem
  2. Find cause
  3. Find and implement solution
  4. Check result

There are methods for problem solving and RCA that are a lot more refined and give the user good help on how to move between the different steps but the “find cause”-step is often left to more ad hoc techniques such as brainstorming. I think most methods miss out on one good starting point when looking for the causes; our assumptions.

The old saying that assumption is the mother of all f…ups holds true quite often. Validating assumptions should always be done, but if you missed doing this validation earlier, at least do it during the root cause analysis. You will stand a good chance of finding some problem causes in this group.

I want to suggest an approach where our assumptions are made explicit and are compared to history and facts as a first step to identify possible causes. After a problem statement has been properly identified and expressed, try to list any key assumptions or prerequisites that would have been necessary to hold true in order for your process to be valid and for you to reach your desired state. These assumptions might have looked more or less obvious at the outset and thus taken for granted, but that is not the same as them being true. Compare these assumptions to history for fulfillment to see if we actually had everything in place in order for our process to work.

If any of our key assumptions or prerequisites turn out to be false, investigate their impact on the process and problem statement and continue the root cause analysis from there. Remember that these are probably only immediate causes and not our system causes.

In part 2, we’ll look at one way of bringing these assumptions out into the light.

%d bloggers like this: