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.