Business Value Engineering framework

In this post I wanted to explain the workshop from a different angle that I have done before.

First, what is the BVE framework?

Scrum is a framework.  Not a full methodology, but a framework. Similarly, BVE is a framework for improving the delivery of business value. And, we think, a nice adjunct to Scrum.  Maybe not appropriate for every situation, but a simple set of tools and ideas to enable you and your colleagues to drive higher and higher delivery of Business Value.

Why do we need it?

Several reasons.  Here’s one.

We find that many people have good specific ideas about Business Value and what the PO should do. But the “buyer” of these ideas has no framework to use to analyze whether this tool, or that idea, or that paradigm is the most important thing for that buyer to add now.  The BV framework offers a way to prioritize the implementation of new ideas and approaches. To prioritize and act on improvements.

We also find that if people don’t have a basic set of ideas and a “process,” then “things don’t happen.”  So, here are some basic ideas and a very basic process to start the improvement happening.  (Yes, too much process can also make ‘thing not happen.’)

What’s in the framework?

Well, many things, but here are some things I want to highlight today.

1. What is Business Value?  This is based on the notion that the practical definition of BV must be done case-by-case. For and with humans.

2. P-D-C-A.  We must have a Plan-Do-Check-Act kind of approach to improving. Iterative, incremental, cyclic. And with metrics.

3. Mapping. We steal the Lean idea of Value Stream Mapping, and propose an even more basic approach for BV.  At least make the process (or lack of process) visible. Only then can you improve it, bit by bit.

4. Visible Hypotheses. Make the underlying (implicit) hypotheses by which your group does BVE visible. Articulate them. Usually there are about 20 key ideas or assumptions. And once you make them visible, everyone starts laughing at, at least, a few of them.

5. Fix-Measure.  To some extent I am repeating part of the PDCA.  Once you identify the biggest problem, try to fix it or improve it, and then measure. And then determine whether the fix is any better. (We also have a healthy skepticism of metrics.)

6. End-to-End.  Ideally we should examine and improve the whole end-to-end process. (Always hard to say when things start and end, but in general, we tend to go broader.)  We don’t want to over-optimize one part, to find that we have sub-optimized the end-to-end.

We talk about these ideas in the Workshop.
But mostly we start doing exercises to implement these ideas.
We learn by doing.

To be fair, Business Value is a hard and complex subject.  We do not expect people to come out of the workshop as experts after only 2 days, but we do intend to establish a framework for getting continuously better.