Thursday, October 13, 2011

One reason for "Business Value Engineering"

I said recently that "business value engineering" is the place we can improve the most.  By which I mean:
(a) identifying the small features that the customer will want the most (once they get them), and
(b) identifying the MMFS (minimum marketable feature set).

Perhaps we should also add to this:
(c) identifying a "business model" that is reasonably attractive to customers and successful for the firm.

By this we mean, all the pricing and servicing and delivery things we put around the product.  If these don't work, the "product" per se may be wonderful, but it will fail.

We need to at least briefly mention the time dimension. For most products, the customer explicitly or intuitively realizes that he is entering into a long-term relationship with you. (At least with all the new products that I deal with.)  So, you must also have something like a "product life cycle" approach that is reasonable.  If you want to succeed longer-term.

I think that improving velocity (as defined by story points) is important (as suggested by recent posts), and important in many ways.  But I think improving business value engineering is, virtually always, the path to more success quicker, for the team.

Almost always, the biggest impediment for a Scrum team is a weak Product Owner (who is responsible for business value engineering).  Usually the person per se is very strong (smart, articulate, etc), but largely untrained and ill-equipped to be a fairly good product owner. Much less an excellent one.

When I talk about business value engineering, I always want to talk about the full end-to-end "process".

I think many people have many wonderful ideas about how to improve things.

But, I find that...
(a) no one can implement all of these proposed improvements at one time (usually it would take years to fully implement them)
(b) some of the proposed improvements are contradictory, or at least don't work well together with certain other things
(c) for a given company in a given industry, given their own current "processes," Improvement A is often much more useful than Improvement B.  While, for another company, Improvement B is more important.

So, as with Lean Value Stream Mapping, one of the key reasons to do a business value engineering map (with hypotheses and assumptions) is to identify the priority of the improvements.

Prioritizing the improvements is very important.
I'd rather make a little progress each month than "lots and lots" of progress that is supposed to arrive in 3 years.


Unknown said...

So, BPR applied to Agile Development, right?

If so, my only question is why haven't software development folks been doing this all along, Agile or not.

Joe Little said...

Hi Scott,

When I used to do Business Process Re-engineering, back oh 10-15 years ago, it was different than what I am talking about. But, yes, similar.

By BVE, I am talking about the process dimension, yes, but also all the other dimensions, such as hypotheses and other stuff that go along with it. So, it is more about the results of the process (did we deliver more BV than we expected?, did we hit Time To Market like the customers wanted?, did we out-innovate the competition?), and not so much the efficiency of the process per se (eg, how many fewer person-hours to get all the steps done).

Your point is well-taken. If this is a good idea, it is not tied to Agile. We should have been doing it all along, eg, when doing a home-grown methods, or those versions of water-fall or RUP or whatever. And I think some actually did to a degree. But god, I never saw it well-implemented and rigorously followed.

Also, with BVE I am NOT talking about Agile Development, eg, what happens within a Scrum team. I am talking about the stuff that comes before and after "agile development" or Scrum or whatever.