In March I did a short workshop on Business Value Engineering at the ScrumGathering in Orlando. Very interesting to me, although it was mainly about the work that the attendees did.
As I commented to them, it certainly was not about what I said. It was not even about what they learned in the session. It is about what they will do. Later.
What did I learn? Well, there is always so much more to learn about this subject.
One thing that became obvious to me is the importance of BV communication.
One of the main reasons to do Business Value Engineering is so that “everyone” can talk about it. So, ‘business value’ needs to become a set of words and ideas that everyone finds interesting, fairly simple, and compelling. Everyone starts to talk the same language. I find this very rarely.
Just to talk about ‘business value’ enough so that the basics feel, well, basic and well-understood.
I guess it is useful now to talk about the larger purposes of communication, at least in this context.
So, let’s put this in the context of Scrum and talk about the following people:
* Product Owner
* Stakeholders (to the PO, in this case; typically people in the business side of the company)
* Managers (too broad, but we’ll leave it at that for now)
And of course we can have other groups of people also.
Now, let’s restrict this further for now, and say we want a common understanding for this effort (say, next 2-3 releases for a given product) of what Business Value means (and, implicitly, how we will measure it).
So, what are the benefits of communication in this restricted context?
Well, my quick answer includes the following:
- getting everyone on one page
- getting several hands on the elephant, to help discover more fully the true nature of the elephant – of BV for this effort
- affecting concrete team actions; eg, what each implementer does
- reduce conflicts amongst stakeholders (since they can see more clearly where the greatest BV is and isn’t)
- minimize the PO as a single point of failure
- by becoming clearer in expression, we become better able to identify flaws in concepts and theories
- as suggested earlier, once we clearly and more concretely conceive of business value, we can then work harder on measuring it (which is typically hard)
- motivating the team
Do any of these need further explanation?
Aren’t all of these fairly obviously compelling?
To clarify the bullet point about metrics, let me use words that my 6Sigma friends like to use. They say it is fine to have a general definition of a metric, but then one must have also an ‘operational’ definition that allows one to actually measure. Some people need the wordy definition, some people do better seeing exactly how you will measure it.
These are some benefits; no doubt others to add and better ways to express them.