Well, we mean all the practices and work-methods around assuring that BV is delivered to the customer. And the firm satisfies all its constraints (eg, good return to shareholders).
We think it is better to view this flow as an engineering process, that, like other engineering processes, is open and visible. And a subject for constant learning.
BV Engineering encompasses all the processes of telling the team what to do. And all the processes of delivering that and finding out “gee, did we really build the right thing?”
We of course view this is an Agile context, where so many things involved are subject to constant change and learning.
So, you see that part of the effort is to identify and test all the assumptions we are making. Part of the effort is to organize things in such a way that we can quickly identify what parts of the flow are failing (as they always to some degree will). Part of the effort is set up small scientific tests. Part of the effort is to learn faster. Part of the effort is to enhance just-in-time knowledge creation. Part of the effort is to harness change for our firm’s competitive advantage (gee, that sounds similar to something…oh, the Agile Principles).
Our bias is that most teams could benefit more by improving BV Engineering than by doing anything else. To the tune of increasing BV delivery by 3x within one year. (This of course does not keep you from also making other improvements.)
I will be talking about this more in a meeting in Atlanta. January 8th. See the Agile Atlanta yahoo group for more details. Or contact me if you have interest.