Risk management

[Paul Sinnett]

I've just read DeMarco's excellent new book Slack. He devotes several
chapters to the subject of Risk Management. While reading through it struck
me that XP doesn't have a practice that directly deals with risk.

I don't mean that it wouldn't be a risk to try XP with a team. Trying out a
new process is always a risk, and the learning process requires some slack
of it's own.

What I mean is that there isn't anything in the principles or practices of
XP that deals with risk on a project. On the contrary, the XP practices
seem to avoid risk where possible. For example, the principle of you aren't
gonna need it (YAGNI) explicitly avoids all consideration of risk. With
risk management you would be expected to consider how likely it was you
would need it and what impact it would have on the schedule if you did.

In a traditional XP context I guess risk avoidance doesn't really matter.
You are not committing to a certain schedule at the beginning of the
project. You are simply committing to working as fast as you can for as
long as they are willing to continue paying you. The customer takes on all
the risk.

But in my business (games) and (I guess) shrink-wrap software in general,
you are required to take on more risk at the beginning of the project. You
are committing to X features in N months. In fact it's more regimented than
that. In our current projects we are committed to X1 features at the end of
milestone M1, and so on up to the end of the project.

We are not in a position to avoid risk because we are in competition with
other companies who are willing to take that risk on.

So my question is how can risk management be made to work with XP?

[Phlip]

Paul Sinnett wrote:
So my question is how can risk management be made to work with XP?

Someone asked, long ago, on the XP mailing list "What is XP's strategy for
dealing with risk?"

Kent Beck replied "What is a fish's strategy for dealing with water?"

--
Phlip

[Paul Sinnett]

John Roth wrote: "Paul Sinnett" <paul.sinnett@btinternet.com> wrote in message:
While I got a chuckle out of the Kent Beck quote that Phlip mentions, risk management is a serious question.

Thanks for taking the time to respond.
The difficulty is that it comes with a whole lot of unstated assumptions as baggage, one of which is that we can predict the size of the risk, or the effects. That's the same prediction problem that XP is set up to avoid as much as possible. I spent close to two decades in the insurance industry. Even hiding out in the back room, you learn a bit about the industry, and I took all the courses that got to a FLMI. So I think I know something about risk and how to manage it. The insurance industry is based on two simple assumptions: 1) you can't predict any single risk, but you can predict a group of risks. 2) Money fixes all ills. So what's the risk of your supplier not having the new WhizBang Super Whatzit part when your project plan says you're going to need it? Answer. Either they'll deliver a workable part on time, or they won't. If they do, you're in fat city. If they don't, you'd better have a contingency plan. In other words, you'd better know how you're going to deliver your product without the new WhizBang Super Whatzit, on time, within budget and with the features the customer asked for. The lesson here is that you're dealing with one-off problems, where the Law of Large Numbers doesn't apply, and money won't fix it.

But we're not dealing with a single one-off problem. We're dealing with a
whole portfolio of risks that may impact either the scheduled delivery date
or the set of contracted features. If all our possible risks materialise we
won't make it. But we could manage the risk so if only 50% materialise we
will.
In a traditional XP context I guess risk avoidance doesn't really matter. You are not committing to a certain schedule at the beginning of the project. You are simply committing to working as fast as you can for as long as they are willing to continue paying you. The customer takes on all the risk. Not exactly. The risk the customer takes on is that for what he's willing to spend in the time he's willing to spend it, he's not going to get all the glitzy bells and whistles he'd like. If you've got enough time to do more than one delivery, he *will* get a product with useful functionality.

In other words, XP avoids as much risk as possible. What is left is all on
the customers side. And they are therefore responsible for managing it.
But in my business (games) and (I guess) shrink-wrap software in general, you are required to take on more risk at the beginning of the project. You are committing to X features in N months. In fact it's more regimented than that. In our current projects we are committed to X1 features at the end of milestone M1, and so on up to the end of the project. How much of that feature set is really necessary to grab the customer and transfer the $$$ from his wallet to your corporate coffers?

Our customers are generally more the ticks in boxes type rather than
visionary type. Publishers tend to be a bit more flexible, but our current
contract is outsourced from another developer. And those contracts tend to
allow very little negotiation.
The fact is, you don't know, and neither does marketing. You know some things that seem to be necessary, and others that are turnoffs if they're present.

We have what we are contracted to do, and when we are contracted to do them.
We have some ability to negotiate on features and timing as the project
runs along. But in general they want us to stick pretty close to the
contract.
But then, there's always Myst and sequels. It's got astronomical sales figures even though it's not a shooter, it doesn't have a really glitzy 3-d graphics engine, etc. etc. etc.

I haven't had any publishers asking for Myst sequels. Although my company
would certainly consider that kind of thing.
We are not in a position to avoid risk because we are in competition with other companies who are willing to take that risk on. So my question is how can risk management be made to work with XP? What I'm saying is that you can only manage risk if you can define the risks.

Well that's a big part of risk management. After all, you can't manage what
you can't define. But we can certainly define our risks. Maybe we cannot
predict with accuracy their likelyhood or impact but we can get a ballpark
figure.
When you're dealing with one-off risks, the only feasible policy is to avoid them in the first place.

I'm not sure I understand your term 'one-off risk'. Do you mean the combined
risk that we will not complete exactly each contracted feature at its
scheduled time?
That either means that the risk in question won't affect your process (something that XP does well on in a lot of cases) or you put contingency plans in place. In many of those cases the contingency plans should have been "Plan A" in the first place.

But if we do that we aren't taking any risk at all. (Well in theory anyway.)
That would be fine but it's not going to help us get contracts. As I said,
we are competing for contracts with companies who are willing to take more
risk.
The kind of risk you're usually talking about with shrink-wrap (games are a special case of that) is the risk that Marketing has their heads somewhere that isn't very useful. There's nothing you can do about that. If Marketing is actually doing their job, you need to supply them with a stream of products that they can take out to focus groups and other testers and find out how well it meets market demand, and what the next features need to be.

Well sure, but marketing is a publisher side responsibility. In our case the
publisher or external developer is our customer. Certainly we need to take
marketing into account when we are pitching new game ideas. But there are
very few publishers that are currently willing to consider new game ideas
at all at the moment. I think it's currently running at something like 5%.

[Gerold Keefer]

Paul Sinnett wrote:
I've just read DeMarco's excellent new book Slack. He devotes several chapters to the subject of Risk Management. While reading through it struck me that XP doesn't have a practice that directly deals with risk.

yes, they implemented YAGNI ...
[...]
The customer takes on all the risk.

yes, that's what clever consultants do ...
[...]
So my question is how can risk management be made to work with XP?

there are certainly risk-preventing elements in XP that is for the good part,
however, any risk management process, as for example described in my
presentation at
http://www.avoca-vsm.com/Dateien-Download/CmmiRiskManagement.pdf ,
requires a YGNI (ya gonna need it) approach and this is completely out of
synch with XP. this is one reason i recommended risk management for large
project in my paper at
http://www.avoca-vsm.com/Dateien-Download/ExtremeProgramming.pdf .

regards,

gerold

[Paul Sinnett]

Gerold Keefer wrote: So my question is how can risk management be made to work with XP? there are certainly risk-preventing elements in XP that is for the good part, however, any risk management process, as for example described in my presentation at http://www.avoca-vsm.com/Dateien-Download/CmmiRiskManagement.pdf , requires a YGNI (ya gonna need it) approach and this is completely out of synch with XP. this is one reason i recommended risk management for large project in my paper at http://www.avoca-vsm.com/Dateien-Download/ExtremeProgramming.pdf .

But both YAGNI and YGNI are risk avoiding techniques. In the case of YAGNI
you avoid the risk of doing work that isn't needed. In the case of YGNI you
avoid the risk of not doing work that is needed. But where YAGNI takes the
risk away and passes it to the customer, YGNI takes the risk away by adding
to the cost.

Risk management falls somewhere in between these extremes I think. You try
to balance the risk between you, your customer, and the cost.

[Uncle Bob (Robert C. Martin)]

Paul Sinnett <paul.sinnett@btinternet.com> might (or might not) have
written this on (or about) Sun, 06 Jul 2003 13:14:40 +0100, :
I've just read DeMarco's excellent new book Slack. He devotes severalchapters to the subject of Risk Management. While reading through it struckme that XP doesn't have a practice that directly deals with risk.

Yes it does. The practice of choosing business value first deals
directly with risk. The riskiest stories are those that have the
highest bang/buck (i.e. the ones that the customer chooses first). If
we can't do those stories, then we might as well not do the project.

Other things might have technical risk associated with them, but if
they don't carry a lot of business value, then they don't have much
*real* risk.
What I mean is that there isn't anything in the principles or practices ofXP that deals with risk on a project. On the contrary, the XP practicesseem to avoid risk where possible. For example, the principle of you aren'tgonna need it (YAGNI) explicitly avoids all consideration of risk.

Not quite. YAGNI presumes that the risk of creating generalizations
in anticipation of new features is higher than the risk of not
creating those generalizations. YANGI *is* a risk management
technique because is directs us to do the simplest solution first and
*then* generalize it as needed. If the simplest solution turns out to
be wrong, we haven't lost much. But if the generalized solution turns
out to be unnecessary, we've already paid for it and have been
maintaining it all along.
Withrisk management you would be expected to consider how likely it was youwould need it and what impact it would have on the schedule if you did.

Exactly. That's precisely what the planning game does.
In a traditional XP context I guess risk avoidance doesn't really matter.You are not committing to a certain schedule at the beginning of theproject. You are simply committing to working as fast as you can for aslong as they are willing to continue paying you. The customer takes on allthe risk.

You can do XP with fixed bid contracts, or share-the-risk contracts
too. The customer does not have to shoulder all the risk.

XP allows the risk to be managed because there is never any doubt
about the state of the project. Each iteration completes with more
working code. We know how fast we are going, and we know how much is
done.But in my business (games) and (I guess) shrink-wrap software in general,you are required to take on more risk at the beginning of the project. Youare committing to X features in N months. In fact it's more regimented thanthat. In our current projects we are committed to X1 features at the end ofmilestone M1, and so on up to the end of the project.

And you always make it?
We are not in a position to avoid risk because we are in competition withother companies who are willing to take that risk on.

You must take on the risk, and then you must manage that risk.So my question is how can risk management be made to work with XP?

"XP *is* a risk management strategy." -- Kent Beck.



Robert C. Martin | "Uncle Bob"
Object Mentor Inc.| unclebob @ objectmentor . com
PO Box 5757 | Tel: (800) 338-6716
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python |

[Paul Sinnett]

Uncle Bob (Robert C. Martin) wrote: Paul Sinnett <paul.sinnett@btinternet.com>:I've just read DeMarco's excellent new book Slack. He devotes severalchapters to the subject of Risk Management. While reading through itstruck me that XP doesn't have a practice that directly deals with risk. Yes it does. The practice of choosing business value first deals directly with risk. The riskiest stories are those that have the highest bang/buck (i.e. the ones that the customer chooses first). If we can't do those stories, then we might as well not do the project. Other things might have technical risk associated with them, but if they don't carry a lot of business value, then they don't have much *real* risk.

But can't you have a high value story with a low risk and vice versa?
I can imagine that in an XP context, where you could be stopped at any
iteration, all high value stories must also be high risk stories. But
that's not the case with a fixed bid contract.
What I mean is that there isn't anything in the principles or practices ofXP that deals with risk on a project. On the contrary, the XP practicesseem to avoid risk where possible. For example, the principle of youaren't gonna need it (YAGNI) explicitly avoids all consideration of risk. Not quite. YAGNI presumes that the risk of creating generalizations in anticipation of new features is higher than the risk of not creating those generalizations. YANGI *is* a risk management technique because is directs us to do the simplest solution first and *then* generalize it as needed. If the simplest solution turns out to be wrong, we haven't lost much. But if the generalized solution turns out to be unnecessary, we've already paid for it and have been maintaining it all along.

What you have described is avoiding risk rather than managing risk. In
managing risk you identify the potential need for the generalisation ahead
of time. Then you estimate its probability and impact. When you consider
the cost, you decide how much risk you are willing to take, and add
mitigation for the rest to the schedule.

With YAGNI you simply assume that the risk won't materialise and so all that
cost is transfered to the customer. You have not managed the amount of risk
you are willing to take other than to avoid all risk and pass it to the
customer.
Withrisk management you would be expected to consider how likely it was youwould need it and what impact it would have on the schedule if you did. Exactly. That's precisely what the planning game does.

I thought the planning game was there for the customer to pick which
features go into the next iteration. Where are risks considered? Is it a
special kind of user story?

I'm going to give an example in a game context so I can get my head round
it. Let's say in our next iteration the customer wants us to add the
playback of sound effects to our game engine. We consider this task, and
estimate that there is a 50% risk that (depending on the number of sounds,
their length, their quality, and so on) we might use more memory than is
available in the runtime memory heap. We estimate that if this risk
materialises we will have to spend an extra couple of days either reducing
the memory load of the other systems, or compressing the sound effects, or
reducing the quality... etc.

Where in the planning game do we handle that? And who decides how much risk
each party is expected to assume?
You can do XP with fixed bid contracts, or share-the-risk contracts too. The customer does not have to shoulder all the risk.

In XP explained Kent had this to say:

"The biggest barrier to the success of an XP project is culture. ... Any
business that runs projects by trying to point the car in the right
direction is going to have a rough time with a team that insists on
steering.
A variant of 'pointing the car' is the big specification."

How do XP teams deal with this friction in fixed bid contracts?
But in my business (games) and (I guess) shrink-wrap software in general,you are required to take on more risk at the beginning of the project. Youare committing to X features in N months. In fact it's more regimentedthan that. In our current projects we are committed to X1 features at theend of milestone M1, and so on up to the end of the project. And you always make it?

No. Although we are usually close either side even if we don't hit it
exactly. And that allows us to negotiate a bit on the milestone.

On occasion we are wide of the mark but that's the risk we take.
We are not in a position to avoid risk because we are in competition withother companies who are willing to take that risk on. You must take on the risk, and then you must manage that risk.

Indeed.
So my question is how can risk management be made to work with XP? "XP *is* a risk management strategy." -- Kent Beck.

Then how do the developer and the customer balance how much risk each of
them take on?

[Uncle Bob (Robert C. Martin)]

Paul Sinnett <paul.sinnett@btinternet.com> might (or might not) have
written this on (or about) Mon, 07 Jul 2003 02:55:42 +0100, :
Uncle Bob (Robert C. Martin) wrote: Paul Sinnett <paul.sinnett@btinternet.com>:I've just read DeMarco's excellent new book Slack. He devotes severalchapters to the subject of Risk Management. While reading through itstruck me that XP doesn't have a practice that directly deals with risk. Yes it does. The practice of choosing business value first deals directly with risk. The riskiest stories are those that have the highest bang/buck (i.e. the ones that the customer chooses first). If we can't do those stories, then we might as well not do the project. Other things might have technical risk associated with them, but if they don't carry a lot of business value, then they don't have much *real* risk.But can't you have a high value story with a low risk and vice versa?

If you define risk in terms of business value (the only meaningful
definition IMHO) then the answer is no. It's only those stories that
have high business value that can have high risk.

Technical risk is real, but must be weighed against business value.
If a given feature has high technical risk, but low business value,
then the overall risk is low and it shouldn't be made a priority.
I can imagine that in an XP context, where you could be stopped at anyiteration, all high value stories must also be high risk stories. Butthat's not the case with a fixed bid contract.

Yes it is. A fixed bid is a weak facade. Most customers are willing
to negotiate after the bid.What you have described is avoiding risk rather than managing risk.

Avoiding risk is a good way to manage risk.
Inmanaging risk you identify the potential need for the generalisation aheadof time. Then you estimate its probability and impact. When you considerthe cost, you decide how much risk you are willing to take, and addmitigation for the rest to the schedule.

And then you still implement the simplest solution possible and evolve
it towards needed generality, because that's the lowest risk, and
least expensive, way to get what you need.
With YAGNI you simply assume that the risk won't materialise and so all thatcost is transfered to the customer.

No, you assume that the cost deal with the materialized risk is lower
once you have a working system.
You have not managed the amount of riskyou are willing to take other than to avoid all risk and pass it to thecustomer.

Working software always lowers risk. Once the customer seen some of
the software working, they know the risk of getting the rest is
lowered. We don't pass the risk to the customer, we lower the risk to
the customer by delivering working software frequently.

Perhaps you are thinking that the cost of frequent delivery is higher
than the cost of anticipatory design. That may be true in some cases,
though I doubt it. In any case it is much better to *know* the state
of the project by seeing regularly delivered working software, than it
is to be told that everything is OK without seeing working software.
The risk of cancellation is much higher when you don't deliver early
and often. So is the risk of delivering something that the customer
doesn't want (even if it matches the requirements).Withrisk management you would be expected to consider how likely it was youwould need it and what impact it would have on the schedule if you did. Exactly. That's precisely what the planning game does.I thought the planning game was there for the customer to pick whichfeatures go into the next iteration. Where are risks considered? Is it aspecial kind of user story?

No. The customer simply decides which stories should be implemented
next. That *is* risk management. The customer knows the cost of the
stories, and the business value. He weighs those two factors and
decides the priority.
I'm going to give an example in a game context so I can get my head roundit. Let's say in our next iteration the customer wants us to add theplayback of sound effects to our game engine. We consider this task, andestimate that there is a 50% risk that (depending on the number of sounds,their length, their quality, and so on) we might use more memory than isavailable in the runtime memory heap. We estimate that if this riskmaterialises we will have to spend an extra couple of days either reducingthe memory load of the other systems, or compressing the sound effects, orreducing the quality... etc.Where in the planning game do we handle that? And who decides how much riskeach party is expected to assume?

The estimate on the story card will be high. When the customer asks
why, you explain these risk to him. Then you say: "But we can reduce
the uncertainty by doing a one day spike to figure out whether we can
fit this in memory or not. If we can, then we can reduce the cost of
the story." The customer gets to decide whether to take the risk on
the high cost story, or to authorize the spike to lessen the
uncertainty. You can do XP with fixed bid contracts, or share-the-risk contracts too. The customer does not have to shoulder all the risk.In XP explained Kent had this to say: "The biggest barrier to the success of an XP project is culture. ... Anybusiness that runs projects by trying to point the car in the rightdirection is going to have a rough time with a team that insists onsteering. A variant of 'pointing the car' is the big specification."How do XP teams deal with this friction in fixed bid contracts?

The same way everybody else does. They estimate the project, figure
out a price that they think is realistic, and bid. If they are lucky,
they can run a couple of iterations first, and calculate their
velocity. That'll help set the bid. If they are even luckier, they
can convince the customer to pay for delivered story points.
But in my business (games) and (I guess) shrink-wrap software in general,you are required to take on more risk at the beginning of the project. Youare committing to X features in N months. In fact it's more regimentedthan that. In our current projects we are committed to X1 features at theend of milestone M1, and so on up to the end of the project. And you always make it?No. Although we are usually close either side even if we don't hit itexactly. And that allows us to negotiate a bit on the milestone.

How do you get close? Do you cut scope, take technical shortcuts,
abandon process during the crunch, triple your estimates, work lots of
overtime?Then how do the developer and the customer balance how much risk each ofthem take on?

I happen to like the model where you work at a small T&M rate, and get
paid nice balloons for story points delivered. It's a nice share the
risk strategy. If you deliver slowly, the customer only pays the low
T&M rate. If you deliver quickly, your effective hourly rate is very
high. The risk is shared.



Robert C. Martin | "Uncle Bob"
Object Mentor Inc.| unclebob @ objectmentor . com
PO Box 5757 | Tel: (800) 338-6716
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python |

[Paul Sinnett]

Uncle Bob (Robert C. Martin) wrote: Paul Sinnett <paul.sinnett@btinternet.com> might (or might not) haveBut can't you have a high value story with a low risk and vice versa? If you define risk in terms of business value (the only meaningful definition IMHO) then the answer is no. It's only those stories that have high business value that can have high risk.

Then how would you define risk in terms of business value:

r = bv?
r = k * bv?

That would deny the reality of items with high business value and low
risk. Which would be a shame since these items are the best of both worlds.
Technical risk is real, but must be weighed against business value. If a given feature has high technical risk, but low business value, then the overall risk is low and it shouldn't be made a priority.

What do you mean by the overall risk?

[Rich]

Paul Sinnett <ps@coyotedev.com> wrote in
news:3F096DC8.1000309@coyotedev.com:
Uncle Bob (Robert C. Martin) wrote: Paul Sinnett <paul.sinnett@btinternet.com> might (or might not) haveBut can't you have a high value story with a low risk and vice versa? If you define risk in terms of business value (the only meaningful definition IMHO) then the answer is no. It's only those stories that have high business value that can have high risk. Then how would you define risk in terms of business value: r = bv? r = k * bv? That would deny the reality of items with high business value and low risk. Which would be a shame since these items are the best of both worlds.
Perhaps I'm a bit dense this morning, but you seem to be missing the
point: Nobody is suggesting that there are no high business value
features with low risk. These are a no-brainer. As you say, "the best
of both worlds".

Rather, the claim is that items with low business value and high risk
are irrelevent. The customer may choose to not bother with that
particular story (risk avoidance) or they may choose to go ahead anyway
since if it fails, they still have *all* the higher priority features
already delivered (risk is mitigated by running code)
Technical risk is real, but must be weighed against business value. If a given feature has high technical risk, but low business value, then the overall risk is low and it shouldn't be made a priority. What do you mean by the overall risk?

I take it as the overall risk to the project as a whole. Losing this
one low business value feature will not have a significant impact on the
project regardless of how high the technical risk of delivering the
feature may be.

[Paul Sinnett]

Rich wrote: Paul Sinnett <ps@coyotedev.com> wrote: Uncle Bob (Robert C. Martin) wrote: Paul Sinnett <paul.sinnett@btinternet.com> :>But can't you have a high value story with a low risk and vice versa? If you define risk in terms of business value (the only meaningful definition IMHO) then the answer is no. It's only those stories that have high business value that can have high risk. Then how would you define risk in terms of business value: r = bv? r = k * bv? That would deny the reality of items with high business value and low risk. Which would be a shame since these items are the best of both worlds. Perhaps I'm a bit dense this morning, but you seem to be missing the point: Nobody is suggesting that there are no high business value features with low risk.

Well maybe I'm reading this wrong but isn't that what Bob wrote above?

I mean, I asked him. And he said no. I thought I'd ask for a bit of
clarification because it did seem a bit odd.
Rather, the claim is that items with low business value and high risk are irrelevent.

Well that's up to the customer isn't it? I mean if it were irrelevant to the
customer they wouldn't have brought it up at all would they?
The customer may choose to not bother with that particular story (risk avoidance) or they may choose to go ahead anyway since if it fails, they still have *all* the higher priority features already delivered (risk is mitigated by running code)

Very true. This is what I suggested earlier. The customer takes on all the
responsibility for the risk.
Technical risk is real, but must be weighed against business value. If a given feature has high technical risk, but low business value, then the overall risk is low and it shouldn't be made a priority. What do you mean by the overall risk? I take it as the overall risk to the project as a whole. Losing this one low business value feature will not have a significant impact on the project regardless of how high the technical risk of delivering the feature may be.

Okay, that sounds reasonable, but... If we take Bob's equation from his
follow-up post:

OverallRisk = BusinessValue * TechnicalRisk

then his overall risk for a low * high task is more than that of a low * low
task. So by this measure our customer should favour the high risk over the
lower?

[Paul Sinnett]

Uncle Bob (Robert C. Martin) wrote: Paul Sinnett <ps@coyotedev.com>:Uncle Bob (Robert C. Martin) wrote: If you define risk in terms of business value (the only meaningful definition IMHO) then the answer is no. It's only those stories that have high business value that can have high risk.Then how would you define risk in terms of business value:r = bv?r = k * bv? Something like OverallRisk = BusinessValue * TechnicalRisk. Truly high risk requires both high business value AND high technical risk.

But by this LowBV * HighTR = HighBV * LowTR in terms of overall risk. Is
this really the kind of equation you were looking for?

I think the problem might be that you are trying to define risk in terms of
risk - that is, your definition is recursive. Perhaps?

[Laurent Bossavit]

> So my question is how can risk management be made to work with XP?

I did a quick brush-up on "risk management". It hasn't changed too much
since I last got an interest in the topic. I'm an XPer, but I like to
think of myself as minimally risk-savvy and consciously use risk
management on projects.

The memes I've got installed at the moment, whether they are useful or
not, run more or less as follows.

Risk is basically the problem of not having facts about the future. At
best we have facts about the past. Risks are undesirable things that
might happen in the future, and we have no way to tell which of these
things will or will not happen.

A project consists *essentially* of the statement that a given desirable
future will come about. Thus a project is risky through and through :
there are many more undesirable things that can happen than desirable
ones. There is less risk in maintaining a desirable status quo than in
bringing about a new state of affairs.

Any structured, deliberate approach to doing something already
constitutes risk management. Driving with both hands on the wheels is
managing the risk of being involved in a car collision; so are putting on
a seat belt or buying a car with air bags. Extreme Programming contains
provisions for certain risks, which might or might not be the risks which
affect your project.

You cannot address unspecified risks, or "all risks". You might be hit by
a meteorite tomorrow, or you might lose your job. If your circumstances
are anything like mine, protecting your job takes priority. Risks are
prioritized by, roughly, likelihood of occurrence times damage done if
risk materializes. Let's say that your greatest risk is "We might not
meet milestone M with feature set F as scheduled." There is a broad
palette of risk tactics for each specific risk.

Risk avoidance: I don't think XP "avoids" risk at all. Risk is avoided by
obviating the possibility that the undesirable event will happen. You
refuse to commit to meeting milestone M by feature F - don't sign the
contract until the software is done. This avoids the risk. As long as you
enter into the contract to deliver specific scope by a specific date, the
risk that it won't come about exists.

Risk reduction: this consists of minimizing the likelihood of the
undesirable event. XP reduces the likelihood that you will lack some
features at each milestone by reducing the amount of "extra" work to be
done, such as paperwork or documentation, and improving overall quality
so as to make development faster.

Risk mitigation: this consists of minimizing the impact of the
undesirable event. XP has active mitigation for the "schedule risk", by
insisting that the most valuable features be done first; this reduces the
likelihood that *important* features will be left out of milestone M.

Risk acceptance: just grit your teeth and take your beating. So we're
missing feature F by milestone M - we'll ship with what we have by that
date. After reduction and mitigation, XP manages any residual risk this
way.

Risk transfer: this consists of getting someone else to take the risk in
your place. Insurance is a risk transfer tactic. You pay a definite,
known-with-certainty amount of money; the insurer will reimburse you if
the risk of not completing feature F by milestone M materializes. No
provision in XP. *Has* anyone ever insured a software project against
schedule/budget overrun ?

Contingency planning: substituting one risk for another, so that if the
undesirable event occurs you have a "Plan B" which can compensate for the
ill consequences. If we miss critical milestone M1 with feature set F1,
we'll shelve the project and reassing all resources to our back-burner
project which is currently being worked on by interns.

Key point from all the above: risk management starts with identifying
*specific* risks. Also, I think you can perform conscious risk management
using *any* process, method, technique or approach. It's important to
recognize that any process, etc. simply *changes* the risk landscape;
your project will always have one single biggest risk, then a second
biggest risk, and so on.

Risk management is like feedback. If you're not going to pay attention to
it, you're wasting your time. More than once I've tried to adopt a risk-
oriented approach to projects, only to have management react something
like, "Oh, you think that's a risk. Well, thank you for telling us. We're
happy to have had that risk reduced. Now proceed as before."

One risk I often raise in projects is skills risk. Developers are
supposed to crank out Java code who have only ever written Visual Basic,
that sort of thing. Not once have I seen a response of risk avoidance
(substituting other, trained team members for the unskilled ones),
reduction (training the worker in Java), or mitigation (making provision
for closer review of the person's code). It's always been acceptance -
"We know it's less than ideal to have this guy working on that project,
but he's what we've got at the moment." If you only ever have one tactic
for dealing with risk, your risk "management" is a no-brainer.

[Paul Sinnett]

Uncle Bob (Robert C. Martin) wrote: Paul Sinnett <paul.sinnett@btinternet.com>: What you have described is avoiding risk rather than managing risk. Avoiding risk is a good way to manage risk.

You must take on risk in order to manage risk. You don't take on any risk if
you avoid it: by definition, you have no risk to manage.
In managing risk you identify the potential need for the generalisation ahead of time. Then you estimate its probability and impact. When you consider the cost, you decide how much risk you are willing to take, and add mitigation for the rest to the schedule. And then you still implement the simplest solution possible and evolve it towards needed generality, because that's the lowest risk, and least expensive, way to get what you need.

Your logic troubles me. If the lowest risk is also the least expensive why
would anyone take a more expensive and / or higher risk approach? Given any
low risk scenario there must be a way to cut a corner and thus reduce cost.
Sure it's risky to do that. But that's what we're talking about isn't it?

[Paul Sinnett]

Laurent Bossavit wrote: So my question is how can risk management be made to work with XP? I did a quick brush-up on "risk management". It hasn't changed too much since I last got an interest in the topic. I'm an XPer, but I like to think of myself as minimally risk-savvy and consciously use risk management on projects.

Thank you Laurent, for taking the time to respond.
Any structured, deliberate approach to doing something already constitutes risk management. Driving with both hands on the wheels is managing the risk of being involved in a car collision; so are putting on a seat belt or buying a car with air bags. Extreme Programming contains provisions for certain risks, which might or might not be the risks which affect your project.

Indeed. The risks that are most important to our projects are those that
impact our ability to deliver to a contract.
Risk avoidance: I don't think XP "avoids" risk at all. Risk is avoided by obviating the possibility that the undesirable event will happen. You refuse to commit to meeting milestone M by feature F - don't sign the contract until the software is done. This avoids the risk. As long as you enter into the contract to deliver specific scope by a specific date, the risk that it won't come about exists.

Hm. But as I understand it, an XP team doesn't contract to deliver specific
scope by a specific date. Instead they contract to deliver a variable scope
by a specific date. I also don't think XP avoids all risk, but I do think
it takes risk away from the developers and gives it to the customers.
Albeit risk that the developers should not have to assume. And I think it's
right to do that. After all, who is better at managing their own risks than
the customers themselves.

However, not all customers are willing to take on such risks. In my
industry, the games industry, the customers aren't willing to take on much
risk at all. And with the cost of development rising all the time it is
understandable.

This presents us, as developers, with an opportunity to capitalise on the
situation. If we are willing to assume a little more of the customer's risk
than we perhaps should, then we can improve our chances of getting better
contracts.

It reminds me of poker: you play tight at a loose table and loose at a tight
table. For us (in games) we are most definitely playing at a tight table.
But perhaps for the sort of projects that XP grew up on, the developers
were playing at a loose table?

I guess this would explain Kent's attitude in the introduction to XPE:

"What us XP? XP is a lightweight, efficient, low-risk, flexible,
predictable, scientific, and fun way to develop software."

"The basic problem of software development is risk."

"If we accept project risk as the problem to be solved, where are we going
to look for the solution?"

and so on.

[Phlip]

Uncle Bob (Robert C. Martin) wrote:
Phlip didn't quite get the story right. Someone asked Kent: "What's XP's risk management strategy?" Kent responded: "That's like asking a fish what it's water strategy is. A fish *is* a water strategy. Likewise, XP *is* a risk management strategy."

Ain't it cool that Google can finally spider old Yahoo Groups posts?!

That ain't the exact quote either, but screw it; we were both close enough.

I also found this great quote on a marginally related Web site:

"Now leave us, and take your fish with you." --Faramir

--
Phlip
http://www.c2.com/cgi/wiki?TestFirstUserInterfaces

[Laurent Bossavit]

> I also don't think XP avoids all risk, but I do think it takes risk away from the developers and gives it to the customers.

For my money, this is a quibble. Aren't customers and developers in the
same boat - employed by the same company, and equally apt to suffer
should the game not be published with an adequate feature set ? Or am I
misunderstanding who your "customers" refers to ?
However, not all customers are willing to take on such risks. In my industry, the games industry, the customers aren't willing to take on much risk at all.

Again, I'm probably misunderstanding something. It was my impression that
game projects got cancelled, shipped late or flopped frequently enough.

[Uncle Bob (Robert C. Martin)]

Paul Sinnett <paul.sinnett@btinternet.com> might (or might not) have
written this on (or about) Mon, 07 Jul 2003 22:28:41 +0100, :
Rich wrote: Paul Sinnett <ps@coyotedev.com> wrote: Uncle Bob (Robert C. Martin) wrote:> Paul Sinnett <paul.sinnett@btinternet.com> :>>But can't you have a high value story with a low risk and vice versa?>> If you define risk in terms of business value (the only meaningful> definition IMHO) then the answer is no. It's only those stories> that have high business value that can have high risk. Then how would you define risk in terms of business value: r = bv? r = k * bv? That would deny the reality of items with high business value and low risk. Which would be a shame since these items are the best of both worlds. Perhaps I'm a bit dense this morning, but you seem to be missing the point: Nobody is suggesting that there are no high business value features with low risk.Well maybe I'm reading this wrong but isn't that what Bob wrote above?I mean, I asked him. And he said no. I thought I'd ask for a bit ofclarification because it did seem a bit odd.

Consider a story whose business value is $100,000 per day. That is,
if this story is running in the system, we earn a hundred grand every
day. Imagine this conversation:

Customer: "Can you do this story."
Developer:"Sure, no problem."
C: "When can you get it done?"
D: "Two or three weeks."
C: So there's $700K at risk.

High business value and low technical risk can still translate to high
overall risk. The developer may look at the story and be absolutely
sure that he can get it done. Yet even a delay of a day costs an
extra $100K.

Having said that, it is certainly true that there are high business
value stories that have very low overall risk. My point is that
accounting for the risk is not something that is intuitive to
developers, and usually has much more to do with business value than
with technical risk. Therefore developers should not be the primary
risk managers.
If we take Bob's equation from hisfollow-up post:OverallRisk = BusinessValue * TechnicalRiskthen his overall risk for a low * high task is more than that of a low * lowtask. So by this measure our customer should favour the high risk over thelower?

I have two stories. Each will generate $100/day once implemented.
The developers are sure they can get story A done in 5 days. They
aren't sure about B though. B might take 3-7 days. Which would you
do first in order to maximize revenue?





Robert C. Martin | "Uncle Bob"
Object Mentor Inc.| unclebob @ objectmentor . com
PO Box 5757 | Tel: (800) 338-6716
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python |

[Uncle Bob (Robert C. Martin)]

Paul Sinnett <paul.sinnett@btinternet.com> might (or might not) have
written this on (or about) Mon, 07 Jul 2003 23:48:53 +0100, :
Uncle Bob (Robert C. Martin) wrote: Paul Sinnett <paul.sinnett@btinternet.com>: What you have described is avoiding risk rather than managing risk. Avoiding risk is a good way to manage risk.You must take on risk in order to manage risk. You don't take on any risk ifyou avoid it: by definition, you have no risk to manage. In managing risk you identify the potential need for the generalisation ahead of time. Then you estimate its probability and impact. When you consider the cost, you decide how much risk you are willing to take, and add mitigation for the rest to the schedule. And then you still implement the simplest solution possible and evolve it towards needed generality, because that's the lowest risk, and least expensive, way to get what you need.Your logic troubles me. If the lowest risk is also the least expensive whywould anyone take a more expensive and / or higher risk approach?

Time pressure, or any other case of inadequate resources. If you
don't have enough resources to be safe, then you have to take on risk.

So, If I have two stories that each earn $100/day, and if one can be
implemented in 5 days, but the other is riskier and might take 3-7
days. Then if I am under time pressure I will opt for the riskier
story because it might save my bacon. On the other hand, if I am not
under time pressure, I'll opt for the safe story because it doesn't
runt the risk of delaying revenue.
Given anylow risk scenario there must be a way to cut a corner and thus reduce cost.Sure it's risky to do that. But that's what we're talking about isn't it?

Cut a corner? No, not that. There is no way to win if you cut
corners. No matter how much pressure you are under, cutting corners
always spells failure. Software systems are too complex to tolerate
corner cutting.

In most cases, even under extreme resource pressure, it is hard to
come up with a better strategy than delivering the most business value
as early as possible.

Robert C. Martin | "Uncle Bob"
Object Mentor Inc.| unclebob @ objectmentor . com
PO Box 5757 | Tel: (800) 338-6716
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python |

[Uncle Bob (Robert C. Martin)]

Laurent Bossavit <laurent.ng@bossavit.com> might (or might not) have
written this on (or about) Tue, 8 Jul 2003 00:05:26 +0200, :
Risk transfer: this consists of getting someone else to take the risk inyour place. Insurance is a risk transfer tactic. You pay a definite,known-with-certainty amount of money; the insurer will reimburse you ifthe risk of not completing feature F by milestone M materializes. Noprovision in XP. *Has* anyone ever insured a software project againstschedule/budget overrun ?

T&M is a risk transfer strategy.



Robert C. Martin | "Uncle Bob"
Object Mentor Inc.| unclebob @ objectmentor . com
PO Box 5757 | Tel: (800) 338-6716
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python |

[Uncle Bob (Robert C. Martin)]

Paul Sinnett <paul.sinnett@btinternet.com> might (or might not) have
written this on (or about) Tue, 08 Jul 2003 01:45:46 +0100, :
I also don't think XP avoids all risk, but I do thinkit takes risk away from the developers and gives it to the customers.

The use of XP need have no impact upon the nature of the contract.
You can use XP to manage internal risk, and still write the contract
any way you like. XP does not imply variable scope contracts.

Having said that. I don't believe that there is any other kind of
contract, really. I think that all fixed bid contracts are really
variable scope contracts in sheeps clothing. Every fixed-bid contract
I've participated in had clauses that allowed the customer to submit
change orders that were paid at T&M rates. It almost never fails that
by the end of the project the change orders are the lion's share of
the work.





Robert C. Martin | "Uncle Bob"
Object Mentor Inc.| unclebob @ objectmentor . com
PO Box 5757 | Tel: (800) 338-6716
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python |

[Laurent Bossavit]

> >the risk of not completing feature F by milestone M materializes. Noprovision in XP. *Has* anyone ever insured a software project againstschedule/budget overrun ? T&M is a risk transfer strategy.

I doubt it. My reasoning is as follows : you contract for $1M of software
to be written, that will make a cash flow for you with NPV of, say, $2M.
If delivery is late and/or unusable - the risk has materialized - you
only have the option of not paying the $1M. The remaining $1M is not
insured; *that* risk is not transferred.

Am I making any sense ?

[Paul Sinnett]

Uncle Bob (Robert C. Martin) wrote: Consider a story whose business value is $100,000 per day. That is, if this story is running in the system, we earn a hundred grand every day. Imagine this conversation: Customer: "Can you do this story." Developer:"Sure, no problem." C: "When can you get it done?" D: "Two or three weeks." C: So there's $700K at risk.

No there isn't. There's $700K to be won but you're not risking anything. The
worst that can happen here is nothing at all. Nothing ventured, nothing
gained. We'll have to make this example more contrived if we want to get a
risk in there somewhere.
I have two stories. Each will generate $100/day once implemented. The developers are sure they can get story A done in 5 days. They aren't sure about B though. B might take 3-7 days. Which would you do first in order to maximize revenue?

Assuming a simple distribution of probability eg. task B has a 0%
probability of completing in 3 days rising to 50% by 5 days and 100% by 7
days. Also assuming that the ability to generate revenue expires in 14 days
(to ensure that there is some element of risk involved). Then it makes no
difference to our probable revenue which we do first: in either case it is
$1,300.

B first, then A = $1,300 +/- $400
A first, then B = $1,300 +/- $200

However, if we did B first we could make up to $1,700 where if we did A
first we could only make up to $1,500. But at the other end, if we do A
first we are guaranteed at least $1,100 whereas if we do B first are only
guaranteed at least $900.

So finally, we now have a choice between higher and lower risk. To maximise
revenue we would do B first. To minimise risk we would do A first.

[Paul Sinnett]

Uncle Bob (Robert C. Martin) wrote: Paul Sinnett <paul.sinnett@btinternet.com> : Given any low risk scenario there must be a way to cut a corner and thus reduce cost. Sure it's risky to do that. But that's what we're talking about isn't it? Cut a corner? No, not that. There is no way to win if you cut corners. No matter how much pressure you are under, cutting corners always spells failure. Software systems are too complex to tolerate corner cutting.

No, not the corner! Arrrrgh!

Whatever do you think I mean by cutting corners? Anyone would think that I
had suggested some awful programming horror such as not making an abstract
base class for an employee object in anticipation of future changes ;-)

I agree with you about pressure though. It's not a good idea to be taking
risks under pressure.

[Phlip]

Laurent Bossavit wrote:
UncBob: T&M is a risk transfer strategy. Uh, wait. I have hallucinated reading "fixed fee is a risk transfer strategy" and responded to that. What you actually wrote was "T&M is a risk transfer strategy". I'm assuming you meant "time and materials". I am unable to understand *that* at all, much less frame a cogent reply.

Think in terms of value flow, not static values. T&M represents
risk-reduction flowing one way, money the other way.

--
Phlip
http://www.c2.com/cgi/wiki?TestFirstUserInterfaces

[Jeff Grigg]

> UncBob: T&M is a risk transfer strategy.

Laurent Bossavit <laurent.ng@bossavit.com> wrote... [...] What you actually wrote was "T&M is a risk transfer strategy". I'm assuming you meant "time and materials". I am unable to understand *that* at all, much less frame a cogent reply. Please tell me more.

"Time and Materials:"
We'll do the project for you on these terms: Here's the hourly rate
for each of our people. You'll pay that (time) plus reasonable
expenses ("materials" == supplies, travel, lodging, and meals, if
appropriate).

This type of contract transfers practically all risk to the customer.
Presumably only the customer knows what they want, and only the
customer will be able to recognize when it's done.

[Paul Sinnett]

Laurent Bossavit wrote: [Time & materials] transfers practically all risk to the customer. Ah. It is a risk transfer strategy *for the software professional* ? We had been discussing risk strategies from the point of view of the entity commissioning the software.

Perhaps that's just the way you read it. I've been looking at both sides.
But if I had a bias it would be in considering the developers position.

[Paul Sinnett]

Uncle Bob (Robert C. Martin) wrote: The use of XP need have no impact upon the nature of the contract. You can use XP to manage internal risk, and still write the contract any way you like. XP does not imply variable scope contracts.

"How can you do a fixed price / fixed date / fixed scope contract if you
play the Planning Game? You will end up with a fixed price / fixed date /
roughly variable scope contract." - XP Explained.

[Paul Sinnett]

Uncle Bob (Robert C. Martin) wrote: Paul Sinnett <paul.sinnett@btinternet.com>:This presents us, as developers, with an opportunity to capitalise on thesituation. If we are willing to assume a little more of the customer'srisk than we perhaps should, then we can improve our chances of gettingbetter contracts. Define "better".

Better value. Bigger profit. Higher profile.
It seems to me that what you really mean is that if you can find a way to manage your risk better than your competitors, then you can take more risk away from the customer without unacceptably increasing your own risk.

Yes indeed. That's exactly it.
I think XP offers you the tools to do exactly that.

For example?

[Paul Sinnett]

Uncle Bob (Robert C. Martin) wrote: XP doesn't tell us how to write contracts. There are many XP teams doing fixed bid contracts.

Are there any reading this newsgroup?

[Uncle Bob (Robert C. Martin)]

Paul Sinnett <paul.sinnett@btinternet.com> might (or might not) have
written this on (or about) Wed, 09 Jul 2003 01:10:12 +0100, :
Uncle Bob (Robert C. Martin) wrote: Paul Sinnett <paul.sinnett@btinternet.com> : Given any low risk scenario there must be a way to cut a corner and thus reduce cost. Sure it's risky to do that. But that's what we're talking about isn't it? Cut a corner? No, not that. There is no way to win if you cut corners. No matter how much pressure you are under, cutting corners always spells failure. Software systems are too complex to tolerate corner cutting.No, not the corner! Arrrrgh!Whatever do you think I mean by cutting corners? Anyone would think that Ihad suggested some awful programming horror such as not making an abstractbase class for an employee object in anticipation of future changes ;-)

;-) Sorry, I probably over-reacted. I've seen too much damage done
in the name of cutting corners.
I agree with you about pressure though. It's not a good idea to be takingrisks under pressure.

Right. The greater the pressure, the more you follow the rules.



Robert C. Martin | "Uncle Bob"
Object Mentor Inc.| unclebob @ objectmentor . com
PO Box 5757 | Tel: (800) 338-6716
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python |

[Uncle Bob (Robert C. Martin)]

Paul Sinnett <paul.sinnett@btinternet.com> might (or might not) have
written this on (or about) Thu, 10 Jul 2003 02:25:22 +0100, :
Uncle Bob (Robert C. Martin) wrote: Paul Sinnett <paul.sinnett@btinternet.com>:This presents us, as developers, with an opportunity to capitalise on thesituation. If we are willing to assume a little more of the customer'srisk than we perhaps should, then we can improve our chances of gettingbetter contracts. Define "better".Better value. Bigger profit. Higher profile. It seems to me that what you really mean is that if you can find a way to manage your risk better than your competitors, then you can take more risk away from the customer without unacceptably increasing your own risk.Yes indeed. That's exactly it. I think XP offers you the tools to do exactly that.For example?

You, and your customers, will know the state of the project all the
time. You will be able to predict when certain features will be
ready, and be able to see measurable and verifiable progress towards
those goals. You will know, well in advance, if there is going to be
a schedule problem. This advance warning is enough to abolish
"management-by-hope". Instead you and your customers can decide what
to do to get the best possible outcome.

This all comes from running the project in very short cycles, with
unambiguous tests closing each cycle. It comes from letting the
customer choose the highest priority features first, and not imposing
a "technical ordering" on the project. It comes from a the estimation
feedback that allows you to size each story and measure how much work
you can get done in a given period of time.

When you have these tools in place then you can make bids that are
lower, because you know you'll be able manage the risk. Your previous
customers will want to continue to use you, even if some schlock firm
underbids you, because they know the outcome is so reliable with you.



Robert C. Martin | "Uncle Bob"
Object Mentor Inc.| unclebob @ objectmentor . com
PO Box 5757 | Tel: (800) 338-6716
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python |

[Uncle Bob (Robert C. Martin)]

Paul Sinnett <paul.sinnett@btinternet.com> might (or might not) have
written this on (or about) Thu, 10 Jul 2003 02:19:38 +0100, :
Uncle Bob (Robert C. Martin) wrote: The use of XP need have no impact upon the nature of the contract. You can use XP to manage internal risk, and still write the contract any way you like. XP does not imply variable scope contracts."How can you do a fixed price / fixed date / fixed scope contract if youplay the Planning Game? You will end up with a fixed price / fixed date /roughly variable scope contract." - XP Explained.

You run a few iterations on T&M or on spec if you have to. You
measure your velocity, count up all the stories in the spec, and then
make your bid. The bid you make will be based upon empirical data,
not wet finger guesses.

As for the quote. I think Kent was making the point that all fixed bid
contracts are really variable scope contracts in disguise.



Robert C. Martin | "Uncle Bob"
Object Mentor Inc.| unclebob @ objectmentor . com
PO Box 5757 | Tel: (800) 338-6716
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python |

[Uncle Bob (Robert C. Martin)]

jgrigg@mo.net (Jeff Grigg) might (or might not) have written this on
(or about) 9 Jul 2003 12:44:02 -0700, :
UncBob: > T&M is a risk transfer strategy.Laurent Bossavit <laurent.ng@bossavit.com> wrote... [...] What you actually wrote was "T&M is a risk transfer strategy". I'm assuming you meant "time and materials". I am unable to understand *that* at all, much less frame a cogent reply. Please tell me more."Time and Materials:"We'll do the project for you on these terms: Here's the hourly ratefor each of our people. You'll pay that (time) plus reasonableexpenses ("materials" == supplies, travel, lodging, and meals, ifappropriate).This type of contract transfers practically all risk to the customer.Presumably only the customer knows what they want, and only thecustomer will be able to recognize when it's done.

In some circles this is called: "a job". All the risk is transferred
to the employer and away from the employee. At least that's the
illusion. You find out just how much of an illusion that is when you
are laid off.



Robert C. Martin | "Uncle Bob"
Object Mentor Inc.| unclebob @ objectmentor . com
PO Box 5757 | Tel: (800) 338-6716
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python |

[Ilja Preuß]

Uncle Bob (Robert C. Martin) wrote: T&M is a strategy used by contracting firms to transfer risk to the client. Fixed-bid is a strategy employed by clients to transfer risk to the contractor.

Isn't this an oversimplification? Doesn't T&M also transfer the risk of a
premature project end to the contractor, for example?

Curious, Ilja

[Tom Adams]

jgrigg@mo.net (Jeff Grigg) wrote in message news:<c794c0fd.0307091144.48fb0143@posting.google.com>... UncBob: > T&M is a risk transfer strategy. Laurent Bossavit <laurent.ng@bossavit.com> wrote... [...] What you actually wrote was "T&M is a risk transfer strategy". I'm assuming you meant "time and materials". I am unable to understand *that* at all, much less frame a cogent reply. Please tell me more. "Time and Materials:" We'll do the project for you on these terms: Here's the hourly rate for each of our people. You'll pay that (time) plus reasonable expenses ("materials" == supplies, travel, lodging, and meals, if appropriate). This type of contract transfers practically all risk to the customer.

Well, not all risks. There is the risk that a T&M contractor will be
renewed when the renewal cycle rolls around. I have worked with a
group of contractors on T&M for 15 years. We manage the software
projects and practice risk control as best we can. The key is not to
have such big overruns or project failures that they throw you out.
Presumably only the customer knows what they want, and only the customer will be able to recognize when it's done.

[Uncle Bob (Robert C. Martin)]

"Ilja Preuß" <preuss@disy.net> might (or might not) have written this
on (or about) Thu, 10 Jul 2003 10:08:06 +0200, :
Uncle Bob (Robert C. Martin) wrote: T&M is a strategy used by contracting firms to transfer risk to the client. Fixed-bid is a strategy employed by clients to transfer risk to the contractor.Isn't this an oversimplification? Doesn't T&M also transfer the risk of apremature project end to the contractor, for example?

Of course. So contractors often put in clauses that constrain
termination of the contract. As it happens, the client usually also
wants those constraints.


Robert C. Martin | "Uncle Bob"
Object Mentor Inc.| unclebob @ objectmentor . com
PO Box 5757 | Tel: (800) 338-6716
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python |

[Paul Sinnett]

Uncle Bob (Robert C. Martin) wrote: Paul Sinnett <paul.sinnett@btinternet.com>:"How can you do a fixed price / fixed date / fixed scope contract if youplay the Planning Game? You will end up with a fixed price / fixed date /roughly variable scope contract." - XP Explained. You run a few iterations on T&M or on spec if you have to. You measure your velocity, count up all the stories in the spec, and then make your bid. The bid you make will be based upon empirical data, not wet finger guesses.

Making an estimate of the whole project based on a few initial iterations
*is* a wet finger guess. You take a simple measurement of the current
weather and assuming nothing changes throughout the next year or so you'll
come in bang on target. How else would you describe a wet finger guess?

I know there is the principle of 'yesterday's weather' in XP but that is
only for short term estimation. 'Yesterday's weather' might be better on
average at predicting tomorrow's weather that an office full of computers,
but it's not as good at predicting large scale variables like annual
precipitation. Or like a bid for a fixed price contract.
As for the quote. I think Kent was making the point that all fixed bid contracts are really variable scope contracts in disguise.

I'm sure Kent can speak for himself on that. I don't think fixed scope
contracts are variable scope. They may be flexible on the spec but the
scope value is more or less fixed. What will happen is that original
features that they discover they don't want will be traded for new features
that they do. This doesn't change the scope in terms of work load, but it
does change where that work goes.

[Paul Sinnett]

Uncle Bob (Robert C. Martin) wrote: Paul Sinnett <paul.sinnett@btinternet.com>:Uncle Bob (Robert C. Martin) wrote: It seems to me that what you really mean is that if you can find a way to manage your risk better than your competitors, then you can take more risk away from the customer without unacceptably increasing your own risk.Yes indeed. That's exactly it. I think XP offers you the tools to do exactly that.For example? You, and your customers, will know the state of the project all the time. You will be able to predict when certain features will be ready, and be able to see measurable and verifiable progress towards those goals. You will know, well in advance, if there is going to be a schedule problem. This advance warning is enough to abolish "management-by-hope". Instead you and your customers can decide what to do to get the best possible outcome.

This is all fine for building the confidence in the customer to take on more
risk. And this may well be exactly what they need. Unfortunately, at the
moment at least, this is exactly the opposite of what they want. It makes
it unlikely for us to win a contract at all under those conditions. What
you are suggesting here is passing risk to, rather than taking risk from,
the customer.
When you have these tools in place then you can make bids that are lower, because you know you'll be able manage the risk. Your previous customers will want to continue to use you, even if some schlock firm underbids you, because they know the outcome is so reliable with you.

Unfortunately our previous customers have had a habit of falling into
financial difficulties. This is something a lot of developers must have
experienced too over the past few years, due to the dot-bombs and the like.

It has been our experience over the past few years that we *have* been
underbid by "schlock" firms. And then *later* we have been hired to rescue
those projects. All I can think is that although it is safer to use us up
front, it must appear safer to use monkeys. We have been presenting a
realistic risk to the customer. It must be more apparent risk than they are
willing to take.

[Paul Sinnett]

"Phlip" <phlip_cpp@yahoo.com> wrote: Uncle Bob (Robert C. Martin) wrote: Phlip didn't quite get the story right. Someone asked Kent: "What's XP's risk management strategy?" Kent responded: "That's like asking a fish what it's water strategy is. A fish *is* a water strategy. Likewise, XP *is* a risk management strategy." Ain't it cool that Google can finally spider old Yahoo Groups posts?! That ain't the exact quote either, but screw it; we were both close enough. I also found this great quote on a marginally related Web site: "Now leave us, and take your fish with you." --Faramir

I think this whole fish thing is a red herring... What I mean is,
Kent's analogy is a fish out of water... Argh, you've got me at it
now...

Firstly, and quite obviously, a fish is not a water strategy.
Secondly, XP does not embrace risk, it embraces change and change is
not risk. Thirdly, XP can survive without risk. Fourthly, one of XP's
stated goals is to reduce risk. I could go on but this analogy simply
doesn't hold water...

To paraphrase Douglas Adams, Kent's analogy is like a Vogon
constructor fleet: it hangs in the air in exactly the same way that
bricks don't

[Phlip]

Paul Sinnett wrote:
...change is not risk...

Still don't know what I was waiting for
time was running wild
a million dead-end streets and
every time I thought I'd got it made
it seemed the taste was not so sweet

So I turn myself to face me
but I never got a glimpse
of how the others must see the faker
I'm much to fast to take that test

--
David Bowie

[Laurent Bossavit]

> Firstly, and quite obviously, a fish is not a water strategy.

It's not obvious to me. Please explain.

[Paul Sinnett]

Laurent Bossavit wrote: Firstly, and quite obviously, a fish is not a water strategy. It's not obvious to me. Please explain.

I don't know that I can. I mean, are you willing to accept that there is
anything in the universe that is not a water strategy?

Or perhaps more importantly, are you willing to accept that there is
anything in the universe that is not risk management?

[Jeremy Dunck]

On 22 Jul 2003 01:43:37 -0700, paul.sinnett@btinternet.com (Paul
Sinnett) wrote:
"Phlip" <phlip_cpp@yahoo.com> wrote: Uncle Bob (Robert C. Martin) wrote: Phlip didn't quite get the story right. Someone asked Kent: "What's XP's risk management strategy?" Kent responded: "That's like asking a fish what it's water strategy is. A fish *is* a water strategy. Likewise, XP *is* a risk management strategy." Ain't it cool that Google can finally spider old Yahoo Groups posts?! That ain't the exact quote either, but screw it; we were both close enough. I also found this great quote on a marginally related Web site: "Now leave us, and take your fish with you." --FaramirI think this whole fish thing is a red herring... What I mean is,Kent's analogy is a fish out of water... Argh, you've got me at itnow...Firstly, and quite obviously, a fish is not a water strategy.Secondly, XP does not embrace risk, it embraces change and change isnot risk. Thirdly, XP can survive without risk. Fourthly, one of XP'sstated goals is to reduce risk. I could go on but this analogy simplydoesn't hold water...To paraphrase Douglas Adams, Kent's analogy is like a Vogonconstructor fleet: it hangs in the air in exactly the same way thatbricks don't


As I read XP Explained, the idea of putting off anything that YAGN was
founded on options. Options (in the financial sense) allow us to
defray risk by providing opportunities for responding to change. XP's
goal is to provide the business with options.

It could be that we're talking about two different levels of risk--
the XP view (which I think is a macro-level goal of giving the
business the best investment they can) and your view (which is more
detail-oriented).

I really did find the options explaination enlightening. I'd simply
never considered software development at the "executive" level in that
light.

Hope that helps...

[Laurent Bossavit]

> >> Firstly, and quite obviously, a fish is not a water strategy. It's not obvious to me. Please explain. I don't know that I can. I mean, are you willing to accept that there is anything in the universe that is not a water strategy?

Sure. The Sun. A bicycle. My cell phone.
Or perhaps more importantly, are you willing to accept that there is anything in the universe that is not risk management?

Most certainly.

The analogy seems apt to me, in that a fish is "obviously" better adapted
to a watery environment than, say, a bald eagle; and XP is "obviously"
better adapted to the risky environment of unstable requirements than,
say, unadulterated Waterfall. Our obviouslies obviously differ.

On the use of the term "obvious", my RSS aggregator disgorged the
following not an hour ago - timely, eh ?

http://christiansepulveda.com/blog/archives/000023.html

[Paul Sinnett]

Jeff Grigg wrote: Perhaps this would help: A random challenger asks a project manager: "What is your 'Reliability Management Strategy' for this project? Can you give me a document [preferably with that name!] that directly addresses the issue of your project's 'Reliability Management Strategy'?" (Implying, of course, that since reliability is obviously important to any project, lack of a strategy for it would indicate management incompetence.) Wise project manager responds: "What is the water management strategy of a fish?"

I believe that on an XP project we should follow core XP values when we are
answering questions about our process. Therefore, I think, in answer we
should not attempt to dodge the issue (which takes courage) but that we
should provide a simple and clear answer (feedback, communication,
simplicity).

This "answer" manages to devalue all four! We might answer this way if we
were afraid of looking incompetent. We might answer this way if we feared
that our direct feedback might not be well received. We might answer this
way if we wanted to avoid communication with our customers by implying that
they would be stupid if they didn't understand our wisdom. We might answer
this way if we feared unpleasant consequences and thought they could be
avoided by confusing the issue with esoteric sophistry.
Point being that fish don't have formal "water management strategies," in spite of being in a watery environment all their lives. Fish live in water -- in environments that would typically be quite deadly for humans. Fish don't worry about the water; they're well adapted to it. Fish die without water, but could probably do little about it if they were to be without water. So in spite of the importance of water to fish, fish don't have formal "water management strategies."

Fish don't have any formal strategies for anything. This analogy fails
because there is no relation between fish and water on the one hand and XP
and risk on the other. You could replace XP and risk with anything at all
and the argument would seem just as coherent.
Likewise, a sensible answer to the question, "What is the 'Risk Management Strategy' of an XP project?" could well be that much of the focus and a number of the practices of XP address various forms of risk. And some practices may have been adopted specifically to address some specific risks. But there is not necessarily any particular need for a separate "Risk Management Strategy" that exists independently of everything else.

I agree that XP is a strategy for avoiding risk. Chapter 1 of XP explained
"Risk: The Basic Problem" sets out that agenda. But risk cannot be reduced
or destroyed, only our exposure to risk can be changed. The exposure to
risk that XP avoids is simply passed on to the customer.

Now I'm not saying this is wrong. The customer ought to be responsible for
the risks, after all they are ultimate source of the risk in the first
place. But I don't think every customer is happy to take on all the risk.
Some customers like to insure against some of that exposure by contracting
it to the developers.

[Paul Sinnett]

Laurent Bossavit wrote: Or perhaps more importantly, are you willing to accept that there is anything in the universe that is not risk management? Most certainly. The analogy seems apt to me, in that a fish is "obviously" better adapted to a watery environment than, say, a bald eagle; and XP is "obviously" better adapted to the risky environment of unstable requirements than, say, unadulterated Waterfall.

The argument being that something that evolved in an environment is better
adapted to that environment than something that did not? The problem is
that all programming methods evolved in the risky environment of unstable
requirements. The relation doesn't hold. If this is your argument then you
could equally apply it to waterfall, spiral, evolutionary prototyping, or
even code-and-fix.

"What is the risk management strategy of code-and-fix? What is the water
strategy of a fish?"

But you say XP is better adapted than waterfall. I agree. But why is it? If
they both evolved in an environment of changing requirements, why is it
that XP is better than waterfall?

I'm suggesting that the reason XP is better than waterfall at handling
changing requirements has nothing to do with the environment they evolved
in. And therefore, the argument by analogy is specious.

[Phlip]

> >To paraphrase Douglas Adams, Kent's analogy is like a Vogonconstructor fleet: it hangs in the air in exactly the same way thatbricks don't As I read XP Explained, the idea of putting off anything that YAGN was founded on options. Options (in the financial sense) allow us to defray risk by providing opportunities for responding to change. XP's goal is to provide the business with options. It could be that we're talking about two different levels of risk-- the XP view (which I think is a macro-level goal of giving the business the best investment they can) and your view (which is more detail-oriented). I really did find the options explaination enlightening. I'd simply never considered software development at the "executive" level in that light.

Try this term: Runway.

It means from the start of the project, until the time the project
financially sustains itself - in the air.

Staying on the ground, burning money, is risky. Liftoff is risky.
Flying is less risky. So, agile practices try to push the liftoff
point as close to the start of the project as possible.

--
Phlip
http://www.greencheese.org/EvolutionaryPsychology
-- Just think: Four billion people in the
world have never received Spam... --

[Paul Sinnett]

Ron Jeffries wrote: <paul.sinnett@btinternet.com> wrote:
I believe that on an XP project we should follow core XP values when weare answering questions about our process. Therefore, I think, in answerwe should not attempt to dodge the issue (which takes courage) but that weshould provide a simple and clear answer (feedback, communication,simplicity). Yes. I agree. The fish metaphor might be the beginning of a conversation on risk. It shouldn't be the whole conversation, unless the discussant is somehow enlightened by the phrase. :)

Indeed. But since there is no way to know that the discussant is
enlightened, and not just afraid to look stupid, then it shouldn't be the
whole conversation for anyone who values feedback. Right?

[Ron Jeffries]

On Thu, 24 Jul 2003 10:04:59 +0100, Paul Sinnett <paul.sinnett@btinternet.com>
wrote:
Ron Jeffries wrote: <paul.sinnett@btinternet.com> wrote:Fish don't have any formal strategies for anything. This analogy failsbecause there is no relation between fish and water on the one hand and XPand risk on the other. You could replace XP and risk with anything at alland the argument would seem just as coherent. It's a metaphor. And, in my opinion, a darn good one.Which suggests you have a criterion for a good metaphor on which thismetaphor rates highly. What is that criterion?

It doesn't imply that. One might rate each metaphor that one rates on its own
merits, not according to some general standard of metaphorica.

I like this one because we can immediately draw the comparison ... so if a fish
is a sater strategy, then in a similar way XP is a risk strategy.

So it directs our thinking. Fish have various aspects that we can imagine
address their being a water strategy: gills, fins, steamlined bodies, and so on.

What might the aspects of XP be that make it a risk strategy in the "same way"
that a fish is a water strategy?

XP might take many small risks instead of a small number of large ones: we might
turn our attention to short iterations, rapid customer feedback.

XP might have risk-limiting aspects: we might turn our attention to extensive
testing, automated for repetition, divided into multiple layers for redundancy.

XP might have ways of bringing important risks forward in time: we might turn
our attention to story sorting techniques and to "spike solutions".

When we turn our attention to the idea that "a fish is a water strategy" has
meaning, and that in some similar way "XP is a risk strategy", it gives us a
frame for thinking about risk in the XP context.

That's why I think it's a good metaphor.

--
Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
I'm giving the best advice I have. You get to decide whether it's true for you.

[Ron Jeffries]

On Thu, 24 Jul 2003 09:59:23 +0100, Paul Sinnett <paul.sinnett@btinternet.com>
wrote:
Ron Jeffries wrote: <paul.sinnett@btinternet.com> wrote:I believe that on an XP project we should follow core XP values when weare answering questions about our process. Therefore, I think, in answerwe should not attempt to dodge the issue (which takes courage) but that weshould provide a simple and clear answer (feedback, communication,simplicity). Yes. I agree. The fish metaphor might be the beginning of a conversation on risk. It shouldn't be the whole conversation, unless the discussant is somehow enlightened by the phrase. :)Indeed. But since there is no way to know that the discussant isenlightened, and not just afraid to look stupid, then it shouldn't be thewhole conversation for anyone who values feedback. Right?

Is there no way to know that the discussant is enlightened? I'm not at all sure
of that.

But if there isn't, then one might go for feedback more directly, yes.

--
Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
I'm giving the best advice I have. You get to decide whether it's true for you.

[Code Like Hell]

http://www.ugkrishnamurti.org/ug/ug_video/ugv_jt/no_enlightenment.ram
http://www.ugkrishnamurti.org/ug/ug_video/ugv_jt/no_enlightenment_56.ram

Ron Jeffries <ronjeffries@REMOVEacm.org> wrote in message news:<6o61ivglehk0s5utsl1nrv871ceodqcn97@4ax.com>... On Thu, 24 Jul 2003 09:59:23 +0100, Paul Sinnett <paul.sinnett@btinternet.com> wrote:Ron Jeffries wrote: <paul.sinnett@btinternet.com> wrote:>I believe that on an XP project we should follow core XP values when we>are answering questions about our process. Therefore, I think, in answer>we should not attempt to dodge the issue (which takes courage) but that we>should provide a simple and clear answer (feedback, communication,>simplicity). Yes. I agree. The fish metaphor might be the beginning of a conversation on risk. It shouldn't be the whole conversation, unless the discussant is somehow enlightened by the phrase. :)Indeed. But since there is no way to know that the discussant isenlightened, and not just afraid to look stupid, then it shouldn't be thewhole conversation for anyone who values feedback. Right? Is there no way to know that the discussant is enlightened? I'm not at all sure of that. But if there isn't, then one might go for feedback more directly, yes.

[Paul Sinnett]

Ron Jeffries wrote: When we turn our attention to the idea that "a fish is a water strategy" has meaning, and that in some similar way "XP is a risk strategy", it gives us a frame for thinking about risk in the XP context. That's why I think it's a good metaphor.

Okay, then I'll overlook the problems with the analogy itself for the
moment.

A fish must be a very specific water strategy as anyone who has ever tried
to keep fish can testify. The water must be just the right temperature, and
contain just the right pH, oxygen, and the right kind of bacteria.

And risk, like water, comes in many different forms. Are we to draw the
conclusion from our metaphor that XP, like a fish, is very sensitive to its
environment? Will XP, like a fish, fail to function if the narrow range of
conditions to which it is adapted are not met?

If so, then it seems to me that we might need a more generalised approach to
risk management than that XP has built in.

[Paul Sinnett]

Ron Jeffries wrote: <paul.sinnett@btinternet.com> wrote:>And risk, like water, comes in many different forms. Are we to draw the>conclusion from our metaphor that XP, like a fish, is very sensitive to>its environment? Will XP, like a fish, fail to function if the narrow>range of conditions to which it is adapted are not met? What narrow range of conditions did you have in mind?By analogy, the conditions under which XP evolved. The C3 project forexample.So, from our metaphor, XP's built in risk strategy can only work well whenapplied to projects whose risk profiles match the C3 project?And therefore other projects might be advised to either run separate riskmanagement or integrate risk management into XP somehow? So your logic is that a thing only works under exactly the conditions it is first tried in? That might be overly limiting. And what about all the other XP teams reporting good results?

Exactly. It doesn't stand up does it. The analogy that XP is a risk strategy
in the same way that a fish is a water strategy doesn't match our
experience of those things. Right?

[Ron Jeffries]

On Sun, 27 Jul 2003 17:07:37 +0100, Paul Sinnett <paul.sinnett@btinternet.com>
wrote:
Ron Jeffries wrote: <paul.sinnett@btinternet.com> wrote:>>And risk, like water, comes in many different forms. Are we to draw the>>conclusion from our metaphor that XP, like a fish, is very sensitive to>>its environment? Will XP, like a fish, fail to function if the narrow>>range of conditions to which it is adapted are not met?>> What narrow range of conditions did you have in mind?By analogy, the conditions under which XP evolved. The C3 project forexample.So, from our metaphor, XP's built in risk strategy can only work well whenapplied to projects whose risk profiles match the C3 project?And therefore other projects might be advised to either run separate riskmanagement or integrate risk management into XP somehow? So your logic is that a thing only works under exactly the conditions it is first tried in? That might be overly limiting. And what about all the other XP teams reporting good results?Exactly. It doesn't stand up does it. The analogy that XP is a risk strategyin the same way that a fish is a water strategy doesn't match ourexperience of those things. Right?

I don't follow your reasoning. My experience is that XP teams all over are
reporting good results. Yet projects all over are risky. Therefore XP may well
be dealing well with risk.

--
Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
I'm giving the best advice I have. You get to decide whether it's true for you.

[Paul Sinnett]

Ron Jeffries wrote: <paul.sinnett@btinternet.com> wrote:Ron Jeffries wrote: And what about all the other XP teams reporting good results?Exactly. It doesn't stand up does it. The analogy that XP is a riskstrategy in the same way that a fish is a water strategy doesn't match ourexperience of those things. Right? I don't follow your reasoning. My experience is that XP teams all over are reporting good results.

I meant that the analogy doesn't stand up. I'm not calling into question the
results of XP teams.

[Ilja Preuß]

Paul Sinnett wrote:
A fish must be a very specific water strategy as anyone who has ever tried to keep fish can testify. The water must be just the right temperature, and contain just the right pH, oxygen, and the right kind of bacteria.

A specific *instance* of a fish, yes. A fish as a general concept doesn't
have this constraints. Of course the "water strategy Fish" needs to be
adapted to local environments.
And risk, like water, comes in many different forms. Are we to draw the conclusion from our metaphor that XP, like a fish, is very sensitive to its environment? Will XP, like a fish, fail to function if the narrow range of conditions to which it is adapted are not met?

XP, like Fish, needs to be adapted to the local circumstances. I think the
analogy works just fine here... :)

Regards, Ilja

[Ilja Preuß]

Paul Sinnett wrote:
Exactly. It doesn't stand up does it. The analogy that XP is a risk strategy in the same way that a fish is a water strategy doesn't match our experience of those things. Right?

Are you saying that all the XP teams out there are doing XP exactly the way
it was done at C3? Or are they just as different as the different types of
fish all over the world?

Regards, Ilja

[Paul Sinnett]

Ilja Preuß wrote: Paul Sinnett wrote: A fish must be a very specific water strategy as anyone who has ever tried to keep fish can testify. The water must be just the right temperature, and contain just the right pH, oxygen, and the right kind of bacteria. A specific *instance* of a fish, yes. A fish as a general concept doesn't have this constraints.

Okay so the analogy should be: XP processes are risk strategies like fish
are water strategies?
Of course the "water strategy Fish" needs to be adapted to local environments. And risk, like water, comes in many different forms. Are we to draw the conclusion from our metaphor that XP, like a fish, is very sensitive to its environment? Will XP, like a fish, fail to function if the narrow range of conditions to which it is adapted are not met? XP, like Fish, needs to be adapted to the local circumstances. I think the analogy works just fine here... :)

It works fine with this interpretation. It's just that now it explicitly
doesn't stand as an answer to the original question. I'll rephrase the
question in terms of the new analogy: how can I adapt XP to a new risk
environment?

[Ilja Preuß]

Paul Sinnett wrote:
It works fine with this interpretation. It's just that now it explicitly doesn't stand as an answer to the original question. I'll rephrase the question in terms of the new analogy: how can I adapt XP to a new risk environment?

Perhaps the analogy ends here - an instance of XP can be adapted on the fly,
based on the massive feedback it provides. Most fishs don't seem to be able
to do that.

Or perhaps they can - perhaps the different risks in software development
are more like different currents the fish adapts his actions to.

Are there any specific risks you are thinking of, making different adaptions
of XP necessary?

Regards, Ilja

[Code Like Hell]

Paul Sinnett <paul.sinnett@btinternet.com> wrote in message news:<3f263f15@news.totallyobjects.com>... Ilja Preuß wrote: Paul Sinnett wrote: A fish must be a very specific water strategy as anyone who has ever tried to keep fish can testify. The water must be just the right temperature, and contain just the right pH, oxygen, and the right kind of bacteria. A specific *instance* of a fish, yes. A fish as a general concept doesn't have this constraints. Okay so the analogy should be: XP processes are risk strategies like fish are water strategies? Of course the "water strategy Fish" needs to be adapted to local environments. And risk, like water, comes in many different forms. Are we to draw the conclusion from our metaphor that XP, like a fish, is very sensitive to its environment? Will XP, like a fish, fail to function if the narrow range of conditions to which it is adapted are not met? XP, like Fish, needs to be adapted to the local circumstances. I think the analogy works just fine here... :) It works fine with this interpretation. It's just that now it explicitly doesn't stand as an answer to the original question. I'll rephrase the question in terms of the new analogy: how can I adapt XP to a new risk environment?

For software risks, can't you just feed a standard XP process story
cards in order of Severity x Probability?

For project risks, the biggest problem seems to be that reporting
requirements create an added burden on the process. Lack of
documentation is cited as a "risk" in traditional books, whereas in
XP, documentation is seen as a solution to the deeper risks
associated with understanding and changing code. This is fine for
developers, but how does the xp process feed value up the mgmt chain?

Story cards are held onto because working software isn't enough, or
the current configuration of the powers that be is not extracting
enough profit from working software. There isn't enough customer.
Or mgmt can't generate any real wealth. Or something. So mgmt needs
to exhibit its capabilities in the meantime. So if mgmt becomes the
customer, feed in cards to gradually automate the exhibition of your
software process instead. Feed them in Severity x Probability.

How is XP not adapted to a new risk environment? What does a risk
require, in general? Some sort of interlock ("if this is happening,
then that can't happen")? So what are the new risks and what
interlocks would you add to XP to fix it?

[Ron Jeffries]

On Mon, 28 Jul 2003 02:57:17 +0100, Paul Sinnett <paul.sinnett@btinternet.com>
wrote:
Ron Jeffries wrote: <paul.sinnett@btinternet.com> wrote:Ron Jeffries wrote:> And what about all the other XP teams reporting good results?Exactly. It doesn't stand up does it. The analogy that XP is a riskstrategy in the same way that a fish is a water strategy doesn't match ourexperience of those things. Right? I don't follow your reasoning. My experience is that XP teams all over are reporting good results.I meant that the analogy doesn't stand up. I'm not calling into question theresults of XP teams.

What makes you feel that the analogy doesn't hold up? (Not that they have to,
their point is just to make a point, not to carry the entire burden of the
future of the race.)

--
Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
I'm giving the best advice I have. You get to decide whether it's true for you.

[Ron Jeffries]

On Tue, 29 Jul 2003 09:54:41 +0100, Paul Sinnett <paul.sinnett@btinternet.com>
wrote:
It works fine with this interpretation. It's just that now it explicitlydoesn't stand as an answer to the original question. I'll rephrase thequestion in terms of the new analogy: how can I adapt XP to a new riskenvironment?

What new risk environment do you have in mind?

--
Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
I'm giving the best advice I have. You get to decide whether it's true for you.

[Paul Sinnett]

Ilja Preuß wrote: Are there any specific risks you are thinking of, making different adaptions of XP necessary?

First, a little background:

When we are looking for new contracts we are often in competition with a lot
of other companies. And in games it is somewhat of a buyer's market. We
have yet to find a publisher interested in a time and materials contract at
all, or even a hybrid. So essentially we have a level playing field. And we
are all bidding for fixed contracts.

Now the publishers know how risky this is because they've all been burned on
multiple occasions. You've probably only ever heard about the spectacular
failures. "Project comes in on time," isn't really news. But, nevertheless,
there are still a lot of late and troublesome projects out there.

From a publisher point of view there are any number of ways they can deal
with such risk:

They could take on a time and materials contract and manage the risks
themselves, XP style. But that would take a lot of courage on their part and
I know of no publisher out there willing to take that on. (Of course if
such a publisher is reading this, please get in touch: ps@coyotedev.com )

They could select those developers that have a track record for delivering
to schedule, for example. But such developers often charge a lot more
because of that, so this option is usually rejected except as part of a
portfolio, as below.

Or they could play the odds. Take a portfolio of projects, get the best deal
they can for each risky one, and set any losses from those against the
profits from the less risky ones. This seems to be the weapon of choice.

Now as far as our company is concerned, our established track record puts us
up against companies who are also very risk aware. The schedules we create
for these contracts usually contain enough slack in them that we are
confident we can deliver to the fixed terms of the contract. We usually
lose a bit of that slack in the bidding but generally this has worked out
quite well. But the problem with this is that we don't end up making much
profit out of it. As a general rule, the low risk projects are the low
profit projects.

So we want more profit. Not because we are greedy, but because (like most
small developers) we have our own internal projects that we'd like to
develop. And those projects are relatively costly when you have to work all
the time just to pay your wages.

We need a way to cut our costs on our projects without unduly raising our
exposure to risk. Now before you jump in with the inevitable plug for XP: we
are already doing many of the extreme programming practices: pair
programming, test first, system metaphor, refactoring, continuous
integration, simple design, frequent releases, coding standard, 40-hour
week (most of the time), and collective ownership. What we are missing is
those pesky bits which require the only thing we can't get: a willing
customer.

These last two practices: the planning game, and the on-site customer is
where most of the risk on an XP project gets transfered from the developers
to the customers. (Where I believe it belongs but that's another story.) In
a fixed contract that can't happen. The contract obliges us to take on that
risk.

So we have the burdon of the risk. And we can't avoid that risk, and let the
customer deal with it. Our only alternative is to manage the risk such that
we can squeeze extra profit out of it.

[Paul Sinnett]

Ron Jeffries wrote: It seems to me -- and I could be wrong of course -- that when we compare XP to other typical processes, XP reduces risk in many places, and increases it nowhere. (We might want to discuss whether that last bit is really true.)

It seems to me that risk is like energy in that it can be shifted around but
never destroyed. When we say "reduce risk" we really mean "reduce our
exposure to that risk" not actually remove it. From a distance XP mostly
takes risk exposure on the developer's side and moves it to the customer's
side. So from a developer's perspective XP is low risk.

But in as much as customers are part of the team on an XP project all the
risk is still there, it just now belongs to them. From a customer
perspective, XP is high risk. Granted, they are fully in control; that's
the point. But what if this is more risk than they are willing to take?

So XP's strategy is to move risk exposure from the developer to the customer
and let him deal with it. But the customers must still manage that risk.
What is their strategy for managing that risk? XP says that is entirely up
to the customer, right?

So now what happens when we can't transfer all the risk to the customer
because we are contractually obliged to take on our share (or more than our
share) of the responsibility? Doesn't that break XP's fundamental
separation of concerns? Doesn't that mean that whatever we eventually end
up doing about the risks we will be doing on the behalf of the customer?

XP doesn't give us tools for managing this. It only gives us tools to
transfer our exposure to these risks onto the customer. It doesn't need
tools for managing these risks because it never has to deal with them.

So you can't just tack on risk management because the other processes fight
you. The more risk you try to take on, the more the practices try to push
it away again. Does that make sense? What are your thoughts?

[Otis Bricker]

Maybe I am just not understanding your situation or the point you are
trying to make. But it seems clear to me that your Fixed Scope
contracter (contractee?) is being confused with the Customer.

If you have a truly fixed scope fixed price contract then the outside
customer is no longer in the loop. Every major requirement/story will
have been decided up front. Someone on your side (the Customer) is now in
charge of setting priorities, choosing features from that list and
providing acceptance criteria. Much of this will be provided in the
contract. Some might be based on knowledge of past trends for change
orders, though you seem to suggest that these never happen. It might be
based on feedback from the contracting party to the Customer about the
current state of the project as things progress.

The person paying the bills should certainly be part of the Customer
team, but if the assumption is that all requirements are fixed in stone
by the contract, then you already have accepted whatever level of risk
this means. The contract limits the amount that can be transfered back.
And the amount that you will accept.

If your planning and velocity suggest that you cannot satisfy the
contract with your current rate of progress, the Customer can decide what
to do. He can decide that more resources should be applied Which might
lower your profit but limit your penalties. Or find out if simpler
versions of stories could be substituted while still satisfying the
contract. But someone will have to decide what you are going to do about
this whatever method you use. XP simply places the responsability on the
folks who are supposed to be making business decisions rather than the
developers. They need to decide what will make the contacter the least
upset.

But what do I know. I don't do XP. And I focus on in-house projects. When
I did educational games, we had an almost constant stream of changes
coming in from the management team. Much of it based on feadback from
playing with what we had at that point.

Otis


Paul Sinnett <paul.sinnett@btinternet.com> wrote in
news:3f2890da@news.totallyobjects.com:
Ron Jeffries wrote: It seems to me -- and I could be wrong of course -- that when we compare XP to other typical processes, XP reduces risk in many places, and increases it nowhere. (We might want to discuss whether that last bit is really true.) It seems to me that risk is like energy in that it can be shifted around but never destroyed. When we say "reduce risk" we really mean "reduce our exposure to that risk" not actually remove it. From a distance XP mostly takes risk exposure on the developer's side and moves it to the customer's side. So from a developer's perspective XP is low risk. But in as much as customers are part of the team on an XP project all the risk is still there, it just now belongs to them. From a customer perspective, XP is high risk. Granted, they are fully in control; that's the point. But what if this is more risk than they are willing to take? So XP's strategy is to move risk exposure from the developer to the customer and let him deal with it. But the customers must still manage that risk. What is their strategy for managing that risk? XP says that is entirely up to the customer, right? So now what happens when we can't transfer all the risk to the customer because we are contractually obliged to take on our share (or more than our share) of the responsibility? Doesn't that break XP's fundamental separation of concerns? Doesn't that mean that whatever we eventually end up doing about the risks we will be doing on the behalf of the customer? XP doesn't give us tools for managing this. It only gives us tools to transfer our exposure to these risks onto the customer. It doesn't need tools for managing these risks because it never has to deal with them. So you can't just tack on risk management because the other processes fight you. The more risk you try to take on, the more the practices try to push it away again. Does that make sense? What are your thoughts?

[Ron Jeffries]

On Thu, 31 Jul 2003 04:08:01 +0100, Paul Sinnett <paul.sinnett@btinternet.com>
wrote:
Ron Jeffries wrote: It seems to me -- and I could be wrong of course -- that when we compare XP to other typical processes, XP reduces risk in many places, and increases it nowhere. (We might want to discuss whether that last bit is really true.)It seems to me that risk is like energy in that it can be shifted around butnever destroyed. When we say "reduce risk" we really mean "reduce ourexposure to that risk" not actually remove it. From a distance XP mostlytakes risk exposure on the developer's side and moves it to the customer'sside. So from a developer's perspective XP is low risk.

First of all, I agree that certain XP developer practices reduce developer risk
-- which is mostly the risk of releasing something that doesn't work, if we look
at the software around us.

It is also certainly true that XP places certain decisions in the hands of the
customer: simply, what to do next. This means that the customer is faced with a
risk that he always faces, namely the risk that the wrong things get done, or
that things get done too late.

However, those risks are almost invariably passed on to the customer anyway. If
the customer, in any process, hands things over to development and walks away,
he is likely to be hit in the back of the head with a late and/or buggy product.

I would say, not that XP "moves" risk, but that XP better reflects the risk
assignment that already exists in the real world.But in as much as customers are part of the team on an XP project all therisk is still there, it just now belongs to them. From a customerperspective, XP is high risk. Granted, they are fully in control; that'sthe point. But what if this is more risk than they are willing to take?

Again, it seems to me that the risks in question are always there, and that XP
places them in a different balance. Further, as I'll come to below, XP provides
specific practices that address the risks that the customer might, in an XP
world, be more explicitly exposed to. (Not more exposed -- the risks are always
there. More explicitly exposed.)

Another issue that you, Paul, seem not to be emphasizing as much as I would, is
that XP is not a customer vs developer process. It is a "Whole Team" process, a
customer /with/ developer process. The /team/ has the responsibility to address
and avoid all risks. It's not as much of an "over the wall" thing as your words
seem to be saying.
So XP's strategy is to move risk exposure from the developer to the customerand let him deal with it. But the customers must still manage that risk.What is their strategy for managing that risk? XP says that is entirely upto the customer, right?

Not at all. XP has several practices which have exactly the same effect on
helping the customer manage risk as corresponding developer practices have in
addressing developer risks.

Small Releases expose the customer to frequent concrete feedback on what is
being built, how it matches what the customer imagines he has asked for, and on
how long it is taking. This is exactly the information that the customer needs
to manage the risk of "wrong product idea", the risk of "misunderstood
requirements", and the risk of "slow delivery".

Customer Acceptance Tests make the Small Releases more concretely specified, and
they also ensure that each feature, as it is build in Iteration N, is fully
tested and complete as customer an