Assumptions – A Bridge Across Why – Part 2

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.

Assumptions – A Bridge Across Why – Part 1

Problem – the 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.

No 1 Stakeholders Don’t Need Requirements

In every project I’ve been a part of, we’ve been working against requirements. Now I think this is regrettable, because what we should be doing is to satisfy needs. The reason for building a system is that some stakeholder has a need and thinks that we can fulfill the need through software. There are requirements as well, but these should never be our main driver.

• Our first-line stakeholder needs to be able to retrieve data at a later point in time. Someone else imposes the requirement that all persistence should be done with Oracle products.
• Our first-line stakeholder needs an intuitive user interface. Someone else imposes the requirement that the user interface must follow some predefined design guidelines.
• Our first-line stakeholder needs a fast system. An integrated system requires that our solution responds within 5 milliseconds.

Requirements are the restrictions that other stakeholders impose on the system that we are building. Needs are “what’s” while requirements are “how’s”. We will have to satisfy different levels of stakeholders but the raison d’etre for our application is always the need of a first-line stakeholder. If the same person also has requirements, i.e thoughts on how we should solve the problem, we need to acknowledge that the person is wearing more than one hat and take this into consideration when prioritizing our backlog. A requirement should never trump the need that it relates to.

If we let the “how’s” take precedence over the “what’s”, we will build the wrong system.

Sucker Punch To My Agile Ego

I just attended Gojko Adzic’s course “From user stories to acceptance tests” where we began the course with an exercise of making a release plan for a “Black Jack” gambling site. Gojko acted as the customer asking for the development project. Three teams with four persons in each team set off to create release plans based on a sheet with the rules for the game. We were slicing the functionality in the most excellent and innovative ways. The time pressure was there so there wasn’t much time to consider our options but all of us were seasoned in the software industry so we managed to do quite well anyway. We proudly presented our plans to Gojko one team at a time. Each plan very well-formed. Then he dropped the bomb on us:

“How do you know that this is what I want? How do you know that this is what I need right now?”.

Ehhh … hmm …  huh?

None of us had stopped for a second to ask the customer about what he wanted or needed.

Working as an agile coach I keep telling my clients that they must communicate with each other. They must never assume anything and they must never draw conclusions based on assumptions. I tell them that whenever your mind goes “I think that …”, they must lift the phone and ask the other person to make sure they have understood the situation correctly.

As soon as Gojko had dropped the bomb upon us my mind started going through all my decisions along the way. I started to rationalize every choice I had made along the way. And they were all excellent. I had made foolproof choices all the time and could defend each and every one of them. But they were all based on one fatal mistake; I hadn’t asked the customer. I had built the greatest castle ever … on top of a quagmire. I noticed how everyone else were rationalizing their behaviour, some out loud. During the time pressure we had all defaulted back to the setting where we thought we knew enough without communicating with the customer and now we were defaulting back to the behaviour of defending our actions.

I think I probably missed about half of what Gojko said during the rest of the day because I was beating myself up. How could I walk into this trap? Because it was a trap, no doubt about that. A very cleverly set trap. But still, I should not be the person walking into that trap. Me, the agile coach, who works every day with helping other people avoiding this trap walked straight into it when I got under pressure. The very same pressure that my clients live with every day, and that’s why they walk into this trap. It’s not because people are dumb or evil or not agile enough that they do this, it’s because we are human. I knew this all along but I still somehow thought that this wouldn’t apply to me. It does. It applies to all of us.

The trick here is not to try to become machines that don’t react to pressure or any other circumstances in a human way. The trick is to recognize the situation that we are in and to understand what this type of situation does to us.