Optional-Scope Contracts

Optional-Scope Contracts

There are, of course, many different types of project contract. What each type of contract has in common is that it attempts to define the project in terms of the four variables that we introduced earlier: time, effort, scope, and quality. (Cost is often seen as one of these variables , though it is essentially a combination of time and effort.)

Some project bids are won on the basis that we ll do it more cheaply and in less time than our competitors . This usually means that both the cost and deadline are set before we know exactly what needs to be delivered. The result is that postbid negotiations take the form of an almost desperate wrangling of the project scope, where the customer wants as much as possible out of the deal, and the supplier (that s us) tries to cut down the scope as much as possible ”at least to a sensible amount. What if the customer wants to fix scope as well as time? Then you ve got a problem. And in fact the fourth variable, quality, tends to be the one that gets sacrificed.

XP attempts to counter this by using optional-scope contracts. The theory is that the customer will be prepared to sign up for a project that runs for a fixed amount of time for a fixed price, without any commitment as to what is actually delivered. This premise is central to XP. Without an optional-scope contract, where scope is the biggest variable, XP cannot function.

Note that treating scope as the biggest variable is in contrast to Extremo Robert C. Martin s viewpoint, where time is the biggest variable because the schedule doesn t exist per se. So it s interesting that one of the fundamental aspects of XP is open to interpretation (and, in fact, is given conflicting interpretations by its own authors). But it s worth reemphasizing a point we made earlier: Fixed deadlines with variable scope are equivalent to fixed scope with variable deadlines. Phrase it how you will, it s still the same thing: no commitment to being done with a job while meeting a deadline.

start example

For a discussion of these opposing sides of the same coin, see the section But If We Don t Acknowledge the Existence of Deadlines, Nobody Will Force Us to Meet Them, Right? earlier in this chapter.

end example

Whichever rocky road you choose to follow, there are potential pitfalls in contract negotiation. The customer may regard your sales team as slippery because the team members refuse to commit to any sort of concrete plan while apologetically explaining that it s just the way our software process works!

Of course, the supplier can commit to a fixed-scope contract anyway, but then that isn t really XP, and the team would then be better off using a process that s tailored to fixed-scope projects. From Extreme Programming Explained :

XP can accommodate the common forms of contract, albeit with slight modifications. Fixed price/fixed scope contracts, in particular, become fixed price/fixed date/ roughly fixed scope contracts when run with the Planning Game. [13]

This is contrasted with a discussion on the C2 Wiki, [14] in which it s postulated that XP s planning game isn t compatible with fixed-price contracts. The problem is that in the real world (there s that pesky real-world thing again!), management prefers to allocate the budget for a project up front, or it may even decide whether or not to give the go-ahead for the project based on its estimated cost.

This doesn t sit well with XP s plan a bit, estimate a bit/plan a bit more, estimate a bit more system. XP s approach does result in more accurate estimates over time, but at the start of the project, the estimates tend to be way off-target, and it s impossible to know (even at a broad level) how much the project is going to cost.

This is, of course, a problem with agile methods in general, not just XP, because a process that doesn t go to reasonable lengths to pin down the scope of the project just can t be accurately costed up front.

In fact, off-target cost estimates are a notorious problem in traditional software projects as well. It s a thorny issue because software is inherently difficult to predict and estimate. However, Ron Jeffries suggested solution (in the PlanningGame C2 Wiki page referenced earlier) of a paradigm change at the management level wouldn t go down well at most companies ( certainly not at the companies where we ve worked ”or with those companies customers, for that matter). Once again, the pesky real world gets in the way.

Optional-Scope Contract

(Sing to the tune of Octopus s Garden by The Beatles)

I d like to be Coding in C
With the optional-scope contract
That we made

No work gets done
We ll just have fun
We can just eat snack food and get paid
(Just eat snack food and get paid)

Oh we would be so happy, you and me
No management can tell us what to do

I d like to be
Coding in C
With an optional-scope contract
With you

start sidebar
Voice of eXPerience: Stumbling About

by David Van Der Klauw

I was calmly discussing XP with our tracker, MG, and coach, BM. I said I didn t feel that I had learned anything properly while doing pair programming. BM contrasted that he had learned things:

BM: Take SQL Server and stored procedures, for example. Before I came to this team, I knew nothing about them.

Me: Well, could you write me a simple stored procedure that “

BM: No I can t, it s just that I feel that with my partner I would be able to.

Me: Well, what happens if your partner knows as little as you? You d have two people stumbling about and nobody really knowing what he is doing.

MG: Dave that s the whole point ”really knowing. If two people stumbling about is what it takes to write software that meets customer requirements, then that is what we should be doing.

Me: Well, 13 years of software development experience tells me that is not the way to do it.

end sidebar
start sidebar
A Night at the Payroll Project: Optional-Scope Contract Scene

Many people credit Kent Beck with inventing the optional-scope contract, which is a cornerstone of the XP philosophy. Along with the famous statement software is never done, it provides justification for an infinite amount of Constant Refactoring After Programming. But in reality, the optional-scope contract was invented by Groucho Marx in A Night at the Opera . [15]

Here we imagine how it might have been at a seminal moment in history as the world of software engineering became infused with Marxist philosophy.

The setting: Groucho plays Otis P. Extremo, an extreme programmer currently working under contract to provide a replacement payroll system to a major automobile manufacturer. Chico plays Barry GoldOwner, the project sponsor. It s early 1999 and, having realized that the team isn t on the imagined schedule, Extremo is seeking to change the scope of his contract with GoldOwner.

Extremo and GoldOwner are standing next to each other, and each is holding a long scroll of fax paper that has the contract printed on it.

Extremo: Now, this thing here about a weekly payroll . . . YAGNI to that, okay?

GoldOwner: Who sa YAGNI?

Extremo: YAGNI, you know, you aren t gonna need it. YAGNI. Where have you been? Can t they live in Detroit with just the monthly payroll?

GoldOwner: Well, I only getta paid once a month, so I guess that s okay.

Extremo: Fine, fine.

[They each rip a page off the contract.]

Extremo: Now, it says here we ve got to code income tax, and federal tax, and state tax, and city tax, and sewer tax. That s too many taxes. Can t we run this payroll program with fewer taxes than that?

GoldOwner: Well, we could move from taxes to Oklahoma, would that help?

Extremo: No, no, I don t think that would be OK. We only want to code the simplest thing that can possibly work, you know.

GoldOwner: [Suspicious] The simplest thing that can possibly work, huh?

Extremo: Well, you wouldn t want us to code the simplest thing that didn t work, would you?

GoldOwner: [Satisfied] Well, I guess you re-a right . . . [Ripping the contract] yeah, thatsa no good.

Extremo: Fine, now we re getting someplace!

GoldOwner: Where?

Extremo: What?

GoldOwner: Where are we getting?

Extremo: Why, Ypsilanti, of course.

GoldOwner: Why didn t you say so?

Extremo: All right, enough of that ”now look, this bit here about being done before January 2000, that s just the imagined schedule.

GoldOwner: The imagined schedule?

Extremo: Yeah, you know, because the concept of schedule depends upon the notion of doneness.

GoldOwner: Doneness? You mean like a steak . . . medium rare?

Extremo: You do know that software s never done, don t you?

GoldOwner: Oh yah, ha ha ha! [Slaps knee] That sa right, how could I forget. Software s never done. Ha ha. How silly of me. I guess we gotta rip that out too.

Extremo: [Ripping page] But we ve still got a contract, right? No matter how small, it s still a contract, right? So when are you going to have those acceptance tests ready?

GoldOwner: I thought you were gonna do the testing.

Extremo: You don t seriously expect me to do the testing, do you?

GoldOwner: No, I guess not.

Extremo: I should say not! The very idea. Having me do the testing! See, it says right here, acceptance tests are the customer s responsibility. Say, do you smell something?

GoldOwner: You mean your cigar?

Extremo: No, no, not my cigar, something else. . . . It has a delicate fragrance . . . like . . . lavender.

GoldOwner: [Sniffs] No, I just smell your cigar.

Extremo: What about Smalltalk code?

GoldOwner: Does Smalltalk code smell like a big stinky cigar? What sa Smalltalk code?

Extremo: You know, Smalltalk code, don t you have any Smalltalk code?

GoldOwner: C mon . . . what am I gonna do with Smalltalk code?

Extremo: Well, you smell it of course ”how do you think you know if it needs to be refactored? [Exasperated] What are they teaching in school these days? Look, can t you smell?

GoldOwner: I haven t smelled anything yet . . . did you code anything?

Extremo: I didn t code anything worth smelling.

GoldOwner: Well, that s why I didn t smell anything.

Extremo: Well, that s why I didn t code anything.

GoldOwner: That s all right, I fool you ”there were no requirements, anyway.

Extremo: Well, I fooled you, too ”I don t even know how to code.

[They pause and look at each other.]

Extremo: Say, that reminds me, it s time to rotate our pair programmers!

GoldOwner: Why, don t you want em facing the desks?

Extremo: No, you see, we don t want people to get into the habit of pairing together for any length of time, because that way one of them might actually learn what the other one is doing, so we rotate them. It s kind of like changing the tires on your car. Every 30 classes or 10 refactorings we rotate the programmers.

GoldOwner: I get it, you don t want the programmers to get bald. But I still think they oughtta face the keyboards. So, how does that work?

Extremo: You know, the first programmer from the first pair becomes the second programmer of the second pair.

GoldOwner: What about the second programmer?

Extremo: Of the first pair or of the second pair?

GoldOwner: Of the first pair.

Extremo: [Scratches head] Let s see, the, uh, second programmer of the first pair becomes the second programmer of the second pair.

GoldOwner: Whaddya you crazy? You just said the first programmer of the first pair becomes the second programmer of the second pair. You can t have both the first programmer of the first pair and the second programmer of the first pair become the second programmer of the second pair ”there aren t enough chairs at the desk!

Extremo: You know, I never thought of it exactly that way.

GoldOwner: [Smiles] Sure.

Extremo: I guess you re right, I guess the second programmer of the first pair becomes the first programmer of the second pair. Yes, yes, I m sure that s right.

GoldOwner: Now you re talkin . What about the third pair?

Extremo: There are three pairs?

GoldOwner: Sure, because three of a kind always beats two pairs.

Extremo: Finally, we agree on something. Listen, with three pairs it doesn t work. The third pair will have to integrate.

GoldOwner: All day?

Extremo: Sure, why not? It s constant integration, you know. Everything is always integrated.

GoldOwner: Even on Thursday?

Extremo: No, of course not. On Thursday we all play pinball . It s right here in the contract, see?

end sidebar
start sidebar
Fangs Is Running Rampant

SoftwareIsNeverDone. Believe it, and be prepared to renounce the concept of doneness if you decide to try XP. It s a Zen thing: The journey is the reward. Who needs projects to get finished, anyhow?

As soon as deadlines are added to an XP project, time becomes a fixed variable. This can cause time-consuming XP practices (particularly refactoring) to slip, and inevitably code quality suffers.

Because the level of code quality is controlled by the programmers, quality management is never quite under the bourgeois management s control.

end sidebar
start sidebar
The Planning Game Defanged

If software is never done, then most customers would have a serious problem.

Adopting a process that embraces fixed deadlines instead of embracing change is a major step toward reenabling the concept of doneness.

Although changes in requirements can be beneficial (and can even be of major commercial benefit to the customer) and shouldn t be prevented, the likelihood of change can be significantly reduced by improving the up-front requirements elicitation process. Learning to extract the correct requirements from the customer and users, and to validate the requirements in the context of the problems they re trying to solve, reduces the amount of churn due to wrong or misunderstood requirements.

end sidebar

[13] Kent Beck, Extreme Programming Explained: Embrace Change (New York, NY: Addison-Wesley, 2000), p. 159.

[14] See http://c2.com/cgi/wiki?PlanningGame.

[15] If you ve never seen A Night at the Opera , you can enjoy the original classic scene in RealAudio at http://www.nightattheopera.net/nato16.ram.

Extreme Programming Refactored
Extreme Programming Refactored: The Case Against XP
ISBN: 1590590961
EAN: 2147483647
Year: 2003
Pages: 156

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net