Questions about Superman

  1. When Clark Kent changes into his Superman costume, what happens to the suit he was wearing?
    1. Where does he stash the Clark Kent suit?
    2. What does he do with his credit cards, drivers license, cell phone etc.?
  2. Where does Superman live? In an apartment? In what part of town?
    1. He has an even bigger problem getting back home: where does he pick up his suit, and how does change back into it without being noticed?
  3. Does Superman have super pee? Could he fell his enemies with a well-aimed jet of urine?
    1. Is there an opening in his costume for that?
  4. (Don’t even want to think about sex – he could kill somebody.)
  5. We know that Superman is subject to aging, because he was a baby when he arrived on earth and grew into a teenager and then and then a man.
    1. How is dental work done? Does he go to the dentist or the doctor with a tiny bit of kryptonite in his pocket so they can work on him?
  6. When he is in a hurry, does Superman ever break the sound barrier?
    1. If so, does the city council pass an ordinance prohibiting superbooms during the night?

In Scrum, velocity is king. But should it be?

The Sprint

In rugby, “players accelerate over short distances or accelerate and sprint to make position.”1  So in rugby, “sprint” has the common meaning of “run at full speed over a short distance.”

The creators of the Scrum software process, Ken Schwaber and Jeff Sutherland, borrowed the rugby term “sprint” to denote a single software development cycle, usually between one and four weeks long. “We called them [Sprints] because the name evoked a quality of intensity. We were going to work all out for a short period of time and then stop and see where we were.” 2 (emphasis added).


Within a Sprint, the main metric is velocity, the number of story points that can be completed during the iteration.

Sutherland’s book “Scrum” has the subtitle “The art of doing twice the work in half the time.” He is explicit about the primacy of velocity: “… once you have your velocity you can figure out the most important thing in scrum: what is keeping you from going faster? What is keeping you from accelerating?”3 (emphasis added). And since Sutherland believes Scrum to be “the way the tech industry creates new software and products”4, this implies that going faster is the most important thing in software development.

Really? Are you sure?


What if you are working on a self-driving car? Is velocity paramount, or is making sure the vehicle can navigate reliably and avoid hitting people more important?

What about software in fly-by-wire avionics? In medical devices? How about medical coding software? Banking and finance – do we want it done quickly or done right? Machine learning, intelligent systems like IBM’s Watson? Voice recognition? Control systems in refineries and nuclear power plants?

Or take another simple example, medical transcription software. Is speed of development the most important thing, or would it be important to accurately code the algorithms that collect data about the amount of time or the number of words the transcriptionist has accomplished so that she can be paid accurately for her effort? And why wouldn’t this also be true of any algorithm in any software?

And then there is security. Security is hard to begin with, and the bad guys are good at getting past it. Before release and after, every reasonable effort should be made to protect the system, and racing through that part of development might not yield the best defense.

Scrum assumes that quality is a product of velocity: “Scrum teams that work well are able to achieve what we call ‘hyperproductivity’ … They also end up more than doubling the quality of their work.”5 No data is provided to support this assertion, and it sounds like magic thinking. The index of Sutherland’s book contains eight references to velocity and not a single one to quality. Scrum includes several measures of velocity yet not a single measure of quality. And as we know, what gets measured gets done.

The way velocity is measured in scrum also has an insidious and perverse effect. The objective is to complete all story points by the end of the Sprint, which means coded and tested (and thus ready to be shipped). If for any reason the job is not “done” by even the slightest amount the team is penalized all of the story points for that work item for that sprint. In other words, a 1% miss has a 100% cost. This might be useful information for the team, but since these statistics are forwarded to management, there’s obviously a strong incentive to move an item to the “Done” column, regardless.6 It’s not that developers will deliberately take shortcuts and ignore quality. On the contrary, in my experience, software engineers care a great deal about the quality and reliability of their work. That’s what they do, that’s what they love. But given the emphasis on velocity, it only stands to reason that engineers will put “Done” ahead of everything else. Their pay depends on it.

Velocity: a management darling

There is no denying that time to market is important, but it’s hard to make the case that speed is more important than quality in any of the previous examples and many more like them. And why would this not also apply to enterprise software – in fact, to any type of software?

Scrum makes management happy because it

  • is a process that has a name;
  • elevates velocity to the number one objective;
  • promises something called “hyperproductivity”;
  • includes seemingly objective measures of how fast the teams are moving, and
  • implicitly penalizes the team for slips.

No wonder it is popular with managers, and why they are willing to pay for it.

And going all out every sprint is not sustainable. Teams producing software do so 52 weeks a year, year in year out, for decades. Developers may change teams during that time but they are still confronted daily with the same complexity as they were before and with the need to pace themselves. “Marathon” is a better metaphor than “Sprint”. Software development is an intensely intellectual discipline, and expecting a developer to go all out every day, 52 weeks a year is stupid. “Sprint” is the wrong name.

Final note

Compared to Sutherland and his disciples, Schwaber and Beedle seem to have a more realistic view of things, an outlook that is closer to the original principles of the Agile Manifesto.  They emphasize the importance of communicating the reason for a miss to management – and to seek a solution to overcome the deficit – but see the occasional slip as regrettable yet normal given the complexity of the work: “The team was unable to estimate and predict everything that happened during the Sprint. An unexpected thing happened! … In complex technology projects with emerging requirements, you should expect the unexpected. Scrum provides you with direct, immediate visibility into the slip at least every thirty days. At that time, management and the team can collaborate on what should be done next, given the new reality.”7

Agile software development definitely has advantages, but some of the language and notions of Scrum seem odd or even incorrect, especially elevating speed over all other attributes in the development process.

  1.  Duthie, Grant M.; Pyne, David B.; Marsh, Damian J.; Hopper, Sue L. “Sprint Patterns in Rugby Union Players During Competition” Journal of Strength and Conditioning Research, 2006 20(1). pp 208-214.
  2.   Sutherland, Jeff (2014) Scrum. p 73. Crown Business ISBN 978-0-385-34645-0.
  3. Sutherland (2014). p 139.
  4. Sutherland (2014). p vii
  5. Sutherland (2014) p 34.
  6. The drive to “Done” is even more dire since in Scrum the expectation is that teams will improve their velocity forever!
  7. Schwaber, Ken; Beedle, Mike. Agile Software Development with Scrum. p 65. Prentice Hall ISBN 0-13-067-634-9

The Scrum Metaphor in Software Development

File:ST vs Gloucester - Match - 23.JPG
Photo by PierreSelim (Own work) [CC BY-SA 3.0], via Wikimedia Commons

I have copied this picture of a rugby scrum from the Wikipedia article, in case it disappears at some time in the future. The caption is “Luke Burgess introduces the ball into the scrum.” Wikipedia says “A scrum (short for scrummage) is a method of restarting play in rugby that involves players packing closely together with their heads down and attempting to gain possession of the ball.

This rugby scrum is the metaphor for the software development process called Scrum (note the capitalization). It’s hard to pin down how widely Scrum is used, but according to a Harvard Business Review article “Embracing Agile”, “scrum and its derivatives are employed at least five times as often as the other techniques.” So it is prevalent.

According to Jeff Sutherland, co-creator of Scrum with Ken Schwaber, their ideas originally came from “The New New Product Development Game“, a paper by Hirotaka Takeuci and Ikujiro Nonaka in the January 1986 Harvard Business Review. The first paragraph of that paper says: “Companies are increasingly realizing that the old, sequential approach to developing new products simply won’t get the job done. Instead, companies in Japan and the United States are using a holistic method—as in rugby, the ball gets passed within the team as it moves as a unit up the field.”

So that is the origin of the rugby idea.

But “scrum” is a crappy metaphor for software development because it seems to say that the team members must compete to gain possession of – what? The ball? What does that even mean? How could it possibly benefit software development?  Takeuci and Nonaka were interested in the cooperative aspect of a rugby team, so to name a cooperative development process after an event whose key feature is fierce competition seems peculiar to say the least.

And I doubt if most Computer Science students suspect that this is what they are signing up for.

How to resolve “Keyset does not exist” error

A Windows Communication Foundation (WCF) service can use an X.509 certificate for message security with the WSHttp bindings even when the service is not configured for secure transport (https) – in other words, when wshttpBinding.Security.Mode = SecurityMode.Message. In this situation, the WCF application needs to obtain the private key of the certificate. A “Keyset does not exist” error will occur if the Windows account the IIS application is using does not have read permission on the file that contains the private key.


This explanation shows how to correct this error in IIS, but the steps are the same for any WCF application.

The steps to correct this are:

  • Locate the file that contains the private key of the certificate.
  • Grant read permission on the file to the account the IIS application is running under.

You must log on to the IIS server with an account that has administrator privileges to perform these operations.

Locate the private key file

Microsoft provides the Find Private Key Tool ( to find the name and location of the private key file associated with a specific X.509 certificate in the certificate store. FindPrivateKey is included as a C# project in the Windows Communication Foundation Samples, and has to be compiled into FindPrivateKey.exe. I have compiled this and you can download here.

Usage: FindPrivateKey <storeName> <storeLocation> [{ {-n <subjectName>} | {-t <thumbprint>} } [-f | -d | -a]]
 <subjectName> subject name of the certificate
 <thumbprint>  thumbprint of the certificate (use certmgr.exe to get it)
 -f            output file name only
 -d            output directory only
 -a            output absolute file name
 e.g. FindPrivateKey My CurrentUser -n "CN=John Doe"
 e.g. FindPrivateKey My LocalMachine -t "03 33 98 63 d0 47 e7 48 71 33 62 64 76 5c 4c 9d 42 1d 6b 52" -c

For, the FindPrivateKey syntax might be:

FindPrivateKey My LocalMachine –n “”

The output will look something like this:

Private key directory:
 Private key file name:

Grant read permission on the private key file

This operation has has 3 steps:

  1. Determine which Application Pool the Web site is using;
  2. Find the identity of the Application Pool;
  3. Grant read permission on the private key file for the Application Pool identity.

a. Determine which Application Pool the Web site is using.

In Internet Information Services (IIS) Manager, right-click the application and select Manage Applications and then Advanced Settings.

IIS Manager Advanced Settings

Make a note of the Application Pool name. In this example the Application Pool is AppPoolWithCertKeyReadPermission.

Click Cancel to close the dialog.
b. Find the identity of the Application Pool

In IIS Manager, in the Connections pane (left pane), select Application Pools, and make a note of the application pool identity. In this example the identity is ApplicationPoolIdentity. Another common identity is the Network Service account. The identity could also be another built-in account, or a specific user account.

Application Pools
c. Grant read permission on the private key file

In Windows Explorer, locate the private key file that was discovered in part 1. Right-click on the file, select Properties, and then select the Security tab. If you see a dialog like this, click Continue.

Security Dialog

Search for the application pool name using the identity of the application pool or the actual account name, if one was specified. The default account for IIS 7 is Network Service. You may need to select Locations and then select the local computer to limit the search scope.In this example the identity of the AppPoolWithCertKeyReadPermission application pool is ApplicationPoolIdentity, and the syntax would be as shown below (the “IIS AppPool” prefix is mandatory):

IIS AppPoolAppPoolWithCertKeyReadPermission

Check names dialog

Click Check Names.

If the name is found, the dialog will appear as shown below. (If not found, check your typing or verify again the Application Pool identity.)


Click OK to accept the account. By default, Permissions will be set to Read & Execute.


Accept the Permissions by clicking OK.

Your WCF application will no longer throw the “Keyset does not exist” error.