Business Value Communication

In March I did a short workshop on business value engineering at the 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.  Feedback is a key word.  Learning is another key word.  Seven heads are better than one…another key related idea.

One of the main reasons to do business value engineering is so that everyone can talk about it more effectively.  So, “business value” needs to become a set of words and ideas that everyone finds interesting, fairly simple and compelling. Everyone starts to talk the same language.

I find only very rarely has an organization achieved this yet.  So, we hope the course will help. To be fair, it takes some work.

First, just to talk about business value enough so that the basics feel … 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:

1. Product Owner
2. ScrumMaster
3. Implementers
4. Business Stakeholders (to the PO, in this case; typically people on the business side of the company)
5. Managers (too broad, but we’ll leave it at that for now)
6. 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 to 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 the elephant — of BV for this effort
• affecting concrete team actions — ex: what each implementer does
• reduce conflicts among stakeholders (since they can see and agree more 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 metric, 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 of the benefits; no doubt others to add and better ways to express them.

Your comments are welcome.

 

 

« « Business Value Engineering Workshop || Value from the Scrum Course » »