Additional Value from the Scrum course

In the prior post, I spoke of a simple way of measuring the value of a scrum course. And the real subtext was: You must measure velocity (productivity) and you must increase velocity dramatically. (And, oh, by the way, a course might help you do that.)

But aside from velocity, does the CSM course provide other values?

I think yes.

So, what might they be? I would be very interested to hear how you would put this (or these).

X has already mentioned that it bring a common terminology. This is very helpful. In many ways, and to many different people.

I have heard a senior manager say: "If they only thing I get is greater visibility into where we are, that's plenty. I don't have to have anything else get better." And while the Scrum course won't guarantee that, one of the main benefits of Scrum is that, if you do it right, everyone gets greater visibility. [Now, we are concerned that some managers will meddle more, in a hurtful way, if they get greater visibility, but almost always the meddling goes down some, at least.]

People work less in isolation. I think this is a big improvement. It is a more humane way of working, in this way. Less lonely.

Teams are held accountable for something important, rather than an individual being held accountable for something fairly unimportant and outside his/her control. This is, in general, a big improvement. There are issues, and there are ways that Scrum still holds (appropriately, I think) individuals accountable, so this needs further discussion, but in general, a clear improvement.

More fun. Scrum says that the team must be having fun (well, mostly fun) or its not being done right. And, if it is done with "right" limits, it is always more fun (or so I have found). To me, this is a value on its own.

More focus on impediments. The PMI folks might argue that we always were working impediments, and of course in some sense this is true. But Scrum brings a lot more rigor and effective action and focus on the top impediment, one at a time. Everyone can contribute, the team can identify and prioritize them and devise a plan to remove each one. Even if we don't measure velocity, this is a big value add in many ways (eg, more satisfying and less painful way to work).

So, that's a start. Hardly a complete list of the value. But a start.
You could say that these start to explain how Scrum "magically" leads to greater velocity and a higher delivery of Business Value.

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?