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.

"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.