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.

The best work?

I just got an email where someone said that their group does not have a real project-type project. This got me thinking.

Key idea: How do we know our Agile teams are getting the best work?

It seems to me we have the theory that, magically, "the users" will ask us for the best work we could possibly do.

So, let's parse this a bit. The users might be the business or management or the customer. And the best work might be the most important thing we could do, or the most valuable or the highest business value, etc.

OK, so as soon as we make transparent the hypothesis we can see at least 4 holes.

1. The users are always human, and almost never can identify the highest value things. Consistently, reliably.
2. Identifying the highest value things (product, project, story, whatever) is, in large part, cost-benefit analysis. Only if the decision maker has complete understanding of all the benefits and all the costs (risks), can she make the best decision. If we technologists don't tell the business folks about the costs, how can they possibly give us the best stuff?
3. Do you know what you are really capable of? For sure, most business guys do not know what technology is really capable of. And they don't know what your Dev team is capable of.
4. Are we technologists capable of keeping up with all the extensions inherent in existing technology? Or keeping up with technology innovation? Even less can the business guys do that.

How do we fix this mess?

The issue here is that, although we are doing important work, we are still "failing" if it is not the most important work.

Well, I will suggest we need to get business and technology people together more, and the technologists need to ask: "How could we be more sure that we are getting the best work... so we, together, can make the greatest possible contribution around here?"

There are about 250 business days each year. I bet there are 250 ways to phrase that question.

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.

Identify your multiple! WHAT?!?!

Let's discuss the last post, from the skeptic's point of view.

Simon (the implementor) 1: "OK, I don't want to get fired. But what this "multiple" got to do with it?"

The multiple is the relationship between the cost of the team and the NPV (net present value) of the benefits the Team delivers. As in: "If I invest $1 million in this team over a year, I expect them to (and they usually do) deliver about $3 million in NPV from that work." If you have been doing any investing in the stock market lately, you will appreciate that that is a powerful statement.

Simon 2: "Great. You're asking me to get something I don't understand. And I know we don't have it around here. Thanks for nothing."

Well, if you are an implementor, you have no real need to understand NPV in detail. How it is calculated. You're right about that. Product Owners (or business sponsors) should do that. But you can appreciate that some BV must be delivered, othewise the firm would not invest in the team (or at least should not). ie, You don't have a job.

You think no one has NPV around your shop? Three comments:
1. Yes, this is all too common. And incompetent. (Did I say that nicely enough?) [more on this below]
2. They might have it and not tell you. At least the initial estimate used to justify approval of the project.
3. To me, it is also incompetent management not to inform the team, at some level and frequency, how much BV they are delivering. (more on this below)

So, go ask your Product Owner: "Show me the money. Now." If she can't show you money, she must at least have something.

Simon 3: "I went and asked the PO. And she said it was too hard to estimate. She said: "It's a very important project, trust me." Too much risk involved. Kinda made sense to me."

Well, at some point you must say: "If these guys manage this badly, I should go work for a better managed firm." But maybe not this week.

Yes, doing our work as professionals is hard. Estimating BV is hard. And predicting the future is difficult. Developing software is difficult too. But of course, that should not stop us from doing what is important.

People also make it seem harder than it is by demanding too much precision. All we need is a decent number, with a reasonable bell curve of probable values, and we have enough to make decent business decisions. (Simon says: "Ok, yeah, I remember that bell curve stuff from that stats course in college.")

So, who knows how to convert risk into dollars. Let's see...umm, I just got a bill from my auto insurance company. Oh yeah, they use "actuarial science" to establish premiums (price/value) for risk. So your firm could hire one of those guys.

Simon 4: "I went back to the PO and she said we have no actuaries around here now. So we're stuck. Your idea is a non-starter for us. And thanks for making me feel bad too."

Wait a minute. Let's try another approach.

Can we get about 5 key senior managers who understand the business side of your industry? And also the business side of your effort (project/product)?

Ask them to play a kind of wide-band delphi. They discuss the assumptions and facts around the project (or set of Product Backlog items) to guess at the total BV. Then each independently guesses (eg, writes a number on a hidden sheet of paper). Then they all show at once. If the two extremes are disparate, then the two people who voted the extremes talk about assumptions. And maybe the team asks more questions to get the info for a better estimate. Maybe they vote again (and maybe another round). At some point you declare "we have enough consensus", and average the numbers given.

In case this "team" may be biased (or someone will complain loudly that they are), I suggest you or the PO have them take the number and explain it to a more senior manager. If it passes his "sniff test", then it is good enough for business decision making.

Simon 4: "Yeah. Tried that. They wouldn't bite. Are you wasting my time yet?"

Ok. This happens. Usually I am not happy with it. Sometimes it makes some sense.

So, we have another approach.

Ask the delphi team what the maximum is they would pay for it (that feature set or "the project"). Go through some reasonable consensus building. Then take the numbers and average them. Now you have a number. It may need "rounding up", given that most people want to make a profit on investments. And this number is the max cost, not the max value.

Simon 5: "OK. That sounds reasonable. But what if they don't bite for that?"

At some point you must persuade them. Or leave. Or wait to be fired (worst option).

Explain to them all the ways that not having a decent estimate of BV known by the Team is hurting them. Often this will work.

For example, telling the Team the Business Value will almost always change their behavior. It will affect their motivation. It will get them thinking about what is most valuable to the customers (or various end users) and to the firm. Your best implementors typically don't do their best work until they see the challenge.

Simon 6: : "I will try. But what if they don't do it?"

Again, if they are really incompetent, you should leave. Alternately, show them why BV is important to you. Make a personal case.

BTW, incompetence can be very easy to fix (or very hard). Some people, with just a little training, can become competent. So, we don't mean these folks are evil, or mean harm, or are completely stupid. Probably no one, yet, has made them see how doing things a different way would be better.

Simon 7: "Wait a minute. That remark could apply to me. Are you insulting me?"

Well, the usual case is....we all could be more competent at our jobs. It is more useful to think of this as...not a problem, but an opportunity.

Simon 8: "OK. Let's imagine they give us an estimate of BV. How do I know they didn't just pick it out of [bleep bleep]? I mean, you know what these [bleep] are like!"

Simon, come on. This is the public airways. Please.

Still, very good question. Make them get real numbers that show, after-the-release, whether the estimate was decent or not.

Usually the estimate will be somewhat wrong (high or low). Tease them a little, but don't make them chicken to guess (uh, estimate) the next time. As you know, stuff happens between the time you estimate and the time the software goes live. And insist that they learn how to do it better (and maybe more frequently).

By learning about this, we each can have more successful work. More satisfied customers. This makes for more successful firms. Pretty soon, we might have the economy back on track. And then my neighbor will have a job again, and quit talking to me endlessly about ACC basketball.

This Bus Value stuff is not as much fun as watching somebody make a fool of themselves on American Idol. But it might be more important. To you.

ACTION: Go identify your multiple. Now.

Two posts ago, I buried a key idea in a lengthy list.

Here's the gist. When the managers come around trying to figure out who to "re-engineer", would it be helpful to be able to say, "Guys, the firm invested in our team about $1 million last year...and got about $2 million back NPV"...might that allow you to relax if you could say that? (NPV means Net Present Value...your Product Owner should know this stuff.)

By multiple, I mean the relationship between NPV and cost. Usually the multiple is between 3 and 20 (or should be).

OK. Action item. For today. Go talk to your Product Owner and estimate the NPV of your last project as a team or your current set of work (say, next 2 releases). Annualize it (managers think more easily in those round numbers).

Much better if the NPV estimate is based on actual results rather than someone's dream of what the benefits "ought" to be.

Yes, there are lots of issues. Yes, life is difficult to measure. Get the best approximation you can.

Example: "We have a risk project. How can you measure NPV for risk?" Umm, who is really good at putting a price on risk? Auto insurance anyone? Go talk to an actuary and let 'em help you figure it out.

Yes, there are lots of problems with these numbers. Heck, there are lots of problems with helmets in the NFL, but I would not recommend playing without one.

Should we invest in a better Product Owner?

I won't bore you with the calculation, but...

If you assume that a better Product Owner can:
* increase the value of Product Backlog items (stories) by 20% on average
* identify the Pareto curve partially in the Product Backlog, so that an 85-33 rule applies
* and if we assume that the team costs about $1,000,000 per year (all-in) and delivers, before the better PO, about $3,000,000 per year...

...then, what happens?

The team is now able to deliver $3,000,000 "projects" three times per year. Thus, this new PO has tripled the business value delivered by the team.

So, how much could you afford to invest in that better PO to get those results? Probably more than $1,500 (eg, for a Certified Product Owner course). And, while the course is good, I suspect that most Product Owners need more than just the course to get those results (eg, perhaps some coaching from someone really good).

So, what's the first impediment to doing this?

What I find is that most firms think of their IT department as a cost center. And thus they have no concept of BV delivered by IT, much less metrics around that. So, I am suggesting that just getting estimates of BV (and telling the team) and then measuring (even if only roughly) the BV actually delivered would be a big step in the right direction.

BV does not have to be measured in money. At least not initially. Depending on your firm, other direct metrics would be more meaningful. Then you need some experts to give you a rough estimate of the money value of those benefits.

Knowing the BV delivered of each team might be kind of important right now. In more ways than one. Go talk to your Product Owner about that today.

Business Value Engineering

BV Engineering? What is that?

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.

Toward a general theory of business value

I did a presentation yesterday at Agile2008. Here is the link to the slide deck.

I hope it would be accurate to say that being there would have been more useful than just reading the deck. But here it is.

Two key ideas.

Business value is about learning. As a team. BV is always changing (on many dimensions) and we learn, in part, to keep up with that change.

Business value is about communicating to change behavior. As in a lot of situations, it takes some effort to communicate successfully. It might not happen very well the first time you do it. Inspect & adapt.

In addition to trying to reveal all the ideas and assumptions around our use of "Business Value" (or at least many of them), the deck also talks about:
(A) definitions of business value
(B) relatively specific actions during the course of an effort where we can improve our business value engineering

This is a quest for mastery in a very difficult skill. Even intermediate skill levels take a good time to achieve. It is my belief that the effort pays real dividends. So I think I have seen and so I think others have told me is their experience.

The deck uses a circular and episodic approach. All the interconnections between the ideas are not spelled out, and it is for the observer's mind to actively engage and discover them for themselves. The whole is more than the sum of the parts. At least in my opinion.

One hope you can use with benefit.

The Nokia Test (5): A prioritized Product Backlog is essential

We started a series on The Nokia test some time ago. This is the fifth explanatory post about the test. To find the others, search above (left). And here is the original post.

The second item in the second section of the Nokia Test is this:

• There is a product backlog prioritized by business value

Seem obvious? Well, maybe you don't want to say so quickly.

First, if we are doing Scrum, we must have a Product Backlog. A Product Backlog is a list of all the work items the team is expected to work on. If the Team is doing software, most of them will be features at a high or low level of granularity. In Agile, the growing preference is to put these Product Backlog items in User Story format.

This part of the Nokia Test does not require you to use the User Story format. Or any particular format.

"Prioritized": Ummm. What does that mean?

Well, I think it means that the Product Backlog has been put in order of Business Value.

The Nokia Test does not give us any hints about what Business Value is. My opinion is that this itself is a complex topic. But I think the implication is that the Product Owner (who owns the Product Backlog, and makes all final decisions about it)...the Product Owner will put the items in business value order.

Does the test imply that Nokia always wants to work the highest business value items first?

This is open to some debate. My view is that one can still pass the test if one also uses "cost" (or story points as a proxy for cost) and dependencies/risks as additional factors (bits of information) in helping the Product Owner to order the work.

Let's put this some other ways.

The technical team does not have the final decision about what order to do the work in. Sometimes it is better to be inefficient and get some high Business Value item(s) out there in production.

Since all Product Backlog items are not of the same size (let's call this "amount of work" for now...although one must tread carefully here), and not of the same Business Value, the Product Owner must do cost-benefit analysis to determine (implicitly at least) business value per unit of work for each PB item.

Why do we prioritize by business value? We are always trying to discover and release business value (eg, increase customer satisfaction). Quickly. Only if we use Pareto's 80-20 rule can we do the most important stuff first. Ordering the PB items puts Pareto's rule into play.

And I think the Nokia Test says the Product Owner cannot cop out and say each PB item has the same amount of Business Value.

Similarly, this part of the test does not prohibit some team members (developers), where they have useful knowledge, from influencing the Product Owner about business value and about the order of the work. (Still, Scrum says the Product Owner gets the final say.)

* * *

Well, that's a start on the implications from this one part of the Nokia Test.

Please see our other posts on the Nokia Test.

Note: The picture of the story card above was stolen from here: http://www.pragmaticsw.com/newsletters/Newsletter_2008_05_SP.htm

What is the scope of impediments?

Last night at Agile-Carolinas we had Israel Gat, VP of Distributed System Management at BMC Software. He spoke on "Leading the Disruption". He is giving this talk also in Austin, TX (and maybe elsewhere). If you get a chance, I urge you to go. Or just contact him.

After that meeting, I had several conversations. And then thought about them this morning. All that results in this post. Or at least, this question?

What is the scope that defines what might be an impediment?

By definition in Scrum, an impediment is anything that keeps the team from being more productivity. And I personally add that everything is imperfect, so by my definition everything is an impediment to some degree, and the trick is to identify the one or two biggest impediments today.

Scrum has also said that the scope is wide, including such diverse things as engineering practices and personal issues.

What I have not seen talked about much is the scope from an end-to-end Value Stream perspective. So, I would argue that anything that reduces the business value of what the Team produces (or the speed with which the value is realized) is an impediment.

So, as a simple case, imagine you have a Dev team in Charlotte and an "implementation" team in Chicago. (In this context, implementation means all those services around the software that make it actually useful in production.) The Dev team completes their work. The Implementation team is not ready (certainly not as ready as the runner to the right). So no business value can be realized.

I am suggesting this is an impediment. Perhaps the top one for that Dev team. And that Dev team (and their ScrumMaster) need to assure it is fixed (understanding that "a dead ScrumMaster is a useless ScrumMaster"). They probably can't fix it themselves, but they can make many efforts to get others to fix it. Perhaps they need to enlist a manager's help.

To me, this is similar to what Toyota found, ie, that to get the full benefits of Lean, they needed to aggressively train their partner firms upstream and downstream from them in the Lean ideas around flow, pull, JIT, etc, etc.

Does this make sense to you?

Your Business Case for Agile

My friends at Innovel have a blog entry titled "Build Your Business Case for Adopting Lean Agile". Take a look.

As you try to get a revolutionary idea adopted, remember that you must always be selling the idea (see John Adams to the right). (Note: You don't even need 50% of your countrymen to agree, if you would succeed.) Your idea may be brilliant, may even be one of the best ideas ever to appear on this planet, yet you must still sell it.

To start anything in business, you need a business case. And given that everyone has a say and an opinion, in fact you need to have a good feel for all the benefits involved, so you can explain the WIIFM to anyone. (WIIFM = What's In It For Me)

And given that change is happening all the time, you even need to keep your business case up-to-date, since Agile will always be challenged with some equivalent of "what have you done for me lately?" People change. People forget. Attention gets re-directed.

So, what is the case?

Well, coincidentally Israel Gat of BMC is giving a talk this week at Agile-Carolinas (and another at APLN-Richmond). "Leading the Disruption". The idea that for BMC, Agile was so successful that it was disruptive, particularly for downstream processes. Such as sales and marketing. In a prior presentation he had shown hard data that to me proved that Agile had given them double the productivity for a large IT shop, compared to essentially waterfall (compared also to what they were doing before).

There are many people to whom we must make the case. Let's assume for now, to a senior business manager (maybe the CEO?).

BMC so far has doubled productivity. Umm. Impressive. In fact, Scrum (the main flavor of Agile that BMC use) was built to increase productivity by 5x to 10x. And it has been proven to have done so with some teams (the community has data in various papers). We don't (yet) have the broad based data to show whether "some" really equals many, most, likely, X%, for certain types of teams, etc. , etc. Based on the anecdotes I hear, most teams are clearly better even when not doing "most" of Agile. And teams that adopt Agile well are typically very much more productive.

Let's look at this a different way. The multi-functional IT teams (including business people, etc) are producing: more, faster, cheaper, and better. All at the same time. As in, higher quality, more accurately what the business needs (not just what they said), faster time to market, etc. What's not to like?

Another benefit senior managers like is visibility. They can tell whether an effort is on target or having problems. (More on this later.)

As Jeff Sutherland says, the ability to change directions quickly, and to focus this fire hose of productivity on a competitor's new feature is very valuable.

As an aside: One thing not to like is people doing cowboy agile. That is, people saying they are doing agile, but who really are not. At the extreme, this means people whose definition of agile consists of "we don't do documentation". Cowboy agile makes your audience more skeptical of real agile.

OK. One more thing on this topic.

How do you prove this for yourself?

Take people to the Gemba; show them the team room, the team, the product owners of successful teams, the working software. (Gemba is a Japanesee word, famous in Lean, meaning "the place where the truth may be found.")

Also, gather metrics from day one. I will talk about other metrics later. Today let's talk about velocity. Gather velocity (the sum of the story points of Product Backlog items completed in an iteration). Show that it is reasonably consistent from sprint to sprint. Then show the velocity increasing. Remove some more impediments. Show it increasing more. Impressive. A blind man can see this stuff.

If the velocity increases by 50% and the business value of new stories is not diminishing, then clearly you've got something going on. All you have to prove is that Agile is a good investment compared to other investments. Not hard if you work at it.

Will every team succeed? No. (Actually even failure is a success with Agile...topic for another post.)

Can fairly good people generally show impressive progress? Yes!

What's a ScrumMaster Worth?

You may have noticed that some people are feeling a recession out there. So money can be a bit tighter.

So, can you afford a good ScrumMaster?

The answer is obviously yes, and in fact they are even in greater need (since there is greater urgency).

Now, let's unwrap this from a financial viewpoint. We will use a simple example, and provide a simple spreadsheet. Hopefully you can take these ideas, use your own local numbers, and have a good conversation so the right thing happens.

A caveat: This post is not suggesting that the ScrumMaster is the end-all and be-all. We are asserting that the ScrumMaster can have a big influence on the productivity of a team. And that better ScrumMasters can have a lot more influence. And that the best ScrumMasters are rare.

* * *

Imagine a team of 8 that costs $1,000,000 per year. Including the Product Owner and ScrumMaster.

That team produces Business Value at some multiple of its cost. Let's take the case that that multiple is 7x. So the team produces $7,000,000 in BV per year. (One can think of BV being NPV (net present value) but it could be measured, originally at least, many other ways.)

Let's take the case that the team has an "ok" ScrumMaster, but the team is increasing velocity at only 10% per year. (Assume at the beginning of the year they are running at 150% of waterfall velocity.) Assume the "ok" ScrumMaster is making, all-in, $125K.

Now assume a "better" ScrumMaster who can double the productivity of the team in one year. (He does this by removing impediments or having them removed.) And assume that the better ScrumMaster (if he is available) costs $250K per year.

(NB. I hope you are noting that the numbers we are using are simple, round and convenient. You have to identify your own numbers. Nonetheless, I will call the numbers in this post, hopefully, inspirational.)

My, my, my. Very expensive dude, isn't he.

Should we invest in the better ScrumMaster?

Well, let's look at this some more. We assume that the Product Owner has or can discover new Product Backlog items so that the average BV of stories will not decline over the year. And let's assume the better ScrumMaster does not improve productivity by helping her (the Product Owner) discover more business value. Let's further assume the better SM improves (enables the team to improve) velocity roughly equally over the year. So that, over the next year the team will produce $10.5 million in business value (rather than $14 million, if the jump were to happen immediately).

I have also assumed the situation (the team, the managers, the company, etc) will allow the better SM to help enable the team to reach a 2x level.

(N.B. The conversation is about value in relation to cost. It is not, and never was, purely a cost consideration.)

So, for an added investment of $125K, the firm will get an extra $3.15 million. Is this a good business decision?

Well, we don't quite know yet.

Let's assume the better SM finds impediments that cost $1 million to fix (training, SW, HW, etc), so that, in simple terms, the firm must invest a total of $1.125 million total to get $3.15 million.

What do you think? Is this a good business decision in a recession?

One could discuss my assumptions endlessly. Discuss a little if you must; then do an experiment where you are. We are all interested in your results.

(To update this algorithm with your own assumptions, download the XLS file here. And revise it.)

N.B. Scrum was built to help teams get 5x to 10x productivity gains. I think a 2x gain in one year is conservative (low, easily reached in a normal situation). So, there is more juice in the orange. There is also the possibility that you have a "dead core" and further productivity improvements are not possible. More on this in later posts.
N.B. A key principle of Agile is sustainable pace. So in Scrum, the gains are not made by driving the team through a "death march". Unfortunately, this still has to be said for some people.

Toward a general theory of Business Value

The title of this post is a little highfalutin, but it gets the idea across I hope.

After many discussions with people about this subject, I find that the words "business value" tend to mean something very narrow to most individuals.

For example, the words often mean mainly or mostly: "the numbers we put on the story cards", "the silly NPV estimate someone made to get this project approved", "how the company benefits from this team's project", "something that only the business guys care about...probably they just want to boast that they have the project with the biggest one", etc.

It is important to note immediately that business value ties in with our highest values. To satisfying the basic human needs of those in difficult circumstances, of obtaining our highest aspirations, of leading a good life (in whatever way you define that). When I was young, I was taught two main rules: (a) Love God, and (b) Love your neighbor as yourself. Without ignoring (a), let us say that in my opinion, business value is really about expressing caritas to specific individuals.

To me, when you use the words business value, you imply and/or are really talking about a whole bunch of things:

• a definition of what value means; and one or more specific operational definitions of BV for the effort (project) at hand
  
• a bunch of ideas that surround and pervade BV, that are key to the way we use it
• a recognition that communication and motivation are key
• a very practical down-to-earth subject, that is at the same time difficult and slippery
• a bunch of practices that make BV useful. I want to call these the BV engineering practices (although again that may sound too highfalutin to some)
• change and learning, so the subject is as much about adapting to change and learning about it faster, as about any hard and fast dicta on BV itself

And other things as well.

So, I wanted to back up on the subject. At least compared to some who want to rush to consensus on one definition of business value (eg, reduction in cycle time, to pick one of my favorites from Lean).

So as not to lose you, please define in your own head what Business Value means to you. Say, the business value of a project. (I assure you there are many different definitions out there.) Now, think about that as I talk about why we care about business value.

I am searching for the general ideas that pervade all views of business value. And perhaps by examining them, we may discover more about what BV really is, or at least how to use it better.

Why do we care about Business Value?

"You have to be very careful if you don't know where you're going, because you might not get there." This was Yogi Berra's wacky and wise way of saying it.

I have been on too many projects where there was no clear definition of what we were trying to accomplish. In several cases, one guessed that we were at the personal and daily whim of some project "leader" (not that I considered the leadership skills all that high).

Let me state this a different way.

In the world, my hypothesis is that there are an infinite number of good things to do. The problem is not finding a set of good things to do, but in deciding which are the most important things to do.

So one reason we care about BV is to, in this short lifetime, accomplish something truly meaningful.

Another reason is that we work in small teams. And we want everyone to be working toward a common goal. So we need to agree what that common goal is. It can be expressed in many ways, but at one level it must be called business value. Or, more specifically, the operational definition of business value for this project that motivates the team to do only (and just) what is needed as defined by business value.

Put another way, business value draws upon our natural motivations, and gives us a basis for putting a natural order into all the arrangements involved with a team's work (eg, who does what, the architecture of the system, etc., etc.).

Another reason is based on my hypothesis that change is incessant. This means that people forget, customers change, customers' needs change, past estimates (if they were accurate) are no longer accurate, etc. To the degree we understand BV appropriately, it can act as a guidepost in this swirl of change. We do not build new products for mere technical success. We do it to provide business value to specific people, so we must adapt to this change.

My hypothesis is that BV itself is also changing. This is alluded to below, but more a subject for later.

Four related ideas

Let me mention now four ideas that are key to understanding business value (that weren't already implied by things I said earlier).

Cost-Benefit Analysis: No buyer buys a thing in isolation. He is always comparing an apple to an orange to a box of Cheerios. He only has some much money (or time), so which gives him the most satisfaction for the buck? It is my hypothesis that we should use this kind of thinking (or should) for each project. And we should do this at a more granular level also.

Pareto's 80-20 Rule: Pareto posited that in any population, there were "the vital few". This is translated into saying: "20% of the things provide 80% of the value." And this is true for any size population (or at any level of population, if you prefer). So, it is probably true of projects, of themes within a project, of nitty "requirements" within a story.

My hypothesis is that, in any set of stories for a project, there are at least one or two order of magnitude difference (given the same size story) between the BV on one story versus another. This information is very valuable. This is a very common (although not universal, I think) situation for product backlogs.

Knowledge-creation: There is a whole set of ideas around knowledge creation. We will greatly simplify them here. First, that a team is better at learning/discovering new things than an individual. Second, that knowledge goes through cycles of conversion from tacit to explicit (and perhaps back again). Third, that knowledge creation is energized by putting people together in a place and providing a context (meaning). (See The Concept of "Ba".) Fourth, that knowledge can be said to self-organize into a product (solution). There is increasing evidence that knowledge-creation is the core competency. Our hypothesis is that applies to Business Value in many ways.

Learning Methods: We think BV should be used in the context of (to pick one instance) Deming's PDSA model. This is Plan-Do-Study-Act. (Basically the scientific method.) We think short, time-boxed iterations are key. That some data is a key learning device (comparing expected results to actual results). And that general indicators are more important than slowing down for precision and "accurate" numbers. In the end, though, it's about people, not the numbers. The numbers are only a rough guide to the people. In many cases, out-of-the-box intuition may be a better guide.

A full BV engineering approach

Let's give a rough first definition of what we think a minimal BV approach would be (the fancier term would be a full BV engineering practice).

• a well-communicated high-level definition of business value (this might have multiple dimensions)
  
• a well-communicated operational definition of BV for the specific effort
• a clear way to measure whether that hypothesis (as embodied in the operational definition) was correct; or how incorrect it was (probably a likelier outcome)
• a confirmation that this definition actually energized behavior (eg, the programmers wanted to see success in that way) and that it was used in a way that allowed small adjustments toward a better outcome
• a clear set of practices for using this definition throughout the course of the project
• a clear way to modify those practices, so that better practices could emerge over time
• a common understanding about the time-boxes around the practices, and a continual questioning about whether those time-boxes (presumably at different frequencies, depending on the practice) were the most effective in guiding a better delivery of business value in this specific case
• a set-out way to develop the people to perform these engineering practices (training and the like)
  

There should also be some discussion about the dimensions of the word "better" in the next-to-last bullet. That might mean faster, more, higher quality (perhaps more reliably hitting the target), cheaper, etc., or some combination of those, depending on the context. My personal bias would be, first, to optimize faster delivery.

It is probably necessary to say (just as we still have to say that agility requires greater discipline of a sort) that the overview of the BV engineering approach above does not imply something like BDUF, endless documentation, high ceremony, etc.

* * * *

Now, does all that discussion make sense in the context of your current definition of Business Value? I hope so.

I would greatly appreciate your comments on this discussion. And on later related discussions. Or earlier ones. More to come.

Business Value and Money: Killing Low Priority Projects

This topic is leading somewhere. It may take a few posts to fully get there.

First, let me say that in my personal opinion (and Peter Drucker's and many others'), business is not mainly about money. Money is a measure, but it is not why we run the race. Business is about delivery satisfaction to your customers. You do that, then you meet the very real constraints of making money (for employees, for shareholders, for suppliers, etc).

Nonetheless...money is a very clear indicator. And some people get very fuzzy when they start to describe "why are we doing this project". So I am, with some hesitancy, going to suggest that we ask 'em: "Ok, we are spending very real money to develop this new product. I need to know how important it is." Perhaps "I" is one of the developers, who gets much more motivated when the project is important.

So, let's take a simple case (so the math is easy for me). These details:
Project length: 1 year
Project Team people costs (all in): $800,000
Other project costs: $200,000
Total project costs: $1,000,000

So, we are investing $1 million. What do we get back?

I will suggest that the first release of any project should always bring a high multiple over the costs. In fact, one way of picking projects is only to do those that bring the highest multiple over their costs.

When I was in MBA school, we learned about the CAPM (Capital Asset Pricing Model). I don't think it has changed much, at least for purposes of this discussion. The basic idea is Net Present Value (or Internal Rate of Return) of cash flows. To make this example simpler, let's say that the lowest multiple for active projects for this company is 5. Thus, we want the NPV of the project to be $5 million.

Side note: If you feel you must get into all the heady stuff around the CAPM, start here: http://en.wikipedia.org/wiki/Capital_asset_pricing_model My suggestion is that most business decisions can (and must) be made with much less precision. Bond trading might be an exception.

So, the Product Owner says: "I can't put money on the benefits this new project will give." You say: "Fine. Understand that it is difficult to be precise. But let's do a sniff test to see if we're wasting our time on a low priority item. If you think about all the benefits, do you feel comfortable telling everyone, including our managers, that the implicit benefits of this project, taken together, are worth at least $5 million in NPV?"

This is an order of magnitude swag, but I hope it knocks down a few projects that are being done "for other reasons than business value" I'll say diplomatically.

Does this help a little? Your comments are welcome. You might want to tweak some of my assumptions (cost of project team, return multiple, etc). Easy to do in a spreadsheet.

How to measure success on agile projects from a customer point of view

This topic is a thread on Scrum-Dev (the yahoo list). Excellent topic. With many good posters. Go and see.

This is an involved topic, so I will give some views in this post, and more views later.

I start with the word "measure". Because I am concerned that we are measuring too many things (not good), and the wrong things (even worse). Many people don't take to being measured like a thing. (People have lots of characteristics and variability, but being a "thing" is something they are especially not good at, or so I have found.)

So, what to do if one wants a simple measure?

The simplest "measure" would be to ask the Product Owner on the team..."is this team effective and are you guys producing business value?"

This is one measure. It might even be binary (yes or no). And it is low cost to collect, except that the Product Owner might give you (let's say for now that you are a senior manager) more of the truth than you want. And ask you to assist in making things better (and things can always be better). (As an aside, if the Product Owner were really good, I might accept a yes/no answer. From a less strong Product Owner, I would always want a longer answer, probably with follow-on questions.) And it might be a conversation that is forward-looking and action-oriented.

The next problem becomes "what is business value really"? To me this is the key direction to take this question (finding a simple measure). (There are other directions we must also take, but for later.)

Let me emphasize this: efforts (projects) are successful to the degree that they deliver business value. There are no technical successes ("we did what we were asked to do", "we're within scope and budget", "it's a beautiful system", etc, etc). There is only delivery of business value...at least somewhere along the chain of value to the ultimate customers.

Therefore: "what is business value really?" There are many views on what business value is. We have discussed some in earlier posts.

Lean says that value is defined by the customer in the context of a specific product (service) at a specific time. That says, among other things, that customers are redefining value all the time. If you take your own personal experience, you know that your "values" (at least in the
material world) are changing all the time. Your own wants and needs change, with great rapidity sometimes.

OK, so what do we do about this in Scrum? Well, Scrum does not prescribe any specific method. (That's a good thing, because there are so many situations.)

What I often suggest is this...and it seems to fit many situations well. Let's assume you can determine a dollar amount representing the business value of a release or for the whole project. Then, assign 1,000 (or 10,000) "gummi bears" to all the existing user stories (or the equivalent if your Product Backlog is not in stories). Perhaps reserve some gummi bears for stories yet to be discovered. You might put those BV gummi bear numbers on one corner of each Story Card. (I do not call these BV numbers "Story Points" because too many people understand that term to mean points of size/effort, which is different.)

Then, as each iteration is completed, count the gummi bears "done". Say 100 are done after the first iteration and the total is 10,000. And say that the total business value is $26 million. 100 divided by 10,000 says you have completed 1% of the business value. Or $260,000 in business value (if I did the math right).

It's a good enough approximation for most situations.

The next problem is if total business value changes during the project. Which it always does to some degree. And new business value is discovered (if anyone is paying attention). Usually.

Is that a simple enough answer?

Of course there is much more to say on this topic. I particularly recommend Software by Numbers by Denne and Cleland-Huang.

"Things should be as simple as possible, and not simpler." I think Einstein said that.

Let me deal with one more issue (in this post) that I have often seen. The issue: the Product Owner is not always "good enough". This is always a risk. But, in a way, unavoidable. Someone must be the proxy for our customer set, trying to determine the overall business value of the product (or our change to the product). Scrum prefers, to avoid long delays in making decisions, to name only one Product Owner. Who serves as that customer proxy (in the context I mentioned). Of course, one or more people (perhaps on the team, perhaps not) might still assist that Product Owner in determining the business value.

Just as the one Product Owner can fail, so also can any group of people fail. Scrum has no silver bullet to eliminate failure by people. What it does do is make clear and visible where the (relative) failures are. Often that can allow corrections to be made.

Business Value: Some useful links...

Here are some related links you may find useful...

Marco Abis sent me these links:

http://www.mythodology.com/technicality-business-awareness-now-what

http://www.mythodology.com/why-business-acumen

I like these principles of Lean, especially the first one, about specifying value:
http://www.lean.org/WhatsLean/Principles.cfm#specify

And I like this HBR article by Womack and Jones on Lean Consumption:
http://custom.hbsp.com/b01/en/implicit/custom.jhtml?pr=LEANER0503C2005030462
See what they call the 6 principles of lean consumption. I call 'em a pretty good summary of what people want.

You need to know about Net Present Value. Here's a start. Don't forget the shareholders. They are people too. As are other capital providers.

You need to know about Peter Drucker. Here's a start. See the last bullet in the list of basic ideas. The first phrase was revolutionary in America at the time.

You may also wish to review the first principle of agile, here.

"THERE IS AN OLD SAYING in the media business (at times attributed to David Ogilvy) that your most important assets go down the elevator each night." See here. Don't forget the workers either (and that includes the managers too). Without their many capabilities, nothing would be created.

Business Value: What is it?

On Wednesday, I will lead a session on Business Value in Charlotte, NC. That night the topic will be "what is it?" This is part 1 of the full session I will lead at Agile 2007. (Part 2 in Charlotte will happen on May 24th.)

My hypothesis is that we don't know as much about Business Value as we need to know. And that we are discovering business value all along the way, just as business value is changing. (What? Customers change their minds?)

In that session on Wednesday we will discuss these questions:

1. Why is Business Value important?
2. What is Business Value?
3. Which definitions of Business Value align best with which people?
4. What do customers really want? What did you buy today and why?
5. Does the Business Value of a project ever change? Why? How did you discover that change?
6. Which tools should we use to uncover Business Value?
7. In a project, who should care about Business Value?
8. Does Business Value seem easier or harder now?

To me, this all relates to what Yogi Berra said: "You've got to be very careful if you don't know where you're going, because you might not get there."

Do all the people on your team agree on the definition of business value? Is it tangible to them? Are they always driving toward it (and nothing else)? Or do they, like most humans, say after a few days "what was it you wanted?"

Google, Agile and Business Value

Google announced on 4/20 that it earned $1.002 billion in the first quarter. The Net was up 69% from 2006. See WSJ.com - Google Displays Core Strength*. The sales increase was not too shabby either.

Maybe it's a company we can learn from. (Or maybe they are just lucky.)

Google uses Agile. As I hear, Agile isn't forced on anyone, and many different types of Agile are used. Which, in a way, is agile itself. My hypothesis is that the relationship between Agile and the increased profits is not coincidental.

But that is not my topic for today.

As I hear it, Google takes a very different view of how to use Business Value in its projects. It allows project teams to work on lots of things, as long as someone thinks there is potential of value. The value is not clearly defined upfront. Google gets a beta product in front of the customer world quickly, and gets feedback. After feedback and improvements, if the product has traction (internally and externally) then they release. Only then do they start to worry about monetizing the product (say, Google maps).

Again, they build, and give it away and build market share. And once they have a product that people want, then they figure out how to monetize it.

What's the idea here?

I am guessing the idea goes like this....
1. The first thing is serving the customers.
2. Some products (for Google at least) don't need to bring in money by themselves. They are looked at as filling out a whole customer relationship. It is those customer relationships that become profitable (in multiple ways, if you know how Google makes its money).
3. The first decisions are made by the bright employees deciding how much they want to invest (their own time) in creating or improving the product. My understanding is that each employee is almost an entrepreneur in the way he decides to invest his own time in projects. (I will guess this is something of an exaggeration, but you get the drift.)
4. Then each product team "sells" the product internally and externally, building users and buzz. And perhaps gathering input and more people (workers) for the project (product). So, the key tollgate is "does this product add value for the customer?" Early on, and to some degree later, internal people act as proxies for external customers. But the product is also out quickly to get external customer feedback as well.
5. Then, once they have a released "successful" product (ie, successful to the customers), then they worry about monetizing it (how Google will make money off it). Sometimes those earning are indirect (eg, via ads rather than via license fees to users).

To me, the main lesson here is that Google folks expects to learn along the way what the customers really want. And what business value really is. So they start getting feedback as soon as possible. It's a question of who can learn more useful stuff faster.

What is Business Value? Part 1

I have noticed a bunch of projects lately (mine and those of other people) where the business value is not so clear.

As Yogi Berra said, "If you don't know where you're going, you might not get there."

But what is Business Value? I mean, what is it really?

First, I like the definition of Lean. Value is defined by the end customer. Value becomes meaningful when talking about a specific product that meets a customer’s needs at a specific price at a specific time. (See here: http://www.lean.org/WhatsLean/Principles.cfm#specify)

End customer. So, all the rest of us are just making guesses at what the customer wants. Remarkably, sometimes we are right. And the next sentence is also important. There has to be a context. In fact, I believe the context is much larger and harder to define than this. We buy things based on a conscious or unconscious comparison to all the other things we might buy or do or not do.

For example, when I go to Starbucks for a decaf coffee (don't ask; no, I hardly ever buy a latte), I am implicitly comparing to all the other cool things I could do, places with social scenes, drinks I might have, other bars or coffee houses I have gone to lately.

My main point is business value is complex. And it changes. The customers are changing and my understanding of the customers is hopefully improving along the way. Indeed, I should organize things so that I can experiment with new products, to find out if my hypotheses about the customers were correct. (Yes, Virginia, even end customers can't always explain to you what they really want. Accurately.)

So, with agile project management, we are learning about what the project is and how to do the project and who the team really is. At that same time, the business lead is learning "what really is the business value here".

"As you from crimes would pardon’d be,
Let your indulgence set me free"
- Shakespeare, The Tempest

The business lead must accept the Team is learning, and they must accept that the business lead is learning.

Now, the fact that we are learning does not mean we start with totally sloppy thinking or no thinking. We need to make a relatively quick first estimate (hey, it might even be accurate enough). And then test that. I would not suggest starting a project just on the hunch of a "business lead" who has no track record of successful hunches.

A couple of suggestions:

• Demand to understand the business value of your project (be reasonable in how you put this)
  
• Talk about it (anyone might have a contribution)
  
• Talk about it some more; see if everyone is motivated by the business value as articulated so far
  
• Develop an approach together to getting more confirmation that the business value of your project is really there (Hint: incremental releases might be part of that approach.)
  

We have some more things to say about business value, and then we will talk about the relationship between a SW project and a process.

+ Joe Little