Business Value Engineering framework

I am about to do another BV Engineering workshop. In Orlando, Feb 23-34.  Preceded (appropriately) by an Intermediate CSPO (Product Owner) course. Feb 21-22.  See: http://leanagiletraining.com/courses.html

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

First, what is the BVE framework?

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

Why do we need it?

Several reasons.  Here's one.

We find that many people have good ideas about Business Value and what the PO should do. But the "buyer" of these ideas have 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.  We believe the framework offers a way to prioritize the implementation of new ideas and approaches.

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.

What's in the framework?

Well, many things from a certain point of view, but here are some things I want to highlight today.

1. What is Business Value?  This is a 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 a yet 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. 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.

So, 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 course as experts after only 2 days, but we do intend to establish a framework for getting continuously better.

Why an Intermediate CSPO (Product Owner) course?

I am about to do an Intermediate Certified Scrum Product Owner course in Orlando.  Feb 21-22.  Followed by a Business Value Engineering workshop. Feb 23-24. See http://leanagiletraining.com/courses.html

In this post I wanted to talk about why the Intermediate CSPO is important and how it is different.

First, our finding is that the Team is important. Any focus too much on one role, or one role in isolation, is potentially leading people astray.  In a Team, every role plays with every other role. (Yes, we might do some work in isolation, but always for the use or benefit of others. So, the isolation is only temporary, and not very meaningful.)

So, I like all Product Owners to start with the CSM (Certified ScrumMaster) course. And ideally to take this with the rest of the Team.

And then to play Scrum for some time.  So, the PO starts to have real questions from the real world.

Second, I think for almost all teams, the biggest impediment is that the PO is not good enough.

This is not because we don't ask good people to play the PO role. Usually we do.  Sometimes excellent people.  It is because no one is a trained and experienced (eg, for 5 years) Product Owner.  At first.  So, very good people appear weak because they lack training and coaching and experience.

So, I find that the best thing is to take POs with a CSM and some experience, or no CSM and a fair amount of experience, and send them to an Intermediate CSPO course.

The course actually covers most of the same topics. But from the point of view of an experienced person.

For example, we review basics.  In this course not to explain them the first time, but to check for real world understanding. And to correct the mistakes that beginners in any sport always always always make.  The bad habits, we might say.  The Scrum-But that they have started to do.

Third, we try to build the aspiring Product Owners into stronger Product Owners.  I have just suggested my key point-of-view: That becoming the Tom Brady (the Quarterback of the New England Patriots for those in Rio Linda) of Product Owners is a journey that takes years.  So, when we say aspiring, we do not mean that they come to the course with no accomplishments, but rather that whatever they have done, they aspire to be better.

A lot of the basic things we talk about are also discussed by other trainers. And on the website above.

What are some key ideas that we talk about that others (usually) do not?
* minimizing work in progress
* maximizing learning
* ordering the product backlog to optimize BV delivered over some period of time
* focusing on the gold, platinum and diamonds, and ignoring the silver, copper and dirt (Pareto)
* sizzling steak and killing babies (the psychology of an earlier release)
* a brief intro to the BV Engineering framework (approach)
* no Technical Debt (is a PO issue too!) (Well, zero is a very low number, but that's the direction.)

An Intro to BV Engineering: the paper

I have written the 2.1 version of a paper that introduces the concepts around Business Value Engineering.

See: http://agileconsortium.pbworks.com/w/page/50231393/BV%20Engineering%20Paper

I would very much appreciate your feedback on this paper. Here or to my email address.

Thanks!