Value from the Scrum course

I wanted to reiterate views I have expressed elsewhere, I think.

My best guess is that a typical development team of 7 or 8, including the product owner and the scrummaster, costs about $1 million per year. Including all related costs. (In my opinion, every team should know their total annual cost.)

My best guess is that a typical development team can produce about $3 million per year in Net Present Value. Based on what they develop; ie, their share of the "earnings" from the product. This is discounted over the 3-5 year typical time horizon. (In my opinion, every team should be given an estimate, and some data after the fact, of the value of the work they will be doing, say, over a year. This concentrates their minds wonderfully.)

From a Business Value viewpoint, the goal of the Scrum course is to significantly increase the productivity of each team. So, let's assume the whole team comes to the Scrum course. And some related managers. Let's assume the team can double their productivity (their velocity) within one year. Let's assume in years 2 and 3, they continue to improve. So, saying we go from a NPV of $3 million per year to $6 million per year is not a stretch.

Let's say that there are other costs/factors that also contribute to the doubling (coaches, impediments removals, etc). So that the Scrum course, which teaches 3 teams, only gets 25% of the added value. 25% of $9 million is: $2.25 million. (Does the scrum course deserve more or less than 25%? You judge.)

Now, get out your spreadsheet and calculate the value for yourself, with your own assumptions. See XLS file here. Let me add that there are many other benefits, but let's ignore those for now.

By the way, a decent team (not a great team) in Jeff Sutherland's opinion should be able to double velocity in 6 months. Many do in 6 weeks. And some companies are seeing an improvement of 5x-8x for every team and it happens quickly.

A couple more things to say:

1. The purpose of the course is not to convey explicit knowledge, although that happens. The key purpose is to get the people willing, wanting, and waiting to change. "It's the Tacit Knowledge, stupid." (To play with a political quote from the past century.) Without this change, which always happens somewhere else than the brain, no worthy improvement will take place.
2. The team must be having fun. I won't explain that more here.
3. The team must be working reasonable hours (40 or less in total).
4. Thus, the way to velocity improvement is by impediment removal.
5. And thus, managers must be removing some impediments (and letting the team self-organize) or the full amount of improvement won't happen.
6. Finally, this is still not a silver bullet. Teams can be dysfunctional and projects can still be impossible. (The good news is that these serious problems can be identified very much sooner.)

Now, our challenge to you. Have you achieved a measurable and believable increase in your own baseline velocity? How much?

You owe it to yourself, your teammates, your company, your customers, and right now to the world economy, to get your team going. You can do it. If you feel you can't change your organization, first, don't believe yourself. "The culture" can resist one or two people. It cannot resist a fired up group that is right.

Still, if you can't change your organization, then you must change your organization. And then double there. You will be proud of yourself when you do it. You know you can. We know you can; we cheer you on.

Doubling is not enough, but like 12 lawyers at the bottom of the ocean, it's a good start.

Business Value Communication

In March I did a short workshop on Business Value Engineering at 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, it needs to be a set of words and ideas that everyone finds interesting, fairly simple, and compelling. Everyone starts to talk the same language. I find this currently very rarely.

Just to talk about it 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
* ScrumMaster
* Implementers
* 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)
* Customers

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 BV for this effort
  
• affecting concrete team actions; eg, what each implementor does
• reduce conflicts amongst stakeholders (since they can see 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 metrics, 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.

Your thoughts?

Business Value Engineering Workshop

At the ScrumGathering, Tues (tomorrow) I will do a mini workshop on Business Value Engineering. At 1:30pm.

Here are the slides: http://bit.ly/cXmYaI

Most of the slide deck is for reference; only a few of the slides will be used in the workshop. The mini workshop is about 2 exercises.
#1 Define at your table Business Value.
#2 Articulate your BV Engineering approach. (Map, BV Model, Theories, Timeboxes/Feedback loops)

I hope in this way that people will start to see this framework can be used. And also used to look at all the other great ideas about business value that others are discussing. Each of those must be put in the context of an overall framework. This BV framework hopes to be that general context.

BV Engineering is a framework, kind of like Scrum and kind of like Lean. So, as in Lean, we ask that people make explicit the BV "cycle" and approach, much as Value Stream mapping does.

I hope you will find these ideas and practices useful.