Getting Business Decisions Made – 2

Posted on March 31, 2007 by Joe Little

A few days ago I posted on this subject. This is a continuation of that post…

I had already discussed the first of Esther Derby’s 6 steps. (Again, I am trying to discuss something different from what she was going at, so naturally there will be differences.) For her 2nd step…

2. Determine what’s important to the person who makes the decision.
First. decide who you think the decision-maker should be. Try to arrange things so that the right decision-maker is involved, or the right group of people is involved. Often, hearing intangible benefits from multiple people will make the benefits more real to the decision-maker.

Second. One model is a single decision-maker and multiple advisors. Another model is a loosely defined decision-making team. Think through what the model really is in your situation.

Third. Consider what you think ought to be important as decision criteria. If what you think is important is not congruent with what the decision-makers think is important…consider a short or long campaign to influence their thinking. Say something like “I consider A, B, C, D, and E as the decision criteria, and I weight them as 10, 7, 3, 2, 1. What do you all think?” A campaign can be that simple.

3. Ask that person who they consider credible sources related to the issue.
Esther’s advice here relates to hard-to-measure benefits. At a higher level, you are asking: “What kind of information would it take to get you to approve my proposal?” Esther’s hypothesis (generally valid) is that absent conclusive hard data, most decision-makers will accept one or a group of “expert” opinions.

In her post, Esther describes multiple things that the decision-maker valued, so naturally (and normally) no one person could be an expert in all those areas. Thus, you need a set of experts’ opinions.

More generally, sometimes success is in finding a disparate set of information that, taken together, gives the decider confidence in making a reasonable decision. Maybe: (a) benefits, (b) risk reduction, plus (c) no better alternate course of action. Imagine how you would think making a chess move. Often business can be even more complex than chess in the number of factors that come into a decision.

Remember that you want the decider to feel you are helping her (or him). You want to checkmate the decision; pinning the decider might gain a different and more emotional reaction to your request than you are looking for.

4. Create a short interview protocol.
Again, Esther’s advice is appropriate for her case. A more general step is “figure out how you will collect the information”, whether by one method or five.

More general advice here is also not to make data collection too onerous. Ask the decider “if I collect this and that info, would that be enough to convince you? I don’t want to get into a bigger effort if something smaller would be enough.”

Often the decider will say “collect what you can in X days, and come back and show me what you have”. Some remember how hard it is to come up with good data.

5. Interview the people the decision maker identified as credible.
Here the general advice is…collect the information. If you haven’t done it already, make sure the information is credible to the decider. Or say “here is the info I have collected so far, this is what I feel the information says…but do you feel it is credible?” Be ready to receive input that is it not (yet sufficiently) credible. If you asked in the right tone, she won’t be thinking “well, I can’t trust the info he brings me anymore.”

6. Summarize and present the results.
Sometimes it seems you only get to present once to the decider. Maybe true for one decision. But as mentioned, I am proposing that you not worry about one decision. You are trying to influence for many decisions. And you are trying to learn “how does this manager make decisions? And in what ways can I influence her?”

Esther’s point is, of course, well-taken. Every time you present to the decider, think about the kind of presentation that appeals to her. Example: Is it summary first and then selected details? Or build and build details, and then look at the summary? (And lots of other variations of this.) Almost every decider wants a summary. Almost every person wants a summary that has no more than 3-5 bullets. And there are lots more aspects to “presentation” than this.

As a last suggestion. Each person has different kinds of information that they will find convincing. Decisions must be made even if the ideal data is not available. Sometimes a combination of harder data and softer data is convincing. Sometimes you only have 1 to 3 expert opinions. Sometimes you can get a decision if you say “Why don’t we try this as an experiment, and see if it works?”

Let me repeat a key point: Costs should never be looked at in isolation. Always consider the benefits and costs together. (And if you want to consider risks as something different, then the upside and downside risks as well.)

Where there is a will, there is a way. You can get more business decisions to go your way.

Carnival of the Agilists

Posted on March 28, 2007 by Joe Little

We are honored to have been selected for the Carnival of the Agilists, in the latest “issue”. See Pete Behrens’s blog and Agile Alliance for the other blog entries selected. Agile Alliance has all the previous Carnival selections.

“Carnival” I hope suggests the joyous creative side of Agile. And the variety of opinions that are voiced. For some of you, there may be an association with “too rowdy” or unbridled behavior (think of a Southern city that is also famous for a hurricane). Some people under the banner of Agile do things that provide a minor bit of support for that negative image, but, in my opinion, that is not what Agile is about at all.

Anyway, enjoy this selection of blog entries.

Getting Business Decisions Made – 1

Posted on March 23, 2007 by Joe Little

It is wonderful how we make decisions in life. And, in a certain way, it is even more wonderful how we make decisions at work.

I do not wish to digress too much, be perhaps the first subject is the illusion of power. For example, for perhaps most decisions in our business lives to be meaningful, they must be followed by others. This usually requires that the followers actually believe that the right decision was made. Or, at least the decisions are much more effective if the followers believe in them. To obtain that belief, it would help that the decider at least involve the “followers” in the decision process. But I digress.

Esther Derby recently wrote a blog entry on Estimating hard-to-measure benefits.
Her example is getting approval for a readiness review. An earlier example had been getting approval to do a face to face retrospective. I want to take what she wrote, and broaden the case. And talk about getting approval for most things, eg, for most things to do with the agile adoption at your company, or most things to do with the success of your project.

Let’s assume you are a project leader. Thus, like everyone really, you can either get approval up-front or ask for forgiveness later.

Esther suggests these steps for hard-to-measure benefits (not quite comparable to what I wish to discuss, but close enough for a start):
1. Identify the proposed course of action.
2. Determine what’s important to the person who makes the decision.
3. Ask that person who they consider credible sources related to the issue.
4. Create a short interview protocol.
5. Interview the people the decision maker identified as credible.
6. Summarize and present the results.

I want to comment on these in a somewhat different context over a couple of posts. In this post, I’ll only cover Esther’s first point.

1. Identify the proposed course of action.
First, I would suggest taking the attitude that you are not worried about one decision. You are trying to set up a string of small decisions that lead eventually to overall success (eg, perhaps for your project). You can lose a battle; you wish to win the war. And, you must respect the decisionmaker’s (or makers’) problems: no time, no data, confusion, the fog of war.

Second, early on, assess who is the right people (people) to be involved in the decision. You often have more influence over this than you might think. You get to pull them in.

Third, as an early case, bring to the decision-maker something that is close to a no-brainer. It is clearly something that ought to be done. Most decisions should really be easy. If it’s hard, there’s probably an easy opportunity out there you should be working on instead. Build up the decision-maker’s confidence in you…that you only propose good ideas.

Fourth, if the decision is more borderline, tell the decision-maker that. They often trust you more if they feel you are an honest broker.

Judgment Under Uncertainty

Posted on March 21, 2007 by Joe Little

Tom Peters’ blog has this post about Judgment under Uncertainty: Heuristics and Biases, by Daniel Kahneman, Paul Slovic, and Amos Tversky. They are psychologists. But Kahneman won the Nobel for Economics for prospect theory.

But the issue is making decisions in a world of uncertainty seems quite relevant to Agile. For the customer, for the business side, for the development team (including the Product Owner). Suffice to say that my bias is that people aren’t always as rational as we sometimes think they are.

People have the idea that (a) a collect all the data needed, (b) I analyze it, and (c) I make the right decision. Most business people know this is a senseless model, totally unrealistic. As the head of Google said, he wants to get more “at bats” than anyone else. (This comment makes sense if you understand that Ted Williams story about batting averages. Ted Williams holds the highest career batting average in the majors of anyone with >500 home runs. It is .344.)

Elements of Agile Style – 1

Posted on March 20, 2007 by Joe Little

I have written a short handbook, called The Elements of Agile Style. (Current draft available in PDF.)

What got into me?

Well, I had to do it. We need more reminders of the basic stylistic elements before we move forward to work in our own individual style. This is the way with any art. You write a sonnet. You play football. You learn a martial art. You dance. You cook. Establish a firm grasp of the basics and then move toward mastery.

All of these arts require the disciplined understanding of certain basic elements. It was recently March Madness time, so I’ll call these basics dribbling and shooting, and staying in front of the offensive player and covering the passing lanes. From mastery of these basics your own individual style starts to emerge.

Strunk & White’s The Elements of Style did a similar thing for writing. It set out some rules and guidelines and suggestions. It covered usage, composition, forms, and style.

Rules, Rules, Rules. This seems to be an area of some controversy. For some, Agile is a revolution against Waterfall, which had far far far far too many rules. And so, to them, any rules are anathema. Nonetheless, with admitted trepidation, I started with the “rules of Scrum”.

Why? Didn’t I know that every team must self-organize and set rules for itself? And that any externally imposed rules would likely ruin the team?

First, I guess I must confess my attitude toward rules. To me, rules were created by someone or some group long ago and far away. And I am here and now. I am in my current situation, and if the rules don’t obviously hinder me, I will likely go along with them, but otherwise I will break the rules in a second. I’m from New York. I’ll jaywalk. I’ll go the wrong way on a one-way street (if there’s no traffic).

Second, frankly, I have a lot of respect for the Team. I believe the Team wants some rules, if only to simplify life some. And I trust that the Team will use judgment about when to enforce a rule and when to let it slide. (Hint: On Wednesday, Sept 12, 2001, I would not be worrying too much about the length of the Daily Scrum.) If the Team can’t stand up against a mere book, and tell the book where to get off, they have much greater problems than a book can solve.

I will have further posts about the book later.

If you read it, I hope you find this little book useful. Your comments are welcome. Thanks.

Face To Face Still Matters

Posted on March 20, 2007 by Joe Little

Last Friday Esther Derby wrote a blog entry that struck a nerve.

Part of the reason I started this blog is because I see so many people worrying about costs without considering the benefits. Or the means without considering (enough about) the ends.

Esther’s entry is “Face to Face Still Matters“. And of course it does. Communication and learning take place fact-to-face at such a higher rate than over a phone or at even lower bandwidth.

Communication and learning are what we need more of to make the projects more successful.

So, people who want to consider distributed retrospectives (her particular concern) agree to save a few more costs and lose some big benefits.

Similarly, if we focus only on the cost side of Agile, or of projects more generally, we are short-changing ourselves and our customers. Almost always we (as business owners or customers) care more about the value delivered than the cost.

ACTION: Don’t ever let anyone talk about cost-savings without also talking about the effect on value delivery. (It is not necessary a linear or even a direct relationship, but it can be.)

Waste in projects…Working hard is not enough.

Posted on March 19, 2007 by Joe Little

The second big idea in Lean is waste. Or getting rid of waste (muda in Japanese). Seems obvious. Everyone in favor of waste, raise their hands….umm, no one.

First: Why do I want to talk about this? Many reasons; one today. I meet so many development team members who are so gung-ho, they want to impress everyone with how hard they are working. Working hard is nice, and a demonstration of good character. Up to a point. But working hard, by itself, can be wasteful. (Other issues with working hard…in another blog entry.)

[Note: My apologies to people experienced with Lean. I feel it is necessary to go over these basics first. If you wish to comment, with a more advanced insight, please do. Please be patient.]

There are many types of waste (to be discussed later). Let’s start with time as an example. In simple terms, (and it really means more than this implies) let’s look at waste being every extra second it takes from the time we start working on the product until the end customer gets satisfaction. Think of it first as “I’m an impatient customer, and I want to be satisfied now.” Lean attacks the time delay with a value stream map…and actions arising from that.

This is what Womack and Jones say:

Identify all the steps in the value stream for each product family, eliminating every step and every action and every practice that does not create value.

The value stream is the set of all the specific actions required to bring a specific product through the critical management tasks of any business: the problem-solving task running from concept through detailed design and engineering to production launch, the information management task running from order-taking through detailed scheduling to delivery, and the physical transformation task proceeding from raw materials to a finished product in the hands of the customer. Identifying the entire value stream for each product is the next step in lean thinking, a step which firms have rarely attempted but which almost always exposes enormous, indeed staggering, amounts of waste.

“Wait a minute”, you say, “how can I, smart as I am, be doing anything that does not add value?”

First, any time things are standing idle, it is waste.

Second, value is defined in the eye of the customer. So, of course you are always doing stuff that you or someone thinks is very very very important. But does the customer see it as adding value to him (or her)?

In Lean there are two types of waste: Type I muda is waste that is (currently) unavoidable. Government reporting might be an example of this. You don’t want to go to jail, so although it adds no value to the customer, you do the government report.

Type II muda is avoidable waste. Like wait time.

Note that muda is an ugly word (in Japanese). Lean uses it for that very reason. Waste is ugly.

Once most of the Type II muda has been eliminated step-by-step, then you go back and re-evaluate Type I muda. Isn’t some of that now avoidable? Can’t we talk to the government, etc?

We will also suggest that many things that once seemed important and useful are, under a careful eye, things that can be done with less effort or in a simpler way, thus avoiding much waste.

Using these ideas, we can use Pareto’s 80/20 rule, and ask: “Are we focused on the 20% of effort that will produce the 80% of value?” “Should we really be doing any or much of that 80% of things that only produces 20% of the value?”

Thinking about and talking about waste in this way typically raises many questions…we will start to talk about those in a few more posts. Comment below with your questions.

Next, we want to talk about another way to look at the types of waste. See the Poppendiecks for a preview. See the list of 7 types of waste on page 3 of this linked article.

** Joe Little

Customer Value & Lean

Posted on March 15, 2007 by Joe Little

To discuss Lean and Lean Software Development is a long task. Permit me to start slowly, with background, and to start with some digressions.

There has been a lot of talk lately of the auto business. What will happen to Chrysler. Is there something there we can learn. (Hint: Lean is being used outside the auto industry.)

Lean, as you know, is mostly closely associated with Toyota and two men: Taiichi Ohno and Shigeo Shingo. They of course were strongly influenced by Deming and Henry Ford. When asked a question, Mr. Ohno famously said, “Oh, I got it all from reading Today and Tomorrow by Henry Ford”. The story of the people and their courage and inter-relationships is interesting. I doubt that you can read too much by Ford or Deming. Or by Ohno or Shingo. (For myself, my grandfather was a GM man quite some years ago now.)

What has all of this to do with Agile & Business?

In my mind, the first principle of Lean is this: Value is defined in the eyes of the end customer. See Lean Principles at the LEI. This from Lean Thinking by Womack & Jones:

“The critical starting point for lean thinking is value. Value can only be defined by the ultimate customer. And it’s only meaningful when expressed in terms of a specific product (a good or a service, and often both at once), which meets the customer’s needs at a specific price at a specific time.”

In Lean Solutions, Womack and Jones speak for all of us (as customers) when they say we want our problems solved. We don’t want a product, we want our problem solved:

“Solve my problem completely.”
“Don’t waste my time.”
“Provide exactly what I want.”
“Deliver value exactly where I want it.”
“Supply value exactly when I want it.”
“Reduce the number of decisions I must make to solve my problems.”

And, if you are younger, you might add: “And give me something that is waayy cool to be involved with.”

When we are doing Agile, we are already trying to get close to the customers. To get frequent feedback from the customers. Even to collaborate with them. In Scrum, we have the Product Owner (and she with the whole team must be asking how well is she representing all the end customers).

The customers are changing fast. Are you working at it enough in your project today?

* * *

In the Agile Community, Mary and Tom Poppendieck are the ones most closely associated with Lean Software Development. See their site, here. I will be talking more about these Lean ideas in future posts.

Joe Little