Risk management
Paul Sinnett
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
> 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
John Roth
"Paul Sinnett" <paul.s...@btinternet.com> wrote in message
news:3f08...@news.totallyobjects.com...
> 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.
While I got a chuckle out of the Kent Beck quote that Phlip mentions,
risk management is a serious question.
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.
> 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.
> 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? 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.
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.
> 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. When you're dealing with one-off risks, the only feasible policy
is to avoid them in the first place. 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.
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.
John Roth
Opinions on request.
John Roth
Paul Sinnett
Typical.
So... getting back to the question, how can I integrate XP with risk
management?
Paul Sinnett
> "Paul Sinnett" <paul.s...@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
> 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
>> 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)
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 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 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 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.
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.
>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.
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 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.
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. 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.
And you always make it?
>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.
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
> Paul Sinnett <paul.s...@btinternet.com>:
>>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 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 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.
>
> 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.
>>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.
>
> 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. 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.
>
> 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 with
>>other 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)
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."
Uncle Bob (Robert C. Martin)
>Uncle Bob (Robert C. Martin) wrote:
>> Paul Sinnett <paul.s...@btinternet.com>:
>>>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 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 any
>iteration, all high value stories must also be high risk stories. But
>that'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.
>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.
>With YAGNI you simply assume that the risk won't materialise and so all that
>cost 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 risk
>you are willing to take other than to avoid all risk and pass it to the
>customer.
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).
>
>>>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.
>>
>> 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?
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 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?
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. ... 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?
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. 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.
>>
>> 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.
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 of
>them 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.
Paul Sinnett
> Paul Sinnett <paul.s...@btinternet.com> might (or might not) have
>
> 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
news:3F096DC8...@coyotedev.com:
> Uncle Bob (Robert C. Martin) wrote:
>> Paul Sinnett <paul.s...@btinternet.com> might (or might not) have
>>>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. 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.
Uncle Bob (Robert C. Martin)
on (or about) Mon, 07 Jul 2003 13:55:36 +0100, :
>Uncle Bob (Robert C. Martin) wrote:
>> Paul Sinnett <paul.s...@btinternet.com> might (or might not) have
>>>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?
Something like OverallRisk = BusinessValue * TechnicalRisk.
Truly high risk requires both high business value AND high technical
risk.
Paul Sinnett
>>>>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:
>>> 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
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
>
> 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
>> 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
> 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
Uncle Bob (Robert C. Martin)
>Rich wrote:
>> Paul Sinnett <p...@coyotedev.com> wrote:
>>> Uncle Bob (Robert C. Martin) wrote:
>>>> Paul Sinnett <paul.s...@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.
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 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?
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?
Laurent Bossavit
> 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)
>Uncle Bob (Robert C. Martin) wrote:
>> Paul Sinnett <paul.s...@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?
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 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.
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.
Uncle Bob (Robert C. Martin)
>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.
XP doesn't tell us how to write contracts. There are many XP teams
doing fixed bid contracts. I happen to think fixed bid contracts are
nonsense and amost always devolve into T&M contracts. But that's just
me.
Uncle Bob (Robert C. Martin)
written this on (or about) Tue, 08 Jul 2003 01:45:46 +0100, :
>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.
Define "better". 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.
I think XP offers you the tools to do exactly that.
Uncle Bob (Robert C. Martin)
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 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 ?
T&M is a risk transfer strategy.
Paul Sinnett
>> 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 ?
Yes. By customer I am referring to whoever our contract is with. It's true
that there are some publishers who also develop their own games. However
most actual game production is handled by external developers.
>> 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.
Indeed that is true, it is a very risky business. And in that environment I
can understand why publishers wish to avoid as much of that risk as is
possible.
Uncle Bob (Robert C. Martin)
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 think
>it 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.
Laurent Bossavit
> >provision in XP. *Has* anyone ever insured a software project against
> >schedule/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 ?
Laurent Bossavit
> > 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.
Please tell me more.
Paul Sinnett
> 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
>> 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
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
> > > T&M is a risk transfer strategy.
Laurent Bossavit <laure...@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.
Laurent Bossavit
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.
Paul Sinnett
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
> 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
>>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.
>
> 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
> doing fixed bid contracts.
Are there any reading this newsgroup?
Uncle Bob (Robert C. Martin)
>Uncle Bob (Robert C. Martin) wrote:
>> Paul Sinnett <paul.s...@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 ;-)
;-) 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 taking
>risks under pressure.
Right. The greater the pressure, the more you follow the rules.
Uncle Bob (Robert C. Martin)
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.
Uncle Bob (Robert C. Martin)
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.
Uncle Bob (Robert C. Martin)
Yes. However, my point remains. 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.
Uncle Bob (Robert C. Martin)
(or about) 9 Jul 2003 12:44:02 -0700, :
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.
Ilja Preuß
> 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
> > UncBob:
> > > > T&M is a risk transfer strategy.
>
> Laurent Bossavit <laure...@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.
Uncle Bob (Robert C. Martin)
on (or about) Thu, 10 Jul 2003 10:08:06 +0200, :
Of course. So contractors often put in clauses that constrain
termination of the contract. As it happens, the client usually also
wants those constraints.
Paul Sinnett
>>"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.
>
> 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
> Paul Sinnett <paul.s...@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.
Uncle Bob (Robert C. Martin)
>Uncle Bob (Robert C. Martin) wrote:
>> Paul Sinnett <paul.s...@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.
I don't believe the customer will view it that way. I think the
customer will view it as gaining a lot of control.
>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.
I hope you are charging a *lot* for the rescue. Sounds like it could
be a good business, and that the schlock's are fertilizer for you.
Paul Sinnett
>>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.
>
> I don't believe the customer will view it that way. I think the
> customer will view it as gaining a lot of control.
With respect, it doesn't matter how you think the customer will view it. It
only matters how they do view it. I admit that my own experience is limited
but I'm not aware that it is unrepresentative in the video games sector. I
accept that customers might be less risk averse in other areas.
SUPER KOOL 223
These folks might have some clue about risk assessment and what to do
about it
http://www.adtdl.army.mil/cgi-bin/atdl.dll/fm/100-14/default.htm
Note there is a Severity x Probability of consequences associated with
*not* doing anything, so you can't escape.
The RM strategy is something you feed into XP process as story cards.
Customer responsible for making up the matrix and determining
priorities based on Severity x Probability. But that's their problem.
The primary risk XP deals with as a fish in water is the fact that all
your schedules and commitments are worthless because they are based on
today's understanding of value, and stuff is changing too fast, so
your bound to be overcommitted at some point and suffer a loss. The
trick is to deliver value fast now and not get overcommitted by too
much. Overcommitted means you've done a lot of up-front documentary,
plans, infrastructure investments and design work which is rendered
worthless, when you could've taken a least-commitment approach and
just Done X Now, and not suffered as much loss.
Regards.
Paul Sinnett <paul.s...@btinternet.com> wrote in message news:<3f08...@news.totallyobjects.com>...
> 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?
Paul Sinnett
> > 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
> ...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
It's not obvious to me. Please explain.
Paul Sinnett
>> 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?
Jeff Grigg
>>> 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."
paul.s...@btinternet.com (Paul Sinnett) wrote...
> 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...
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?"
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."
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.
Jeremy Dunck
Sinnett) wrote:
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
> >
> > 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 ?
Paul Sinnett
> 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
> 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.
Indeed. To provide the customer with options. Since it is the customer who
must then manage the risks.
> 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'm simply looking at it from the customers viewpoint of taking risk, in
contrast to the XP developers' viewpoint of avoiding it. Obviously the risk
to the whole team remains constant.
> 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...
It helps a lot more than fishy stories.
Paul Sinnett
>> 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
> >constructor fleet: it hangs in the air in exactly the same way that
> >bricks 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... --
Ron Jeffries
wrote:
>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.
It's a metaphor. And, in my opinion, a darn good one.
--
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
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. :)
Paul Sinnett
> <paul.s...@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 is
enlightened, and not just afraid to look stupid, then it shouldn't be the
whole conversation for anyone who values feedback. Right?
Paul Sinnett
> <paul.s...@btinternet.com> wrote:
>>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.
>
> It's a metaphor. And, in my opinion, a darn good one.
Which suggests you have a criterion for a good metaphor on which this
metaphor rates highly. What is that criterion?
Ron Jeffries
wrote:
>Ron Jeffries wrote:
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.
Ron Jeffries
wrote:
>Ron Jeffries wrote:
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.
SUPER KOOL 223
http://www.ugkrishnamurti.org/ug/ug_video/ugv_jt/no_enlightenment_56.ram
Ron Jeffries <ronje...@REMOVEacm.org> wrote in message news:<6o61ivglehk0s5uts...@4ax.com>...
Paul Sinnett
> 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.
Ron Jeffries
wrote:
>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?
What narrow range of conditions did you have in mind?
>
>If so, then it seems to me that we might need a more generalised approach to
>risk management than that XP has built in.
I'm not quite clear what "a more generalized approach to risk management" might
mean. I am supposing that you may mean something like "following the risk
management ideas in such-and-such a document." Is there a particular generalized
approach to RM that you prefer?
I can think of reasons why one might want a different, or additional approaches
to risk management. One might be in a regulated environment that specifies
certain behaviors, such as separate "blind" reviews, or certain documentation,
such as requirements tracing, for example.
Paul Sinnett
> <paul.s...@btinternet.com> wrote:
>>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?
>
> What narrow range of conditions did you have in mind?
By analogy, the conditions under which XP evolved. The C3 project for
example.
So, from our metaphor, XP's built in risk strategy can only work well when
applied to projects whose risk profiles match the C3 project?
And therefore other projects might be advised to either run separate risk
management or integrate risk management into XP somehow?
Ron Jeffries
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 for
>example.
>
>So, from our metaphor, XP's built in risk strategy can only work well when
>applied to projects whose risk profiles match the C3 project?
>
>And therefore other projects might be advised to either run separate risk
>management 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?
Paul Sinnett
> <paul.s...@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 for
>>example.
>>
>>So, from our metaphor, XP's built in risk strategy can only work well when
>>applied to projects whose risk profiles match the C3 project?
>>
>>And therefore other projects might be advised to either run separate risk
>>management 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
wrote:
>Ron Jeffries wrote:
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.
Paul Sinnett
>>> 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?
>
> 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ß
> 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ß
> 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
> 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ß
> 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
SUPER KOOL 223
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
wrote:
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.)
Ron Jeffries
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?
What new risk environment do you have in mind?
Paul Sinnett
> 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: p...@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.
Ron Jeffries
wrote:
>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.
Now here comes the inevitable XP plug. We're talking about Beck's metaphor about
XP is a risk management strategy, as a fish is a water management strategy.
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.)
XP has much faster feedback than (most) other processes one might be used to
using. The techniques you use, pairing, test driven, and so on, all provide
rapid feedback on how things are going -- better information, equalling lower
risk.
Even without a customer, a team can do iteration planning and release planning,
which quickly gives the best feedback I've ever had on how things are going.
(Some people may do better. But all the PERT and Gantt I ever did in the past
never served me as well as XP's simple, high-frequency planning.) So even
without a customer taking up their part of the load (and I agree with you that
there are parts of the risk that they should bear), we can produce the
information we need that tells us how well we are doing at getting done on time.
Knowing how we're doing, in turn, allows us to take action if we find we're off
track, such as go back to the customer early, negotiate for more time, more m
money, less to do, and so on. These things aren't special to XP, they are the
kinds of things that all companies do when they (finally) figure out that
they're in trouble on the deliverables.
So it seems to me that, while it's really just a metaphor, the notion that XP is
(inherently) a risk-management strategy ... holds water. ;->
N'est pas?
Paul Sinnett
> 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
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.s...@btinternet.com> wrote in
news:3f28...@news.totallyobjects.com:
SUPER KOOL 223
rockin post. What if you find a niche or some other angle to reduce
competition, so that the difficulty of the stuff you're doing goes
down, but the perception of difficulty, or lack of supply, let's
you charge the same or more. Customers have no clue about the actual
difficulty of stuff they're paying for, it's market competition that
decides the price--you're competing with too many other fat brains.
Would this be possible? Find a niche or outsource/buy the difficult
parts from a secret supplier. You probably already do this :-)
Always a quest for secret suppliers...
Paul Sinnett <paul.s...@btinternet.com> wrote in message news:<3f28...@news.totallyobjects.com>...
Ron Jeffries
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 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.
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 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?
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 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?
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 and developers agreed, in Iteration N. So the
feedback on mistundersood requirements is very rapid. In addition, the Customer
Acceptance Test ensures that the developers cannot so easily pull the wool over
the customer's eyes. I don't believe that most developers would try to do that,
but the tests ensure that it is at least much more difficult should it happen.
More commonly, the tests just discover mistakes in communication or errors in
implementation.
The Planning Game addresses risk in two ways. First, the Release Plan practice
provides a frequent look at the overall project progress. This lets the customer
detect risks of delayed delivery or incomplete delivery. In addition, the
Iteration Plan allows the customer to address which requirements will be done
first, providing the ability to maximize the return on programming investment,
at a very detailed level. The customer can dial back frills in features, can
defer lower priorities in favor of higher ones, can even change his mind if he
sees some aspects of "wrong product" late in the process.
In short, in my very considered opinion, XP /properly reflects/ the true
apportionment of risk management responsibility between customers and
developers. I wouldn't say it /changes/ the apportionment, it merely reflects
the reality of what developers do, and do not, already have or take
responsibility for in projects.
And, XP practices materialize clear and frequent feedback addressing the major
customer-related concerns.
>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?
As your question is phrased, it seems to me to ask: "If owing to a contract,
developers have to take on risks that XP would say belong to the customer,
doesn't that mean that we have to take on risks that XP would say belong to the
customer?" Yes. If we assign responsibilities differently, we will be assigning
responsibilities differently. It seems almost tautological to me, so I must be
missing something. But I'll try to press on:
While I don't agree with the characterization of "transfer", I see the question.
I would answer that /the team/ will be doing things about some risks on behalf
of the customer. The XP practices still provide the information, though the
motivation might be slightly different, and the management of the practices
might come from the other side of the team.
>
>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.
As discussed above in detail, I believe that this is a serious misapprehension.
XP does in fact have tools that offer the customer the ability to deal with the
key project risks. We might want to discuss any risks that I've not touched on,
or to discuss in more detail what else might be done.
It is important to remember, as we talk about this, that XP is not supposed to
be a full catalog of practices that one might do. It is a minimalist catalog of
practices that are arranged to provide enough information about the project --
in all aspects -- to permit competent professionals to observe what is going on
and to adjust their specific practices to the specific situation. One might
prefer a more RUP-like or CMM-like process that lists everything that the
world's most complex project might want to do. That could be a good way to
define a process, though some might disagree. XP is not trying to define that
kind of process.
>
>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?
I don't see that at all. Any XP project "tacks on" additional practices that it
finds appropriate. Common are different kinds of testing, or additional kinds of
analysis to help the customers figure out what they want. Some teams that need
ultra-high reliability, or that choose not to pair program, sometimes add code
reviews.
I expect every XP team to modify practices, and I don't see a place where the
existing ones would get in the way. What are the risk management practices that
you might wish to "tack on", and what practices seem to you to resist that?
Regards,
Dirk Thierbach
Disclaimer: I don't know anything about the game industry, so maybe
what I am saying is just completely ignorant. In that case, feel free
to ignore it :-)
> 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.
> [The publishers] 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
Why? The publishers could actually reduce their risk of "getting
burned". The publishers want to have a game that say can sell, and
they want to have it in time, and (of course) they don't want to pay
too much for it, so they can themselves make more profit. So I think
the publishers would be better off if the were in a situation to
better control what features go into the game for their money, what
features turn out to be unnecessary, and what features would cost very
little but substantially improve the chances of the game beeing a
success.
> 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.
But this alternative only seems necessary if all the contracts include
"all or nothing" risks. If they have finer control about a particular
contract, they don't have to do risk management with a collection of
contracts. Even if the developing company has to pay fines if they
don't deliver in time, AFAIK there is still some risk that the project
just goes down completely and in the end there is no company that can
pay the fine (but you know better than me if this applies to your kind
of market).
> 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.
So here's the problem: Because the contract is "all or nothing", you
have to include slack. If you can reduce the slack, while getting the
same pay, you make somewhat more profit. At the same time, the publisher
also wins, because better control means he has to take less risk,
he will get a usuable game in the end, and he can estimate the amount
of money he has to spend for that a lot better.
> 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.
If these internal projects are related to some contract, the publisher
should be expected to pay at least some part of them. If they are not,
why should the publisher be willing to pay at all for them? And if you
cannot make money with those internal projects, why do you want to
do them at all?
> So we have the burdon of the risk. And we can't avoid that risk, and
> let the customer deal with it.
So it looks like you have to talk to the publisher(s) and convince
them that it is a win-win situation for both of you if they move away
from the "all or nothing" contract.
> Our only alternative is to manage the risk such that we can squeeze
> extra profit out of it.
If the contracts remain fixed time I really don't see a way that XP
can help to "manage" that risk. I don't think XP is meant to deal with
that kind of situation.
- Dirk
Paul Sinnett
> Paul Sinnett <paul.s...@btinternet.com> wrote:
>> [The publishers] 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
>
> Why?
Because they would have to take on the responsibility for delivering the
product.
> The publishers could actually reduce their risk of "getting
> burned".
I agree with you. We just haven't been able to make the publishers see it
that way.
----
>> 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.
>
> But this alternative only seems necessary if all the contracts include
> "all or nothing" risks. If they have finer control about a particular
> contract, they don't have to do risk management with a collection of
> contracts. Even if the developing company has to pay fines if they
> don't deliver in time, AFAIK there is still some risk that the project
> just goes down completely and in the end there is no company that can
> pay the fine (but you know better than me if this applies to your kind
> of market).
This does happen in practice. My intention was just to give a rough
background context without overcomplicating the issues.
----
>> 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.
>
> If these internal projects are related to some contract, the publisher
> should be expected to pay at least some part of them. If they are not,
> why should the publisher be willing to pay at all for them? And if you
> cannot make money with those internal projects, why do you want to
> do them at all?
Internal projects require a significant up-front investment by the developer
to get a game idea to prototype stage. This is before most publishers will
even consider looking at a project. Once signed, though, a publisher would
then foot all the development costs as an advance against royalties.
>> So we have the burdon of the risk. And we can't avoid that risk, and
>> let the customer deal with it.
>
> So it looks like you have to talk to the publisher(s) and convince
> them that it is a win-win situation for both of you if they move away
> from the "all or nothing" contract.
We'll keep trying. No bites yet.
>> Our only alternative is to manage the risk such that we can squeeze
>> extra profit out of it.
>
> If the contracts remain fixed time I really don't see a way that XP
> can help to "manage" that risk. I don't think XP is meant to deal with
> that kind of situation.
I think you're right. I don't think it was meant to either. Hence the
thread.
Paul Sinnett
> 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.
Then let's not use the term 'customer' for the driver in this situation.
I'll use the term 'proxy' for this role within the context of a truly fixed
contract.
> 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.
And that person, the proxy as I call them, takes on the responsibility for
managing the risk that has been passed by contractual means from the
customer. And it is the techniques that the proxy must use to manage that
risk that I am interested in.
In a T&M XP development the customer can specify the things that are most
important to them and be fairly sure that they will get something useful
and worthy of their investment at the end of each iteration; even if some
things get bumped.
A proxy doesn't have that luxury. He must deliver what is contracted more or
less without regard for the actual usefulness or value of any particular
feature. A proxy doesn't have access to the criteria that the customer
could use to prioritise and defer items. So the proxy can feed nothing into
the planning game. The risks to the project must be dealt with in some
other way.
Now the standard way of dealing with this, as Laurent posted earlier, is to
find the risks, prioritise them by exposure, and manage them, or at least
manage the currently most important ones.
We should catch as many up front as we can, because once the contract is
signed our options for managing them are reduced. And there is obviously no
problem doing this whatever process you use.
But once the project is running the XP practices themselves fight against
the options that we might otherwise use to manage the risks. For example,
to mitigate a risk we would by definition, have to add things up front to
the project that we aren't going to need (except to mitigate the risk, of
course). This fights against the principle of YAGNI. I'm not sure what the
planning game would make of it (but our planning game is crippled anyway
due to the fixed contract). It could also make the code more complicated
than it needs to be, moving us away from the practice of simple design.
We'd have to remember not to refactor it out - even thought it's not
needed. And so on.
Ron Jeffries
earlier posting, to which you've not yet had the chance to respond. I have to
entertain myself somehow ...
On Fri, 01 Aug 2003 00:55:30 +0100, Paul Sinnett <paul.s...@btinternet.com>
wrote:
>Otis Bricker wrote:
>> 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.
>
>Then let's not use the term 'customer' for the driver in this situation.
>I'll use the term 'proxy' for this role within the context of a truly fixed
>contract.
Well, OK. The XP role is, however, called Customer. If I wanted to emphasize
that it wasn't the person with the money customer, I might say Proxy Customer or
something. Anyway the term proxy will certainly work for now ...
>
>> 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.
The above is from Otis. As far as I know, this isn't really true in the usual
case. Almost every real "fixed" contract includes change management,
anticipates using it, and does use it. The customer changes its mind, and the
lack of spec clarity needs to be dealt with, and schedule problems need to be
dealt with. Many contracts are also closely monitored by a customer rep, often
on site, especially in government or other regulated situations.
>>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.
>
>And that person, the proxy as I call them, takes on the responsibility for
>managing the risk that has been passed by contractual means from the
>customer. And it is the techniques that the proxy must use to manage that
>risk that I am interested in.
Yes. I'm still not clear why you think that XP doesn't provide hooks for this,
and why you think that some of the things one would do would be a problem with
XP. Since XP teams are dealing with risk all the time -- and since the
customer-side risk /is/ provided for in XP, as I discussed in my posting above,
I'm not seeing the same problems that concern you. I'm hoping we can drill in on
that soon.
>
>In a T&M XP development the customer can specify the things that are most
>important to them and be fairly sure that they will get something useful
>and worthy of their investment at the end of each iteration; even if some
>things get bumped.
Yes. Or the customer can cancel the project if he doesn't like how things are
going. The proxy has /exactly/ the same capabilities.
>
>A proxy doesn't have that luxury. He must deliver what is contracted more or
>less without regard for the actual usefulness or value of any particular
>feature.
Yes, and no. Yes, he is working from a list of "given" priorities. Even in a
fixed situation, there probably are some features that are more critical than
others. Every fixed contract I have seen had that characteristic, at least. And
requirements can be met in varied ways, some elaborate, some simple. The proxy
would have substantial control over that.
>A proxy doesn't have access to the criteria that the customer
>could use to prioritise and defer items.
I have never encountered a project where the proxy couldn't talk to the real
customers when needed. And it would be silly, no matter what the team's process,
to have a proxy (or a team) without a deep understanding of what the
requirements mean and why they are the way they are. (I am sure that many teams
in fact use a silly approach to fixed price contracts, but it remains silly.)
>So the proxy can feed nothing into
>the planning game. The risks to the project must be dealt with in some
>other way.
Not correct. As you discuss below, the most important risk mitigation behavior
is to work on risky things first. Thus Boehm's spiral model, for example. A wise
proxy would do the same thing. Get the team to assess risk as well as they can,
and work on the risky stuff first. The risks to the project are dealt with in
the same way they always would.
>
>Now the standard way of dealing with this, as Laurent posted earlier, is to
>find the risks, prioritise them by exposure, and manage them, or at least
>manage the currently most important ones.
>
>We should catch as many up front as we can, because once the contract is
>signed our options for managing them are reduced. And there is obviously no
>problem doing this whatever process you use.
Right.
>
>But once the project is running the XP practices themselves fight against
>the options that we might otherwise use to manage the risks. For example,
>to mitigate a risk we would by definition, have to add things up front to
>the project that we aren't going to need (except to mitigate the risk, of
>course).
That's not how an XP project typically mitigates risk, and I would think it
wouldn't be how anyone would. The things to do at the beginning of the project
are the things that are risky. Not /other/ things -- do the risky things.
What are you envisioning that might want to be done that somehow an XP team
"could not" do?
>This fights against the principle of YAGNI.
I invented the YAGNI principle, and I can assure you that isn't what it means.
YAGNI means not to gild the lily, not to put things in because we think we are
going to need them. Risk mitigation is done because when a feature is risky, we
cannot accurately estimate the time to implement it. Might be a week, might be
forever. We are required by the Planning Game to be able to estimate. Therefore
we /must/ do an experiment, a prototype, or a small piece of the feature, so as
to remove the risk.
>I'm not sure what the
>planning game would make of it (but our planning game is crippled anyway
>due to the fixed contract).
Why is it crippled? The planning game has two pieces: release planning, which
tells us whether and how the pieces fit into the calendar, and iteration
planning, which tells us what to do this week. Both those pieces seem to me to
be perfectly applicable here.
>It could also make the code more complicated
>than it needs to be, moving us away from the practice of simple design.
>We'd have to remember not to refactor it out - even thought it's not
>needed. And so on.
I don't follow this. Perhaps you can think of something that we don't need that
we would need to code. The concept is foreign to me. And if it's not needed then
(a) why did we put it in, and (b) why can't we take it out?
Again, perhaps an example would help.
Have you tried XP in a fixed price situation? Perhaps a story about something
that actually gave you trouble would help. As the thread stands, the problems
you're raising seem awfully speculative to me, and not in line with my
experience with XP in general. (But I haven't done a fixed-price contract with
XP, mind y ou. I just have a pretty good sense from the ones I've done the
old-fashioned way, what I would do today.)
Regards,
Otis Bricker
<snip>
>>
>>> 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.
>
> The above is from Otis. As far as I know, this isn't really true in
> the usual case. Almost every real "fixed" contract includes change
> management, anticipates using it, and does use it. The customer
> changes its mind, and the lack of spec clarity needs to be dealt with,
> and schedule problems need to be dealt with. Many contracts are also
> closely monitored by a customer rep, often on site, especially in
> government or other regulated situations.
>
I have been lucky in that I have never had to worry about the contractual
issues myself. It was just that the discussion up to now seemd to imply
that there would be NO changes. If these are a possiblity, it seems clear
that the Proxy Customer's job is getting the customer a result that they
will be happy with, not just meeting the contract. A major part of this
will be satisfying the contract obligations. But within those limits there
will is still flexiblity. If they are happier dropping feature Z while
having you improve on feature F, they still have that option.
Phlip
> issues myself. It was just that the discussion up to now seemd to imply
> that there would be NO changes. If these are a possiblity, it seems clear
> that the Proxy Customer's job is getting the customer a result that they
> will be happy with, not just meeting the contract. A major part of this
> will be satisfying the contract obligations. But within those limits there
> will is still flexiblity. If they are happier dropping feature Z while
> having you improve on feature F, they still have that option.
In my humble opinion, there is a lower limit to the scale a requirements
document goes to, and there's a lower limit below which it should not go.
For a given document one of those limits may be above or below the other
one.
So, where the paperwork ends and reality begins, the onsite customer
controls scope. They inspect each feature as it grows in real time, and say
when to stop. So if the contract calls for "file selector dialogs with
suitable feedback displaying attributes of the file to be selected", then
for this dialog they say "forget it - nobody needs to see that attribute;
they are just going to open the file anyway", and for that dialog they
review a set of attributes and say, "Okay, that's enough; don't waste time
displaying the more complex attributes".
These chronic improvements to the schedule add up over time. But, on a
traditional project, the OC can't see the features behind a maze of trivial
bugs and UML diagrams and such, so they can't use a line-item veto. So they
must over-specify the documentation.
--
Phlip
Dirk Thierbach
> Paul Sinnett <paul.s...@btinternet.com>
>> A proxy doesn't have access to the criteria that the customer
>> could use to prioritise and defer items.
> I have never encountered a project where the proxy couldn't talk to
> the real customers when needed.
But in the game industry, the real customers are all the end-users
who will play the game. The proxy is the publisher. So the proxy has
to somehow guess what the end-users really want -- they cannot talk
to all of them, and they certainly cannot involve all of them (or
even some representative sample) in the sort of feedback process XP
requires.
- Dirk
Dirk Thierbach
> Dirk Thierbach wrote:
>> Paul Sinnett <paul.s...@btinternet.com> wrote:
>>> [The publishers] 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
>> Why?
> Because they would have to take on the responsibility for delivering the
> product.
But they already have to take on that responsibility. They just manage
it differently, by having a portfolio of projects: Even if one product
is not delivered, on average they will make profit.
>> The publishers could actually reduce their risk of "getting
>> burned".
> I agree with you. We just haven't been able to make the publishers
> see it that way.
So you have to think of some way to convince them. For example, you
could make a publisher two offers: On the one hand, the usual fixed
price contract. On the other hand, XP style with some sort of low cost
time & materials contract with a bonus system, like it was suggested
in this NG some time ago.
Then show the publisher how you arrived at the fixed price, and be
honest about the amount of slack you included (they should understand
why you need the slack. If they don't, it is not worth talking to them
in the first place). Now point out that if you're not going to need
all the slack, the publisher will have to pay less for the program
with the T&M contract. If you do the T&M contract right, your company
will also benefit, but they won't benefit as much as with the fixed
contract. And what's more, the publisher may even decide to include
less features in the game once they see it is working and ready to
sale, so they might even have to pay less.
On the other hand, if the game takes longer to complete, the publisher
will only have to pay the low T&M rates. So this will hurt you (because
you cannot do other work during that time), and it will hurt the publisher
(because they have to pay more), but it won't hurt you as much as for
the fixed cost contract, and it won't hurt the publisher as much as
loosing the whole project. Moreover, since the publisher is in control
as XP Customer, he will be able to see this situation coming early, and
he will be able to deal with it by cutting down on features etc.
Try this with a low risk project first. It should be very likely that
this project will finish up early, so compared to the fixed contract,
your company will loose. But once the publisher sees that this kind of
contract works, you can do it with a high risk project: This will give
you more profit, and at the same time reduce the risk of failure for
the publisher.
The one thing the publisher does not want to do is to "pay you until
it is finished". Try to explain to them that this is not a risk they
have to take because (1) there will always be a working program,
(2) the XP Customer decides when it is finished and (3) the Customer
can control what has to be done in which order.
On other words, try to bait them a bit :-) Does this make any sense?
I think by using a fixed contract, both parties are introducing
aritifical risk. The developing company is betting that they will be
able to complete the project in time. The customer is betting that the
final project will look and work the way it should, and that the
developers will be able to complete the project at all.
This bet is somewhat stupid, because neither side really has enough data
to estimate the odds properly. Both sides are working against each other.
In XP, both sides are working together.
It's the classical prisoner dilemma: If one side doesn't cooperate, it
might be able to win more. If both sides cooperate, there won't be a
risk, and both sides will gain, though they will gain less.
- Dirk
Ron Jeffries
XP recommends that, does not require it. We point out that it works better with
feedback from real users. I would think that game publishers do get some
feedback and could get more if they wanted to.
But XP is indifferent -- as is every software development process -- to the
quality of the business decisions behind the feature list. No pure development
process cares whether the spec is a good idea or not, though a more broad
business process would care. XP provides small releases, and customer tests, and
planning information, so that the business people have the ABILITY to get
important feedback from real users on a regular basis. We cannot make them do
it. If they don't do it, then all processes, XP and any other, are running
equally blind.
The problem is real, but it is in no way that I can see special to XP.
SUPER KOOL 223
[...]
>
> These chronic improvements to the schedule add up over time. But, on a
> traditional project, the OC can't see the features behind a maze of trivial
> bugs and UML diagrams and such, so they can't use a line-item veto. So they
> must over-specify the documentation.
wow. yeah. line items. can I use xslt for that?