Getting Business Decisions Made - 2

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

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

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.

More in the next post.

Judgment Under Uncertainty

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.)

More on this later.

You might also wish to look up Kahneman and Tversky.

Elements of Agile Style - 1

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

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.

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

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

Follow-up to : Much Ado About Animals

There has been a bunch of discussion about the chicken and pig story in the scrumdev yahoo group lately. And my friend, Mike Vizdos, uses the chicken and pig metaphor a lot on his site: Implementing Scrum. That's a link to the latest cartoon.

Reminder: Metaphor alert, as described in my previous post on this subject.

At about the same time, my wife bought 4 steel sculptures, 2 of chickens and 2 of pigs. For no known reason (she knows very little about SCrum and I had not mentioned the chicken and pig sory to her). Since I think of the chicken and pig story is a great Aesop fable for children, let me show you the baby chicken and the baby pig first.

Here's the baby pig. I love the authentic rust.
And the screw used for the nose (look closely). Wouldn't you want to be a pig? (Oh, yes, that's right, it's just a story about committed vs. involved. You don't have to be a real pig.)


Now, here's the sculpture of the baby chick.
What do you observe? Seems to want to dominate the little pig (must be a conspiracy there). Seems a bit of an air-head. And, again, rust becomes her (my artistic impression is that this chick is female...apologies to those who disagree). And I don't know what's up with that tail feather.

Was I talking about a real chicken? Was I talking about a real person? No, in both cases. I was talking about a real thing, that picture of a sculpture you see above.

Here's to always inspecting and adapting based on as-close-to-the-real-thing-as-we-can-get.

To increase the level of fun, let me quote from Mark Twain's Huckleberry Finn:

"PERSONS attempting to find a motive in this narrative will be prosecuted; persons attempting to find a moral in it will be banished; persons attempting to find a plot in it will be shot.
BY ORDER OF THE AUTHOR,
Per G.G., Chief of Ordnance."
Perhaps he protested too much. You be the judge.

Please tell me if this story or these pictures are amusing to you. They say that education and entertainment have been entwined for thousands of years.

Explaining Agile to your brother-in-law

Lately I have been trying to explain Agile to friends and family. To my wife, to my mother, to my brother-in-law, to business people who have never heard of Agile. Let's assume it is their first conversation using Agile with a capital A.

Where does one start? What must one say?

Response to a problem
Lean-Agile is a response to a business problem. Or really a set of problems.

The basic elements or needs are these:

• faster delivery of business value (or at least incremental delivery)
• deal with the human, team issues (communications, motivation, etc.)
• respond better to change
• set up better collaboration between the business and IT
• improve the working situation for the delivery team (key element: sustainable pace)
• release more team creativity to deal with harder problems

Waterfall (with all its flavors) and regular project management are proposed as solutions (in fairness, their main advocates were not attacking this exact problem set), but have not gotten the job done. Agile is an alternative solution.

When to apply?
So, when should Agile be used? My answer now is any time you have a small team situation (7 plus/minus 2). Or, if you have a larger effort, just scale it up with multiple teams working together. And the team and the people around the team are willing to try Agile.

So, Lean-Agile is for IT projects and for business projects. And for work efforts that people don't call projects.

What are the benefits?
The benefits can be stated many ways, but usually amount to these things:

• Faster time to market
• More business value delivered per period
• More accurate delivery of business value (the customer gets what they really need)
• More transparency for the business (the business can see where their investment is going, and how they can help remove impediments)
• More satisfied customers and shareholders
• More satisfied workers

My general rule of thumb is that in 2 years a team should be 4x as productive as before Agile.

What's the catch?
None really.

There is no guarantee that every agile team will succeed. If a team will fail, you learn that early, which is a good thing . If a team fails on a project, usually this will be because that team (or perhaps any team) is not capable of doing the work given them in the project well enough. The good news is that Agile will make visible that mismatch, and the project can be re-staffed or canceled.

Becoming really good at Agile takes time. It requires a mental and emotional commitment to persevere. You will get some benefits immediately, and sadly too many people who come to Agile think that's all there is. They don't fight beyond the complacency of that first plateau.

Agile is a bigger mindshift than most people think. For example, it asks that people become comfortable with a high degree of visibility. This is hard, sometimes. We are human, and we often are uncomfortable revealing our imperfections.

So, what is agile really?
Presumably the problems or the benefits have grabbed you. So you have read this far.

To this point we have given one explanation of why Agile was created and why you should be interested, but we have not explained what it is. Or have we?

Jim Highsmith has said "Agile is a way of thinking, not a particular practice." While this is quite true and important, it is not a satisfying answer to those who ask, "Well, how would I know Agile if I saw it?"

Here, I think, one falls back to a few things:

1. List the flavors of Agile (if they might recognize any)
2. Mention the fours parts of the Agile Manifesto
3. List a few things, as I am about to do

The flavors of Agile are of course not usually satisfactory, since this group often won't know any of them. The Agile Manifesto is wonderful, but usually too abstract for this group. And too oppositional to Waterfall (which this group also often does not know).

So, here's my list. With Agile you...

• focus on delivering small slices of concrete business value frequently (1-4 weeks)
• work with a small team of people, to enable them to be as productive as possible
• use concrete, understandable results to allow all parties to adapt and move forward
• arrange things so that change and learning are benefits
• tell the truth, and make the important things as visible as possible
• minimize waste and extra effort; maximize customer value, don't impress with hard work

Some comments. This is a definition that I hope most ordinary people can grasp. It allows for software and business kinds of projects. While it has some reflections of the Agile Manifesto and Agile Principles, it tries to seem (at least) more concrete and less theoretical. Which I think this audience needs.

This is the least unsatisfactory response I have come up with so far. What do you suggest?

Thanks, Joe

Should business people care about engineering practices?

I facilitated an Open Space event at APLN-Richmond last night. (Open Space is great. Recommended.) Steve led a session that started with the idea: Scrum is inadequate when it comes to requirements gathering. What should we do?

My first response to him (offline) was that Scrum does not try to directly address requirements gathering (not my favorite phrase for that area of work), nor indeed any of the engineering practices. Scrum allows the team, in its situation, to use the engineering practices that are available, that they know best, and that fit best. Scrum most definitely does say: start with good engineering practices and improve them.

But first, is this topic appropriate for an Agile Business blog?

Should business people care?
My answer: Yes. Definitely...Yes.

Why?

To me Agile is about collaboration. We want an intermixing of the Business people and the Technical people. In fact, it would be ideal if every person were both a business person and a technical person.

More specifically, Agile in a way mixes up the work in such a way that all the larger engineering practices must be done together, as a collaboration that includes business and technical skills. I am thinking business value-story-testing-coding here (with Test Driven Development).

And even if some engineering practices are done solely by technical people, they are done in the open, and immediately the business people care.

If the engineering practices can be improved, the business people will see the benefits immediately. If I were a business person on a project, I would care whether the team has constantly improved its the engineering practices. The work will go faster, the quality will be better.

For some, though, this will seem counter-intuitive. To them, all engineering practices belong to the technical people only. That's how the word is defined for them. Business people don't do "engineering".

Of course, this is consistent with the waterfall-like notion that "I gave you the basic idea, now go off and do it. And don't bother me until you're done". Do doubt many of you have heard one or another version of that.

We have found that that approach doesn't work. Or not very well. Many reasons; perhaps the leading, irreducible reason being that there is too much change happening.

It also turns out that engineering practices, for a team, are somewhat different that civil engineering (which my niece does). Software is work done by and with people. Yes, some machines and technology are involved, but the real action is with the people. And almost magical. So, it is engineering where the main creative tools are....people. Umm? (So, are people skills engineering practices? And what are people skills anyway? If I study 'em, can I get a certificate in that?)

The two bits of magic
To me, building products has two main bits of magic. You start with the business value idea, and somehow that must get into code. This communication or transformation must somehow happen. As if by magic. All else is Type II muda (necessary waste).

The second bit of magic is taking working code and surrounding it with all the things necessary to release the business value. Since the release of business value itself (eg, delivery of customer satisfaction) is really key, perhaps it is better to say, "placing the code in a complete environment where it can help release business value."

Those engineering practices are part and parcel of making this magic happen.

Who must do what now?
In an earlier post I suggested that the techies must learn about business value, and understand a lot more about it. Now I have said that the business guys have to learn about software engineering.

But the responsibilities are greater than that. The biz dudes need to explain business value in a way that the geeks can understand. And the IT professionals must explain engineering practices to the suits without looking down their noses, like they were talking to a person who doesn't know what a kilobit is. Neither one is a dark art.

A final reason to care
You should care if you care about the delivery of business value, and about the success of the project.

Much Ado About Animals...or, Animals & the missed metaphor

I have been having or listening to several conversations lately about animals.

In Scrum, we have the idea that the ScrumMaster has some characteristics of a sheepdog. Some of us also talk about chickens and pigs. Mike Vizdos uses that metaphor a lot on his site (http://www.implementingscrum.com/).

As it would happen, my wife, knowing nothing about all this, went out and bought four steel sculptures: a large pig, a baby pig, a large chicken (perhaps a rooster), and a chick (I guess). I will post pictures soon.

Surely this all is not without meaning.

It seems that everyone has been reading Aesop lately. And we're taking our Aesop quite seriously. And perhaps we should.

On using metaphors. Usually metaphors rise from the subconscious to communicate. They make ideas concrete. But my metaphor may not be yours. Just as your attempt at humor may not make me laugh, or make me laugh today. If my metaphor doesn't get through to you, I'll try to say it a different way.

Please don't overuse my metaphors. Only with permission can you extend them. They only come out to play for a brief time, partly because so many want to extend them too much, which makes them brittle and almost useless.

The sheep dog metaphor
Some people are concerned about the woof woof that is sometimes used at the end of the Certified ScrumMaster course. The woof woof is of course alluding to the sheepdog characteristics of a SM. And what can be wrong with protecting the Team?

Well, some people feel that the woofing is like a secret society. Or it seems, in their cultural context, silly and demeaning. (I did not have this reaction, so perhaps I do not do it justice. Nonetheless, I am sympathetic with those who don't "get it" about the woofing.) They feel that the woof starts to create an Us vs. Them feeling.

To me the woof woof is mostly comical, and I fear we can easily get overly involved with a whimsical thing and miss the more important issue.

To me there is a much more useful tension in the idea/feeling of Us vs. Them. A key issue and a key dilemma.

Let me unravel it a bit, as the thread goes through my mind, and then you all join in. So, let me start by saying why I think Us vs. Them is not useful. And then by explaining why it is useful, necessary and inevitable.

Why not useful. To me, to explain this we start with the idea that we are all God's children. (You humanists might prefer "we are all human, with certain unalienable rights".) However much we travel in the dark, we all can come back to the light at any moment. It is not useful to demonize. It is not useful to put people in "bad" categories. (Those who can't woof, those who don't get the woof. Those who woof; those that think the woof is good.) While some actions may indeed be bad, telling a person they are bad usually does not help them stop doing the bad stuff and start doing more good stuff. Why create an enemy before you've met the person?

As an example, I call myself a recovering waterfallic. By which I mean to imply that I have compassion for all who only part get agile, since I myself know that I relapse from time to time from the best ideas in agile. Notice that I don't call others recovering waterfallics, although my guess is that I have talked to quite a few recovering waterfallics, in de Nile and elsewhere.

Most of us are of a mixed nature. Putting the bad out there (in some one else) keeps us from seeing the bad within.

Why useful. Isn't this obvious also? It is so humanly natural to form up in teams. It is embedded in our genes that we must know "our" people and distinguish them from those "other" people. It is also so comforting to identify our enemies within the agile movement. Helps us form our own identify and find friends ("the enemy of my enemy is my friend"). Comforting, and oh so human.

Our language is rife with all kinds of dualities. Light/dark, up/down, good/bad. Ad infinitum. And they are necessary. We often need those simple binary choices so we can move on quickly. If we had to really think about everything, we'd be in quite a pickle. Clearly there are people who don't get agile. We each can identify types of people who are, on average, pretty unlikely to get agile very quickly. Our brain takes a couple of impressions and naturally starts making categories.

And there are indeed instances where a person has hurt the team. We have to identify those persons sooner or later, and do something about it.

The Resolution of Romance (Wynton Marsalis)
If I had a simple resolution to this continuing dilemma, for this tension, I'd be a wiser man than I am. I don't even have a complex resolution. We must have Us vs. Them. We can never have Us vs. Them. Ummm?

Seems to me just recognizing that we have this dilemma is a start. So, let's have chickens and pigs. Let's have a sheepdog to keep the wolves away. But remember, these are Aesop stories for children. We humans are often a tad more complex. And, as Ken Schwaber said, the important thing is that we do more thinking for ourselves, about what our current project situation really is. At least from time to time.

Let's also remember that from our enemies, even in this discussion, we can always learn something. One of my favorite blessings is "May you be blessed with good enemies."

+ Joe Little

What is Business Value? Part 1

I have noticed a bunch of projects lately (mine and those of other people) where the business value is not so clear.

As Yogi Berra said, "If you don't know where you're going, you might not get there."

But what is Business Value? I mean, what is it really?

First, I like the definition of Lean. Value is defined by the end customer. Value becomes meaningful when talking about a specific product that meets a customer’s needs at a specific price at a specific time. (See here: http://www.lean.org/WhatsLean/Principles.cfm#specify)

End customer. So, all the rest of us are just making guesses at what the customer wants. Remarkably, sometimes we are right. And the next sentence is also important. There has to be a context. In fact, I believe the context is much larger and harder to define than this. We buy things based on a conscious or unconscious comparison to all the other things we might buy or do or not do.

For example, when I go to Starbucks for a decaf coffee (don't ask; no, I hardly ever buy a latte), I am implicitly comparing to all the other cool things I could do, places with social scenes, drinks I might have, other bars or coffee houses I have gone to lately.

My main point is business value is complex. And it changes. The customers are changing and my understanding of the customers is hopefully improving along the way. Indeed, I should organize things so that I can experiment with new products, to find out if my hypotheses about the customers were correct. (Yes, Virginia, even end customers can't always explain to you what they really want. Accurately.)

So, with agile project management, we are learning about what the project is and how to do the project and who the team really is. At that same time, the business lead is learning "what really is the business value here".

"As you from crimes would pardon’d be,
Let your indulgence set me free"
- Shakespeare, The Tempest
The business lead must accept the Team is learning, and they must accept that the business lead is learning.

Now, the fact that we are learning does not mean we start with totally sloppy thinking or no thinking. We need to make a relatively quick first estimate (hey, it might even be accurate enough). And then test that. I would not suggest starting a project just on the hunch of a "business lead" who has no track record of successful hunches.

A couple of suggestions:

• Demand to understand the business value of your project (be reasonable in how you put this)
• Talk about it (anyone might have a contribution)
• Talk about it some more; see if everyone is motivated by the business value as articulated so far
• Develop an approach together to getting more confirmation that the business value of your project is really there (Hint: incremental releases might be part of that approach.)

We have some more things to say about business value, and then we will talk about the relationship between a SW project and a process.

+ Joe Little