Business Value Communication

In March I did a short workshop on Business Value Engineering at ScrumGathering in Orlando. Very interesting to me, although it was mainly about the work that the attendees did.

As I commented to them, it certainly was not about what I said. It was not even about what they learned in the session. It is about what they will do. Later.

What did I learn? Well, there is always so much more to learn about this subject.

One thing that became obvious to me is the importance of BV communication.

One of the main reasons to do Business Value Engineering is so that "everyone" can talk about it. So, it needs to be a set of words and ideas that everyone finds interesting, fairly simple, and compelling. Everyone starts to talk the same language. I find this currently very rarely.

Just to talk about it enough so that the basics feel, well, basic and well-understood.

I guess it is useful now to talk about the larger purposes of communication, at least in this context.

So, let's put this in the context of Scrum and talk about the following people:
* Product Owner
* ScrumMaster
* Implementers
* Stakeholders (to the PO, in this case; typically people in the business side of the company)
* Managers (too broad, but we'll leave it at that for now)
* Customers

And of course we can have other groups of people also.

Now, let's restrict this further for now, and say we want a common understanding for this effort (say, next 2-3 releases for a given product) of what Business Value means (and, implicitly, how we will measure it).

So, what are the benefits of communication in this restricted context?

Well, my quick answer includes the following:

• getting everyone on one page
• getting several hands on the elephant, to help discover more fully the true nature of BV for this effort
  
• affecting concrete team actions; eg, what each implementor does
• reduce conflicts amongst stakeholders (since they can see clearly where the greatest BV is and isn't)
  
• minimize the PO as a single point of failure
• by becoming clearer in expression, we become better able to identify flaws in concepts and theories
• as suggested earlier, once we clearly and more concretely conceive of business value, we can then work harder on measuring it (which is typically hard)
• motivating the team

Do any of these need further explanation?
Aren't all of these fairly obviously compelling?

To clarify the bullet point about metrics, let me use words that my 6Sigma friends like to use. They say it is fine to have a general definition of a metrics, but then one must have also an 'operational' definition that allows one to actually measure. Some people need the wordy definition, some people do better seeing exactly how you will measure it.

These are some benefits; no doubt others to add and better ways to express them.

Your thoughts?

Business Value Engineering Workshop

At the ScrumGathering, Tues (tomorrow) I will do a mini workshop on Business Value Engineering. At 1:30pm.

Here are the slides: http://bit.ly/cXmYaI

Most of the slide deck is for reference; only a few of the slides will be used in the workshop. The mini workshop is about 2 exercises.
#1 Define at your table Business Value.
#2 Articulate your BV Engineering approach. (Map, BV Model, Theories, Timeboxes/Feedback loops)

I hope in this way that people will start to see this framework can be used. And also used to look at all the other great ideas about business value that others are discussing. Each of those must be put in the context of an overall framework. This BV framework hopes to be that general context.

BV Engineering is a framework, kind of like Scrum and kind of like Lean. So, as in Lean, we ask that people make explicit the BV "cycle" and approach, much as Value Stream mapping does.

I hope you will find these ideas and practices useful.

What is Business Value Engineering?

I made a post in AgileBusiness (yahoo group). That I thought I would repeat here:

QUOTE
I have been asked to start a conversation about BV Engineering. So, here's a
start...

What is it?

It is a framework for looking at the delivery of business value. It is called BV Engineering for two reasons. First, instead of hand-waving, we believe that BV Engineering should include qantitative measures (although not be dominated by metrics), and, second, it is called that so that it is approached like other engineering practices in Scrum, as something that is not prescribed, except to say one must always have them, identify them, and improve them. And BV Engineering becomes one of those engineering practices.

Where do we start?

We start with a grossly simplistic franework that says: we have
* a box of customers (external and internal typically),
* a box of Business (customer facing people, internal groups like legal and compliance, and perhaps others), and
* a Team (eg, the Scrum team that will produce or improve one product for those customers).

We also start with an assumption that BV Engineering is a round-trip set of experiments that are continuously trying to prove whether our hypotheses related to BV Engineering are useful. Or, more accurately, it is a feedback loop that continuously shows us how far off our hypotheses are. (And since stuff is happening all the time, we are always at least somewhat off.)

And what do we do next?

Next, based on that simple framework, one does a simple drawing, as with Value Stream Mapping, and describes what BV Engineering is in your specific context.

The flow between all the people is diagrammed. The assumptions and hypotheses are described. The business value model is described. We lay out the current state.

Why?

So that, being visible, we can all see it, and make suggestions, little tests, for improving it. Constantly. That is, so we can continuously move toward a future state.

So, what kinds of things are you including?

Well, anything that helps or hinders us from delivering stellar business value to our customers instantly, at a lower price, solving exactly their problem (or fulfilling their need) with no adverse side-effects. And fulfills all our constraints (eg, a good return to capital, etc, etc).

The approach also works if you make the simplifying assumption that "we only want to make money". As Drucker would say, not the correct basis for doing business, but one that some adhere to.

Back to the things. These things include, or might include: communication (who, what, how, when, etc), gathering requirements, the BV model and its assumptions, frequency of release, feedback from the release, how much we do the telephone game, who needs to understand the customer, the role of tacit and explicit knowledge (about what?), how and where we do knowledge creation, how we balance customer needs with legal/regulatory needs, how we do portfolio management, how we start and kill efforts, the Kano model, prioritizing across multiple customers (or customer sets), priority poker, value stream mapping, personas, use cases, etc, etc, etc.

For example, the use of any one of these things has one or more assumptions tied to it. One hypothesis is that these assumptions have often never been articulated, much less challenged, and even less have they been confirmed as accurate for our specific situation.

Two more observations, each fundamental. As soon as one sees this as a feedback loop (or PDCA cycle) that is trying to prove whether our theories and practices are on target, one immediately asks about the frequency of feedback. And almost always it is not fast enough (GM anyone?). And, second, one then looks at this not as a static model, but as a dynamic model that is always adapting to change. So, one asks "how are we building into our BV Engineering appropriate mechanisms for it to be continuously adjusting in a useful way?"

Lastly, let me add a "personal bias" (which I find empirically true), namely:
virtually every team member needs to understand how we do BV Engineering in our specific situation, and where they fit in on the process.

Well, that's a start.
Comments or questions?
UNQUOTE

Your comments, here or on AgileBusiness, would be welcome.

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.

Business Value Engineering

BV Engineering? What is that?

Well, we mean all the practices and work-methods around assuring that BV is delivered to the customer. And the firm satisfies all its constraints (eg, good return to shareholders).

We think it is better to view this flow as an engineering process, that, like other engineering processes, is open and visible. And a subject for constant learning.

BV Engineering encompasses all the processes of telling the team what to do. And all the processes of delivering that and finding out "gee, did we really build the right thing?"

We of course view this is an Agile context, where so many things involved are subject to constant change and learning.

So, you see that part of the effort is to identify and test all the assumptions we are making. Part of the effort is to organize things in such a way that we can quickly identify what parts of the flow are failing (as they always to some degree will). Part of the effort is set up small scientific tests. Part of the effort is to learn faster. Part of the effort is to enhance just-in-time knowledge creation. Part of the effort is to harness change for our firm's competitive advantage (gee, that sounds similar to something...oh, the Agile Principles).

Our bias is that most teams could benefit more by improving BV Engineering than by doing anything else. To the tune of increasing BV delivery by 3x within one year. (This of course does not keep you from also making other improvements.)

I will be talking about this more in a meeting in Atlanta. January 8th. See the Agile Atlanta yahoo group for more details. Or contact me if you have interest.