Business Value Engineering - 3 questions

I want to slightly change my definition of BV Engineering (see earlier post).

It is the values, principles and practices that we use to help us continuously improve the Business Value we deliver.

Some questions and answers:

Q. "Business Value". Ok. Always good. Why add the word "engineering"?

A. Scrum says you must always improve your engineering practices. I think the most important set of engineering practices (typically) are around BV (business value).

Also, engineering implies that metrics and rigor are involved. This is important as an attitude. I see too much hand waving and vague ideas.

Q. What is the relationship of BV Engineering to Scrum?

A. Umm. To me BV Engineering is best done in the context of Scrum, but Scrum is not required.
And, you would think that Lean and Scrum implied or would foster a whole set of approaches to BV in software development, but in practice, this does not seem to be the case.

To me, it is fundamental that a Team is producing the Business Value (whether using Scrum or some other approach).

Q. What is the first thing to do in BV Engineering?

A. In my opinion, the first thing to do is "draw a clear picture" of what BV Engineering means for your team (area) currently. This typically makes more concrete and specific three shapes: the box of Customers (external and internal), the box of Business (the customer facing groups and the internal groups that, for example, have some input about features), and the circle of the team. Then diagram how the BV practices actually work together as you flow between and through these shapes. And then describe the values and principles, theories, models, and assumptions behind the BV practices.

One makes this specific to your situation. Not in infinite detail, but with some flesh on the bones.

The purpose of this simplistic "picture" of your BV Engineering is to enable the Team and the right people to identify where the biggest improvements can be made.

More later.

How honest should you be in Scrum?

First answer: Completely.

Ah, if only the answer were that simple. Sorry, George, but Scrum and Agile provide no cookbook answer to this question.

Some people use "honesty" to mean they get a right to be brutal to others (and also to ignore their own imperfections).

Much more often, the de facto thinking is "honesty means I won't say anything obviously incorrect and I will speak up more than I did before." (Well, I don't want to hurt anyone's feelings. And I didn't say much before anyway.)

So, for most people, the operational answer is: Be a LOT more honest than you were before. Both with good news and with bad. And even about yourself.

It turns out that once there is trust on the team, this is not so hard.

Still, like most things: Easy for me to talk about here. Always challenging for a team to do at the highest level in the real world.

Identify your multiple! WHAT?!?!

Let's discuss the last post, from the skeptic's point of view.

Simon (the implementor) 1: "OK, I don't want to get fired. But what this "multiple" got to do with it?"

The multiple is the relationship between the cost of the team and the NPV (net present value) of the benefits the Team delivers. As in: "If I invest $1 million in this team over a year, I expect them to (and they usually do) deliver about $3 million in NPV from that work." If you have been doing any investing in the stock market lately, you will appreciate that that is a powerful statement.

Simon 2: "Great. You're asking me to get something I don't understand. And I know we don't have it around here. Thanks for nothing."

Well, if you are an implementor, you have no real need to understand NPV in detail. How it is calculated. You're right about that. Product Owners (or business sponsors) should do that. But you can appreciate that some BV must be delivered, othewise the firm would not invest in the team (or at least should not). ie, You don't have a job.

You think no one has NPV around your shop? Three comments:
1. Yes, this is all too common. And incompetent. (Did I say that nicely enough?) [more on this below]
2. They might have it and not tell you. At least the initial estimate used to justify approval of the project.
3. To me, it is also incompetent management not to inform the team, at some level and frequency, how much BV they are delivering. (more on this below)

So, go ask your Product Owner: "Show me the money. Now." If she can't show you money, she must at least have something.

Simon 3: "I went and asked the PO. And she said it was too hard to estimate. She said: "It's a very important project, trust me." Too much risk involved. Kinda made sense to me."

Well, at some point you must say: "If these guys manage this badly, I should go work for a better managed firm." But maybe not this week.

Yes, doing our work as professionals is hard. Estimating BV is hard. And predicting the future is difficult. Developing software is difficult too. But of course, that should not stop us from doing what is important.

People also make it seem harder than it is by demanding too much precision. All we need is a decent number, with a reasonable bell curve of probable values, and we have enough to make decent business decisions. (Simon says: "Ok, yeah, I remember that bell curve stuff from that stats course in college.")

So, who knows how to convert risk into dollars. Let's see...umm, I just got a bill from my auto insurance company. Oh yeah, they use "actuarial science" to establish premiums (price/value) for risk. So your firm could hire one of those guys.

Simon 4: "I went back to the PO and she said we have no actuaries around here now. So we're stuck. Your idea is a non-starter for us. And thanks for making me feel bad too."

Wait a minute. Let's try another approach.

Can we get about 5 key senior managers who understand the business side of your industry? And also the business side of your effort (project/product)?

Ask them to play a kind of wide-band delphi. They discuss the assumptions and facts around the project (or set of Product Backlog items) to guess at the total BV. Then each independently guesses (eg, writes a number on a hidden sheet of paper). Then they all show at once. If the two extremes are disparate, then the two people who voted the extremes talk about assumptions. And maybe the team asks more questions to get the info for a better estimate. Maybe they vote again (and maybe another round). At some point you declare "we have enough consensus", and average the numbers given.

In case this "team" may be biased (or someone will complain loudly that they are), I suggest you or the PO have them take the number and explain it to a more senior manager. If it passes his "sniff test", then it is good enough for business decision making.

Simon 4: "Yeah. Tried that. They wouldn't bite. Are you wasting my time yet?"

Ok. This happens. Usually I am not happy with it. Sometimes it makes some sense.

So, we have another approach.

Ask the delphi team what the maximum is they would pay for it (that feature set or "the project"). Go through some reasonable consensus building. Then take the numbers and average them. Now you have a number. It may need "rounding up", given that most people want to make a profit on investments. And this number is the max cost, not the max value.

Simon 5: "OK. That sounds reasonable. But what if they don't bite for that?"

At some point you must persuade them. Or leave. Or wait to be fired (worst option).

Explain to them all the ways that not having a decent estimate of BV known by the Team is hurting them. Often this will work.

For example, telling the Team the Business Value will almost always change their behavior. It will affect their motivation. It will get them thinking about what is most valuable to the customers (or various end users) and to the firm. Your best implementors typically don't do their best work until they see the challenge.

Simon 6: : "I will try. But what if they don't do it?"

Again, if they are really incompetent, you should leave. Alternately, show them why BV is important to you. Make a personal case.

BTW, incompetence can be very easy to fix (or very hard). Some people, with just a little training, can become competent. So, we don't mean these folks are evil, or mean harm, or are completely stupid. Probably no one, yet, has made them see how doing things a different way would be better.

Simon 7: "Wait a minute. That remark could apply to me. Are you insulting me?"

Well, the usual case is....we all could be more competent at our jobs. It is more useful to think of this as...not a problem, but an opportunity.

Simon 8: "OK. Let's imagine they give us an estimate of BV. How do I know they didn't just pick it out of [bleep bleep]? I mean, you know what these [bleep] are like!"

Simon, come on. This is the public airways. Please.

Still, very good question. Make them get real numbers that show, after-the-release, whether the estimate was decent or not.

Usually the estimate will be somewhat wrong (high or low). Tease them a little, but don't make them chicken to guess (uh, estimate) the next time. As you know, stuff happens between the time you estimate and the time the software goes live. And insist that they learn how to do it better (and maybe more frequently).

By learning about this, we each can have more successful work. More satisfied customers. This makes for more successful firms. Pretty soon, we might have the economy back on track. And then my neighbor will have a job again, and quit talking to me endlessly about ACC basketball.

This Bus Value stuff is not as much fun as watching somebody make a fool of themselves on American Idol. But it might be more important. To you.

ACTION: Go identify your multiple. Now.

Two posts ago, I buried a key idea in a lengthy list.

Here's the gist. When the managers come around trying to figure out who to "re-engineer", would it be helpful to be able to say, "Guys, the firm invested in our team about $1 million last year...and got about $2 million back NPV"...might that allow you to relax if you could say that? (NPV means Net Present Value...your Product Owner should know this stuff.)

By multiple, I mean the relationship between NPV and cost. Usually the multiple is between 3 and 20 (or should be).

OK. Action item. For today. Go talk to your Product Owner and estimate the NPV of your last project as a team or your current set of work (say, next 2 releases). Annualize it (managers think more easily in those round numbers).

Much better if the NPV estimate is based on actual results rather than someone's dream of what the benefits "ought" to be.

Yes, there are lots of issues. Yes, life is difficult to measure. Get the best approximation you can.

Example: "We have a risk project. How can you measure NPV for risk?" Umm, who is really good at putting a price on risk? Auto insurance anyone? Go talk to an actuary and let 'em help you figure it out.

Yes, there are lots of problems with these numbers. Heck, there are lots of problems with helmets in the NFL, but I would not recommend playing without one.

Contradictions

I have been noticing the contradictions in Agile and Scrum lately.

Jeff Sutherland recently did a post about persuasion. The the latest post might be summarized as: "To persuade you must be confident and humble." Oh, sorry, I guess no contradictions there. But he does talk about contradictions elsewhere.

And this quote has been bouncing inside my head for several weeks, and wants out:
"The test of a first-rate intelligence is the ability to hold two opposed ideas in mind at the same time and still retain the ability to function." F. Scott Fitzgerald

We are decisive. We delay decisions ("hey, looks pretty indecisive to me, dude").
One contradiction that I am talking about a lot now revolves around this saying: "Velocity. Don't leave home without it."

We use the known velocity to push back on "magical-thinking" managers who want us to "just do twice as much" in the same amount of time. At the same time, we (the team) use velocity to challenge ourselves to triple our velocity. Like Michael Phelps, we are never satisfied with the record we set yesterday. And by doing many small experiments, we can triple.

I do not need to refer to Hegel's Dialetics, nor to Taoism to help me understand that: "Male and female he created them." There is something in our jeans that tells us opposites attract. Only by seeing the "yes, and" will we create something wonderful. Together.

On a slightly different note: please look at Takeuchi's article in the Harvard Business Review, 06/2008, entitled: "The Contradictions that Drive Toyota's Success." (I didn't add the pun. Honest.)

So, if you notice some contradictions, maybe they are there for a purpose.