Tuesday, March 25, 2008

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.

Suggested Reading - For 2 CSM courses last week

Here are some of the resources we mentioned in the courses.

Caution: "Words, words, mere words, no matter from the heart." W. Shakespeare. Ground your learning in the heart, and in the fire of experience.

The New New Product Development Game by Takeuchi and Nonaka. Let me ask you to go to www.hbr.com and look it up. It's a Harvard Business Review article. It costs $6 (softcopy). If you need to see it before you buy it, contact me.

The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation by Takeuchi and Nonaka. This is the stepping-stone to their discussion of "Ba".

The Concept of "Ba" by Nonaka and Konno. This article gives an introduction to this subject. "Ba" is the place or context where great teams perform.

Extreme Programming Explained: Embrace Change (2nd Edition) (The XP Series)
by Kent Beck and Cynthia Andres. This may be the best written book on Agile. Certainly XP has a lot to add to the game.

Extreme Programming in Practice
by Newkirk and Martin.

Working Effectively with Legacy Code
by Michael Feathers. Great book if you have to work with legacy code. And who doesn't.

Ssh! We're Adding a Process
by Mark Striebeck at Google. Story of how Ad Words (arguably the highest business value piece of software ever written) adopted Agile/Scrum.

Agile Retrospectives: Making Good Teams Great
by Esther Derby and Diana Larsen. Retrospectives will normally be extremely valuable if you follow their advice. (If you just talk, and take no action, retrospectives could be a waste of time almost.)

Fearless Change: Patterns for Introducing New Ideas
by Mary Lynn Manns and Linda Rising. One could argue that, since Agile is still new, we need these tools to influence others to adopt Agile. I think a better argument is that we need these tools to influence others because we are always learning what Agile really is. Extremely useful book, whether you are a team member, a Product Owner, a ScrumMaster or a manager.

Rolling out Agile in a Large Enterprise by Gabrielle Benefield. This is about Yahoo. Many good suggestions.

Software by Numbers: Low-Risk, High-Return Development by Mark Denne and Jane Cleland-Huang. This book explains what you should go to Minimum Marketable Feature sets to get incremental funding. Or...it pays to go Agile.

The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) by Frederick P. Brooks. It includes the famous essay on No Silver Bullet.

User Stories Applied: For Agile Software Development (The Addison-Wesley Signature Series) by Mike Cohn. Key stuff.

Agile Estimating and Planning (Robert C. Martin Series) by Mike Cohn. Again, key stuff.

* * *
There are many other great resources. This is a start. You may also want to look at earlier posts of this sort. Start here.

Tuesday, March 11, 2008

"How to Tap IT's Hidden Potential"

"How to Tap IT's Hidden Potential" was the title of an article in the WSJ on March 10. Published in collaboration with the MIT Sloan Management Review.

The subhead read: "Too often there's a wall between a company's information-technology department and everything else. That wall must go."

I remember getting a paper back in the 10th grade: "You have a firm grasp of the obvious." I was smart enough then not to feel complimented. (This is perhaps too harsh for these authors; they are raising a very important issue that has not been addressed well enough yet.)

In 1970 Dr. Winston Royce wrote a now-famous article entitled: "Managing the Development of Large Software Systems". Because of this article he is considered the father of "waterfall". One of the top five problems he identified he called (in a positive way): "Involve the Customer". Same basic idea; this was a known problem before 1970. And there have been many surveys of successful projects over the years. One of the top reasons for success always is that the business/customer was more heavily involved.

This gap between IT and the business side is a serious problem, and it is shameful that we (the business community) have not addressed it with much greater success. In my opinion, this is the key reason that we are getting generally a lousy return on our investment in IT. Certainly compared to what we could get. So much so, that management is often so desparate that they use this kind of logic: "Well, it's probably going to fail for $50 million here in the US. Let's ship it to India, where it will fail for $25 million." The logic might be slightly better than that, but not much.

Back now to the WSJ article written by Amit Basu and Chip Jarnagin. So what do they recommend?

  • Begin with IT literacy - and commitment - at the top.
  • Hire an IT leader who sees the big picture.
  • Create demand for IT solutions.
  • Make sure nothing gets lost in translation.
  • Rationalize IT spending.
  • Create an IT portfolio by evaluating risks and returns.

I like some of these ideas. I would put greater emphasis than they did on making these solutions adaptive to change and to learning (they do hint at this). You should read the article. (You may need to join the WSJ online. Or see the comment (below) where the article is available for free.)

But what's missing with these ideas? Well, in general, they are too high-level. What is needed is a way to get business and IT people collaborating in a specific small team that will accomplish a specific mission. Where the rubber meets the road. To me, this is where Scrum helps to solve this problem.

Wednesday, March 5, 2008

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.

Tuesday, March 4, 2008

Suggested Resources for CSM Course NYC Feb 28-29

Here are some of the resources we mentioned in the course.

First, a suggestion and two cautions.
Suggestion: Always tightly link thinking and action.
Caution: "Words, words, mere words, no matter from the heart." W. Shakespeare
Caution 2: "Of making many books there is no end, and much study is a weariness of the flesh." Ecclesiastes 12:12

The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)
by Frederick P. Brooks. It includes the famous essay on No Silver Bullet.

The New New Product Development Game by Takeuchi and Nonaka. Let me ask you to go to www.hbr.com and look it up. It's a Harvard Business Review article. It costs $6 (softcopy). If you need to see it before you buy it, contact me.

Rolling out Agile in a Large Enterprise by Gabrielle Benefield. This is about Yahoo. Many good suggestions.

Software by Numbers: Low-Risk, High-Return Development by Mark Denne and Jane Cleland-Huang. This book explains what you should go to Minimum Marketable Feature sets to get incremental funding. Or...it pays to go Agile.

User Stories Applied: For Agile Software Development (The Addison-Wesley Signature Series) by Mike Cohn. Key stuff.

Agile Estimating and Planning (Robert C. Martin Series) by Mike Cohn. Again, key stuff.

Leading with the Heart: Coach K's Successful Strategies for Basketball, Business, and Life by Mike Krzyzewski and Donald T. Phillips. I live the Duke Blue Devil basketball team. Not surprisingly, I find basketball an apt metaphor for a software development team. Coach K gives a lot of great advice about building a winning team.
The Concept of "Ba" by Nonaka and Konno. This article gives an introduction to this subject.
***
There are many other great resources. This is a start. You may also want to look at earlier posts of this sort. Start here.