What is Scrum?

I am excited to be giving a Certified ScrumMaster course with Jeff Sutherland next week. In Richmond.

So, I was thinking: what is the essence of Scrum if you would play the game well?

(Remember that Scrum is named for the Scrum formation in Rugby. We often show a video of the famous All Blacks team doing the Haka and playing Scrum. We think Takeuchi and Nonaka, who originated this metaphor, were thinking of these great teams.)

To me the essence is that team spirit that is willing to face a rough opponent and a difficult situation, and overcome any obstacle to win.

I sometimes call this the Michael Phelps attitude. He is thinking: "I broke world record in each of the last three heats. And now, in the finals, I want to jump in the water and break it again."

There are many things from art and science that we give the teams in the course. But we must convey this essence. Without this tacit knowledge, it avails almost nothing to have all the explicit knowledge in the world.

Value of Training (CSPO)

What's Scrum training worth?

I am about to lead a Certified Scrum Product Owner course. (2 days, in NYC and a bit later in Saratoga Springs.) The question comes up...what is this course worth?

I explain this in more detail in the course, but here's the summary.

In the course we talk about many things, and hope to get many improvements. Imagine, though, that we only make 2 improvements to a Product Owner. And that PO manages only one Team.

Assume the Team costs about $1 million all-in per year. Team of about 8 people.

Assume the Team currently produces about $3 million per year in NPV (net present value, a core way of measuring business value). (Microsoft seems to be averaging about a 5:1 ratio or better overall.)

OK. We teach Sam, the PO, how to create 20% better stories. So, instead of $3 million per year, the team can get $3.6 million per year.

Now, we also teach him the Pareto Rule, and how to work it all the time. (80% of the value comes from 20% of the work.) Now, we and Sam aren't perfect, so Sam comes back only able to execute the 85-33 rules, ie, 85% of the value in close to double the 20% of the time that Pareto's rule calls for.

OK, this means in 33% of a year, the Team can get 85% of $3.6 million. Let's round down and call that $3 million. We assume Sam (and the firm) can find more work of the same value. So, in the next 33% of a year, the Team produces another $3 million in BV. And in the last third of that year, the Team produces another $3 million in BV. So, now we have $9 million in BV in one year. A 3x improvement. (I will note we assume that the Team did *not* increase Story Point velocity at all. No other impediments removed...very conservative assumption.)

Even if we (the teacher and Sam) don't immediately achieve quite the same level of improvement we assumed (which itself was far from perfection), I think you can see that, a million here, a million there, pretty soon you're talking real money. And, in my opinion, those improvements alone justify the costs for the 2-day course. Even in a serious recession.

What do you think?

Defining Business Value // #1 Risk

I hear many people complain that it is hard to define business value. So they won't do it. Or they won't try any harder to do it.

That it is hard and always changing is true. That fact does not, though, give us sufficient reason not to work hard to get better.

I won't reiterate here all the reasons why understanding business value really well is very, very important. Suffice to say that one can argue that there is no more important thing to understand. (Yes, one still has to actually build the new product.)

One comment I hear is "I can't define what risk is worth." So, today, let's take risk as an example.

My main reply is "well, get an actuary...those people define the dollar value of risk all the time. It is called an insurance premium."

Then the response often is: "There is the business loss from an 'event', and there is the harder to quantity 'loss of reputation'."

This is correct, as far as it goes. "Loss of reputation" can often be harder to quantify. But nonetheless, you must take a stab at it. And prove to yourself whether your theory of what it is worth was high or low. Only by taking a stab at it, do you force yourself to learn.

Wide-band delphi. I cannot too strongly recommend this technique. As the Romans said, to predict is difficult, particularly of the future. So, we want to get the best ideas possible on the table so that we improve our odds. By improving our odds, we improve the likelihood of overall business success.

So, risk, as one example. Let's say risk (in several forms) is the main driver of the business value of a large effort. Here is one way to estimate it. Based on assumptions I will not articulate here.

Get Fibonacci cards that go to 987 (several orders of magnitude). The 5 "experts" (the best experts you have) go through the Product Backlog, and use the basic planning poker technique, but this time they are estimating the Business Value of each story. (I assume the reader understands basic planning poker.) For each story, the experts question and discuss the underlying assumptions about Business Value. They take an aggressive attitude that they are tryingto uncover Pareto's 80-20 rule within this population of story cards. The BV is relative to the smallest reference story (marked with a BV=1). Ideally, a small set of reference stories. The experts reach a reasonably close consensus (within 3 Fibonacci numbers of each other), and then average to score each card. By and by they complete all the story cards.

But to make a lot of business decisions, you need to know the dollar value of the "whole" effort. (Discussing "whole" is a rabbit hole we won't jump in just now.) So, having had a good discussion of the stories, we ask the same experts: "Ok, write down in secret what you think this whole pile of cards is worth. In dollars. If you need to do a calculation, do it. If you can't think about it any other way, what is the maximum our business should consider to pay for this stuff? How long for you to estimate this? And any questions now for the Product Owner, before you start?"

They might ask the Product Owner about some assumptions. "How many people will this affect? What is the average size of an account? How many accounts do we project we will have in 3 yeras? What's the largest fine the Federal Reserve has ever given?" Whatever they think is relevant.

Regarding the timebox, anything more than 1 hour is too long, almost always. (If the calculation is really important, and will take longer, then maybe.)

Each of the 5 experts writes down his dollar number on a piece of paper, in secret.

Now the fun. You bring all five experts back together, and have them turn over the pieces of paper. They won't be the same. As with planning poker, you have the 2 extremes talk. Then they all discuss what the best assumptions should be. Like a Scrum. But in some sort of timebox. Typically there is a good "fight". This is good. Also, typically, they each need to go back and re-estimate. You might do a couple of rounds of this.

You want a reasonable consensus, but not perfect. I will recommend that the least degree of consensus is within one order of magnitude (eg, $11-99 million). Ideally a good deal more than that. Normally, once within some reasonable consensus, then average the numbers they give you.

Example: 3, 4, 7, 8, 9. The average is $6 million or $6.2 million. (I would not pretend we have more precision by extending the number of decimal places.)

Sometimes it is good to go to the next higher level of management and discuss how the $6 million BV estimate was arrived at. And ask them: do you think this is a reasonable estimate? If not, how would it be improved?

Is the number derived perfectly accurate? Of course not. There is no end to improving our BV estimates.

Is the number better than we currently have? Almost always.
Is the number useful enough to make business decisions with? Yes.
Is the number good enough for us to start learning from? Yes.
Should we revise the number later? Certainly. The key question is how many times.
Should we try to do an experiment in the real world that tries to prove that the estimate was (or was not) reasonably accurate? Yes.

***
Note: The diagram about risk management is borrowed from techrepublic.com. The point, for me, of the picture, is only that it is about risk management. I am making no point now about whether the ideas embedded in the picture are good or bad. Still, the fear of risk often leads people to take no action ("deer in the headlights"). This is often the worst of several options.