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 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.  We believe the 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.

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!

Committing for the Sprint

This is, to me, still a New Year.  And a friend suggested I talk about New Years' resolutions.  Or something like them, Sprint commitments.

Henry Ford said: Whether you think you can or you can't, you are usually right.

So, let us work backwards.

To me, in most business situations, the main thing is satisfying the customer. Helping the customers solve their problem(s).

This is very hard because:
* the customer does not understand his or her problem well
* the customer cannot articulate the problem well
* the customer typically does not understand the technology capabilities that might be brought to bear in the solution, and what their strengths and weaknesses might be
* we (technologists) don't hear very well (we are human, after all)
* we tend to want to build what is cool to us
* our companies tend to be overly involved with existing products ('to a man with a hammer, everything looks like a nail')
* and several other reasons...

Still, satisfaction is what we are after.  Unless silly lawyers and such get in the way.

Typically what we have to build to assist with gaining satisfaction takes several sprints. (The length of time depends on many factors, but first the general domain and what one might call the maturity of the product line or its current technological complexity.)  Most products take more than 1 sprint. Some take 2-4, some take 20-25+.  Although most are in-between, I find.  At least for the first (next) release.

So, how do we climb the mountain?  Well, one step at a time, of course.  And because we know it is hard and fraught with many misunderstandings, we try enable more and more feedback.

So, we have Sprints and Sprint demos. Among other things.  And by going slowly (eg, by taking the time to optimize negative feedback early) we can go fast (deliver the product the customer really wants sooner).

Within Sprints we have 'stories' or Product Backlog Items -- small pieces of functionality or features. Now, a customer never really wants the individual pieces (well, ok, many with a few rare exceptions). The customer wants what we like to call the Minimum Marketable Feature Set -- that set of features that helps him or her (partly) solve a problem.

So, we do have to focus and enable feedback at a detailed level.  But the point is not the detailed level, but rather customer satisfaction with the production release (ie, that's what the software people call the final product).

***
Is it worthwhile to have a Sprint goal?  Yes, absolutely, although it is possible for it to become more important (to some people) than it should be.  But the  Sprint Goal does tend to give a common goal for all the Team. so the team tends to work together better.  And the Sprint Goal tends to diminish the possible myopia of too much focus on individual stories, being "lost in the weeds" as they say.

Now, should the Team commit?

This has recently become a controversial question.  Let me explain. In the new Scrum Guide from Schwaber and Sutherland, they have eliminated the word 'commit.'  They are rightly concerned, I think, that some managers are forcing Teams to fulfill commitments under 'innovation' conditions. And they say, and I agree, that in innovation conditions (which is what most of us should be working in), forcing people fulfill every Sprint commitment is silly.  Just too many variables in our business, too many unknowns and unknowables.  Forcing overtime or punishing people because our work is uncertain just does not help.

Still, after the Sprint Backlog is done, the Team still should commit to that plan. They should start believing that they can do it (I say '9 times out of 10').  Not that they always *will* do it.  But, today (the beginning of the Sprint) with what we know today, we feel this is reasonable and can be done.  It is nothing like a fantasy plan, that could never happen.  That's the way I have explained 'commitment' for years and how I continue to explain commitment.  A commitment in our business can never be a 'guarantee.' 

Managers may not ask (ok, should not ask) a team to work overtime to fulfill a commitment. This is silly and unproductive. (A discussion for a later blog post.)

Now, the biggest problem I find is that Team's over-commit. And then disappoint everyone, including themselves.  This must stop. Promise what you really have a good chance of delivering. If you have extra time at the end of a Sprint, take on an extra story. But do not pretend to be able to do more than you can reasonably do.  'Stretch goals' do not help. (again, a topic for another post).

So, what should the Sprint Goal be.  Well, something that brings the Team together, and that represents the main focus of the Team for that Sprint. Typically, a one sentence version of the top 5 stories out of the 8 'commited' for the Sprint -- something like that. So that when we learn, and maybe things need to be adjusted, we might modify stories, but we are less likely to modify the Sprint Goal.

Are managers evil?

First, many have said that there are a lot of bad managers in the US, and in the world.

Peter Drucker worked on this.
W. Edwards Deming had his ideas, and worked on this.

And many many business gurus have had their say, trying to improve the managers.

On the other hand, there is in the agile community a bunch of people who feel that managers are evil.

OK, maybe that is an exaggeration, most of them do not think all managers are evil.  But in general, they feel that most managers are evil.

We think that virtually all managers are not evil.

Equally, it is less than useless to think of the workers as bad or lazy. Or evil.

But let us stay with the managers today.

Yes, there are many managers who do not manage well. And some may even manage in a negative or bad way.  But I think the main reason is that they have been badly taught.  No one has taught them or they were wrongly taught. Or they have wrongly learned.  For example, that it is useful to be a command-and-control manager. And we have tempted them with ego rewards, and many have succumbed.

There is, for some of them, and for some of "us", the notion that no one can correct a manager. At least no one who reports to that manager.  This also is an un-helpful notion.

So, to replace this notion, we offer a few suggestions:
* managing people is very hard, and probably requires different skills depending on the situation and the people involved
* hierarchy and power are probably not that helpful. At least in most situations where you have knowledge workers.
* with knowledge work, knowledge creation and motivation are quite important. Perhaps yet another reason to look for a different kind of manager than we used to have.
* we speak of leadership, and some say that we need no managers, only leaders. Certainly leaders who lead us in the right direction and do it well are rare.  And we need more of them; more Steve Jobs we might say.  But I think we still need managers.

We are in the process of changing the management culture throughout the world. This will be a long conversation. There are so many dimensions. We need to talk and fight and argue about how to manage better. And, if we over-simplify things into managers and workers, the workers are very much part of this fight.

But calling one side 'evil' is not helpful.

Product Owner & the Team

Is the product owner a member of the team?  Yes. Fully and completely.

What is the biggest problem that most teams face? That, at the high level (value) or the low level (details), they don't understand what the customer wants well enough.  

And who is mainly responsible for managing the flow of this 'business information' into the Team?  The PO of course.

And this is a never-ending job. For example, at the lowest level imaginable, as they complete each step of work, he should be giving feedback: "well, that was not quite what I meant", meaning really "I don't think it is quite what the customer will want."

The feeding of the team, this feedback to the team of Devs (meaning, in overly simple terms, creators and testers) is essential.  And must be done daily.

When we start with a past tradition of thinking and working, there are many obstacles to this 'union' or yoking of the PO with the Devs. One is that the Devs wonder "what is that guy doing hanging around here?"  Another is that the PO feels kind of weird around all these geeks and their geek-talk.

But both sides need and will eventually learn how to live and work with each other.  It takes time.

Only together, as a full team, can they win.