Expected value of slack

[Kent Beck]

Ron,

I've been thinking about your question, "Isn't the expected value of 12 gold
higher than the expected value of 8 gold and 4 silver?" I believe the answer
is yes, the expected value is higher for 12 gold *IF* you only look at the
mirco-scale of development itself. If you look at the bigger picture, of the
whole organization creating value from software, then the expected value of
a 95% chance of 6 gold is most likely much higher than the expected value of
a 50% chance of 12 gold. If we put 12 gold into our schedule, marketing
prepares their materials based on 12 gold, we ask customers lots of
questions about all 12 gold so they start anticipating having all 12, the
sales teams sells all 12 gold, then, when half the time we don't deliver the
whole thing comes apart. We put more up-front planning in place (which can
easily chew up 30-40% of the schedule). We put in QA phases which are really
slack-in-disguise to finish the features. Marketing insists on beta testing,
which is a big disruption. Sales knows they are mostly selling vaporware, so
they act accordingly and so do the customers. The friction of uncertainty
brings the flow of value to a crawl.

That's why you insert slack. You crank up the certainty of your scheduling
until the value begins to flow. Then you slowly crank up the speed as your
ability to estimate improves.

Kent Beck
Three Rivers Institute

[Tim King]

Post by Kent Beck
If we put 12 gold into our schedule, marketing
prepares their materials based on 12 gold...
then, when half the time we don't deliver the
whole thing comes apart.

Hi, Kent. On the other hand, if you put 12 gold into the schedule, but
only commit to 6, and everybody prepares for 6 gold, then when we
deliver only 6, everyone's satisfied. And the next iteration, when we
commit to another 6 but deliver 18, they're ecstatic. We deliver on
average 12 per iteration, but can only commit to 6. (The actual math of
course isn't this simple, but I think this gets the idea across.)

If instead, we commit to 6 gold plus 6 silver, and deliver 6 gold only--
Maybe it isn't as bad as if we had committed to 12 gold, but it's still
sub-optimal. We're still failing to deliver on our committments half the
time. And the next iteration, the best we will deliver is 6 gold plus
some number of silver, never 18 gold.

Some stakeholders will have a really hard time understanding how you can
schedule 12 gold without committing to them. Others won't. I actually
once worked in an environment where we were able to divvy up our
committments this way, and everyone was happy with that arrangement.

-TimK

[Ron Jeffries]

Kent,

I understand the notion, I think, about committing 12 gold vs 6, and
it strikes me as valid right now, though my brain has been sucked
out by students here in New Mexico so I will think on it further
after it grows back.

However, one of the ideas that was being bandied about was asking
whether we should schedule 12 gold, or 8 gold and 4 silver. It seems
to me that in that case, we ask customers all the questions, the
sales guys sell the 4 silver, and so on and so on. So the down sides
are more or less equal, but the upside is lower.

So I get that we might want to under-commit and over-deliver. But I
still don't see the argument for 8G+4S being better than 12G, except
under the Root Canal Theory of Scheduling. That's where I'm still
stuck.

Thanks,

Ron Jeffries
www.XProgramming.com
No one expects the Spanish Inquisition ...

Post by Kent Beck
I've been thinking about your question, "Isn't the expected value of 12 gold
higher than the expected value of 8 gold and 4 silver?" I believe the answer
is yes, the expected value is higher for 12 gold *IF* you only look at the
mirco-scale of development itself. If you look at the bigger picture, of the
whole organization creating value from software, then the expected value of
a 95% chance of 6 gold is most likely much higher than the expected value of
a 50% chance of 12 gold. If we put 12 gold into our schedule, marketing
prepares their materials based on 12 gold, we ask customers lots of
questions about all 12 gold so they start anticipating having all 12, the
sales teams sells all 12 gold, then, when half the time we don't deliver the
whole thing comes apart. We put more up-front planning in place (which can
easily chew up 30-40% of the schedule). We put in QA phases which are really
slack-in-disguise to finish the features. Marketing insists on beta testing,
which is a big disruption. Sales knows they are mostly selling vaporware, so
they act accordingly and so do the customers. The friction of uncertainty
brings the flow of value to a crawl.
That's why you insert slack. You crank up the certainty of your scheduling
until the value begins to flow. Then you slowly crank up the speed as your
ability to estimate improves.

[Rex Madden]

I'm getting confused by this analogy. Are we assuming that the 4
silver are less work? If it's the same amount of work, why wouldn't
you just say that we'll commit to 8 gold, and if everything goes well,
we'll get to the other 4?


On Wed, 9 Mar 2005 21:43:53 -0700, Ron Jeffries

Post by Ron Jeffries
Kent,
I understand the notion, I think, about committing 12 gold vs 6, and
it strikes me as valid right now, though my brain has been sucked
out by students here in New Mexico so I will think on it further
after it grows back.
However, one of the ideas that was being bandied about was asking
whether we should schedule 12 gold, or 8 gold and 4 silver. It seems
to me that in that case, we ask customers all the questions, the
sales guys sell the 4 silver, and so on and so on. So the down sides
are more or less equal, but the upside is lower.
So I get that we might want to under-commit and over-deliver. But I
still don't see the argument for 8G+4S being better than 12G, except
under the Root Canal Theory of Scheduling. That's where I'm still
stuck.
Thanks,
Ron Jeffries
www.XProgramming.com
No one expects the Spanish Inquisition ...

Post by Kent Beck
I've been thinking about your question, "Isn't the expected value of 12

gold

Post by Kent Beck
higher than the expected value of 8 gold and 4 silver?" I believe the

answer

Post by Kent Beck
is yes, the expected value is higher for 12 gold *IF* you only look at the
mirco-scale of development itself. If you look at the bigger picture, of

the

Post by Kent Beck
whole organization creating value from software, then the expected value

of

Post by Kent Beck
a 95% chance of 6 gold is most likely much higher than the expected value

of

Post by Kent Beck
a 50% chance of 12 gold. If we put 12 gold into our schedule, marketing
prepares their materials based on 12 gold, we ask customers lots of
questions about all 12 gold so they start anticipating having all 12, the
sales teams sells all 12 gold, then, when half the time we don't deliver

the

Post by Kent Beck
whole thing comes apart. We put more up-front planning in place (which can
easily chew up 30-40% of the schedule). We put in QA phases which are

really

Post by Kent Beck
slack-in-disguise to finish the features. Marketing insists on beta

testing,

Post by Kent Beck
which is a big disruption. Sales knows they are mostly selling vaporware,

so

Post by Kent Beck
they act accordingly and so do the customers. The friction of uncertainty
brings the flow of value to a crawl.
That's why you insert slack. You crank up the certainty of your scheduling
until the value begins to flow. Then you slowly crank up the speed as your
ability to estimate improves.

Yahoo! Groups Sponsor
ADVERTISEMENT
________________________________
Yahoo! Groups Links
http://groups.yahoo.com/group/xpbookdiscussiongroup/
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

[Ron Jeffries]

Post by Rex Madden
I'm getting confused by this analogy. Are we assuming that the 4
silver are less work? If it's the same amount of work, why wouldn't
you just say that we'll commit to 8 gold, and if everything goes well,
we'll get to the other 4?

I understood the suggestion to be to select 4 equally difficult, but
less valuable stories for the last four. I understood the notion
behind it to be that if we fell short, the disappointment would be
lower.

If the above is the idea, like you, I'm not getting it. I'd be
inclined to commit to what I was sure of, with a range of
uncertainty scaled to the taste of the customer, and always to work
on important things rather than less important.

Nonetheless, wise people have expressed this idea and so I'm still
open to the idea that I'm just not getting it yet.

Ron Jeffries
www.XProgramming.com
For me, XP ain't out there, it's in here. -- Bill Caputo

[Rex Madden]

OK, so the assumptions are:

1 gold is more valuable than 1 silver.
1 gold is the same effort as 1 silver.
There are enough gold and silvers to keep you busy for several iterations.

In that case, why would you ever work on silvers?

I believe the notion of slack, in a lean thinking sense, was
introduced to make sure that non-bottleneck resources would not become
bottlenecks. It doesn't mean that those resources should be working
on less important stuff.

On Thu, 10 Mar 2005 07:35:48 -0700, Ron Jeffries

Post by Ron Jeffries

Post by Rex Madden
I'm getting confused by this analogy. Are we assuming that the 4
silver are less work? If it's the same amount of work, why wouldn't
you just say that we'll commit to 8 gold, and if everything goes well,
we'll get to the other 4?

I understood the suggestion to be to select 4 equally difficult, but
less valuable stories for the last four. I understood the notion
behind it to be that if we fell short, the disappointment would be
lower.
If the above is the idea, like you, I'm not getting it. I'd be
inclined to commit to what I was sure of, with a range of
uncertainty scaled to the taste of the customer, and always to work
on important things rather than less important.
Nonetheless, wise people have expressed this idea and so I'm still
open to the idea that I'm just not getting it yet.
Ron Jeffries
www.XProgramming.com
For me, XP ain't out there, it's in here. -- Bill Caputo
Yahoo! Groups Sponsor
ADVERTISEMENT
________________________________
Yahoo! Groups Links
http://groups.yahoo.com/group/xpbookdiscussiongroup/
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

[Tim King]

Post by Rex Madden
I believe the notion of slack, in a lean thinking sense, was
introduced to make sure that non-bottleneck resources would not become
bottlenecks. It doesn't mean that those resources should be working
on less important stuff.

This is certainly the case with Critical Chain project management. There
are a few different ways slack (or "buffers") might be added, all in
order to ensure that (1) we are working on critical stuff as quickly and
directly as practical and (2) we are available when needed to work on
the critical stuff.

-TimK

[Erik Meade]

Post by Ron Jeffries

Post by Rex Madden
I'm getting confused by this analogy. Are we assuming that the 4
silver are less work? If it's the same amount of work, why wouldn't
you just say that we'll commit to 8 gold, and if everything goes well,
we'll get to the other 4?

If the above is the idea, like you, I'm not getting it. I'd be
inclined to commit to what I was sure of, with a range of
uncertainty scaled to the taste of the customer, and always to work
on important things rather than less important.

I'm having a hard time as well. If the customer understands
the value in slack, can't we just work on what is important?

Erik Meade

[Kent Beck]

Erik,

It is a question of working on what's important. The relationship is what is
important. Delivering all that you've committed to every iteration shows
your team to be trustworthy--they(customer, management, team members) can
believe what you tell them. The Winner Habit is extremely valuable, both for
the team and the organization. It frees you to get on with what you do best,
writing great programs(or lots of mediocre ones!).

Kent Beck
Three Rivers Institute

-----Original Message-----
Sent: Thursday, March 10, 2005 12:08 PM
Subject: Re: [xpe2e] Expected value of slack

Post by Ron Jeffries

Post by Rex Madden
I'm getting confused by this analogy. Are we assuming that the 4
silver are less work? If it's the same amount of work,

why wouldn't

Post by Ron Jeffries

Post by Rex Madden
you just say that we'll commit to 8 gold, and if

everything goes well,

Post by Ron Jeffries

Post by Rex Madden
we'll get to the other 4?

If the above is the idea, like you, I'm not getting it. I'd be
inclined to commit to what I was sure of, with a range of
uncertainty scaled to the taste of the customer, and always to work
on important things rather than less important.

I'm having a hard time as well. If the customer understands
the value in slack, can't we just work on what is important?
Erik Meade
Yahoo! Groups Links

[Ron Jeffries]

Post by Kent Beck
Delivering all that you've committed to every iteration shows
your team to be trustworthy--they(customer, management, team members) can
believe what you tell them. The Winner Habit is extremely valuable, both for
the team and the organization.

Kent,

I'd like to be sure that you mean what I'm hearing here. Is it your
advice/intention now to schedule in such a way that the team never
misses completing a scheduled story in any iteration?

Ron Jeffries
www.XProgramming.com
Here is Edward Bear, coming downstairs now, bump, bump, bump, on the back
of his head. It is, as far as he knows, the only way of coming downstairs,
but sometimes he feels that there really is another way, if only he could
stop bumping for a moment and think of it. And then he feels that perhaps
there isn't. -- A. A. Milne

[Girts Kalnins]

I read it as reducing psychological pressure at the end of iteration.
That could serve as compensation for natural pressure that comes from
willingness to achieve. If we schedule "silver" coins at the end, we
still work as focused as before, not over.

G'irts Kalnins

Post by Kent Beck
Delivering all that you've committed to every iteration shows
your team to be trustworthy--they(customer, management, team members) can
believe what you tell them. The Winner Habit is extremely valuable, both for
the team and the organization.

RJ> Kent,

RJ> I'd like to be sure that you mean what I'm hearing here. Is it your
RJ> advice/intention now to schedule in such a way that the team never
RJ> misses completing a scheduled story in any iteration?

RJ> Ron Jeffries

[William E Caputo]

Is it your advice/intention now to schedule in such a way that the team
never misses completing a scheduled story in any iteration?

Never say never in email.

Best,
Bill

William E. Caputo
ThoughtWorks, Inc.
http://www.williamcaputo.com
--------
Never get so caught up in cutting wood that you forget to sharpen your ax.

[Kent Beck]

Ron,

The rule I have for how much to schedule seems simple but it isn't easy--be
honest with yourself and your customer about how much you can do.

Kent Beck
Three Rivers Institute

-----Original Message-----
Sent: Friday, March 11, 2005 4:13 AM
Subject: Re: [xpe2e] Expected value of slack

Post by Kent Beck
Delivering all that you've committed to every iteration shows
your team to be trustworthy--they(customer, management,

team members) can

Post by Kent Beck
believe what you tell them. The Winner Habit is extremely

valuable, both for

Post by Kent Beck
the team and the organization.

Kent,
I'd like to be sure that you mean what I'm hearing here. Is it your
advice/intention now to schedule in such a way that the team never
misses completing a scheduled story in any iteration?
Ron Jeffries
www.XProgramming.com
Here is Edward Bear, coming downstairs now, bump, bump, bump,
on the back
of his head. It is, as far as he knows, the only way of
coming downstairs,
but sometimes he feels that there really is another way, if
only he could
stop bumping for a moment and think of it. And then he feels
that perhaps
there isn't. -- A. A. Milne
Yahoo! Groups Links

[Ron Jeffries]

Post by Kent Beck
The rule I have for how much to schedule seems simple but it isn't easy--be
honest with yourself and your customer about how much you can do.

That one I like. No frills. I agree that some people don't find it
easy ... sometimes I think I'm getting pretty good at it, but my
environment is pretty easy.

Post by Kent Beck
Ignoring my advice for the moment, what is your advice to teams about how
much work they should plan and the nature of that plan (e.g. commitment,
promise, best guess, just a plan,...)?

Fair question. Here's what I generally do. I guess it's an estimate.
More than a guess, less than a promise. I don't see how it is
possible to make an honest promise and always keep it, other than by
underestimating. Which isn't honest.

I would start with simple yesterday's weather, adjusted (as we
always did on C3) with a bit of Kentucky windage. Schedule that many
stories, customer's choice.

Expect some variation around YW, plus or minus, sometimes better,
sometimes worse. I prefer individuals signing up for stories,
perhaps with pre-planned help from a chosen pair, but would live
with pairs signing up. I like the accountability that comes from
stories belonging to someone.

If done early, help someone else, ask for another story, or if
there's hygiene work to be done, maybe do that. If running late,
negotiate with customer early on to split the story or at least
soften the blow.

My usual recommendation to the customer is to be reasonable if the
team comes to them early, and to exhibit rather a bit of
disappointment if the first word the customer gets of an incomplete
story is at the end of the iteration.

If the customer always threw a tantrum when the team came in under,
I would be inclined to sit down with them and explain the nature of
estimation, and offer to always estimate on the low end, while
recommending against it.

Or, I might suggest producing a range plan: five [virtually?]
guaranteed, seven most likely, nine if we get really lucky.

But I've never had that happen. In my experience, after a little
startup confusion, customers always appreciate the honesty and know
that the team is working hard to deliver according to the plan. It
would be an odd customer who didn't recognize the nature of an
estimate: one who never fell short on his own estimates. That would
be a rare person indeed.

Comments?

Ron Jeffries
www.XProgramming.com
The greatest mistake we make is living in constant fear that we will make one.
-- John Maxwell

[Nigel Thorne]

Please tell me about your "Kentucky windage" Ron.

Cheers
Nigel

On Mon, 14 Mar 2005 21:37:21 -0700, Ron Jeffries

Post by Kent Beck

Post by Kent Beck
The rule I have for how much to schedule seems simple but it isn't

easy--be

Post by Kent Beck
honest with yourself and your customer about how much you can do.

That one I like. No frills. I agree that some people don't find it
easy ... sometimes I think I'm getting pretty good at it, but my
environment is pretty easy.

Post by Kent Beck
Ignoring my advice for the moment, what is your advice to teams about how
much work they should plan and the nature of that plan (e.g. commitment,
promise, best guess, just a plan,...)?

Fair question. Here's what I generally do. I guess it's an estimate.
More than a guess, less than a promise. I don't see how it is
possible to make an honest promise and always keep it, other than by
underestimating. Which isn't honest.
I would start with simple yesterday's weather, adjusted (as we
always did on C3) with a bit of Kentucky windage. Schedule that many
stories, customer's choice.
Expect some variation around YW, plus or minus, sometimes better,
sometimes worse. I prefer individuals signing up for stories,
perhaps with pre-planned help from a chosen pair, but would live
with pairs signing up. I like the accountability that comes from
stories belonging to someone.
If done early, help someone else, ask for another story, or if
there's hygiene work to be done, maybe do that. If running late,
negotiate with customer early on to split the story or at least
soften the blow.
My usual recommendation to the customer is to be reasonable if the
team comes to them early, and to exhibit rather a bit of
disappointment if the first word the customer gets of an incomplete
story is at the end of the iteration.
If the customer always threw a tantrum when the team came in under,
I would be inclined to sit down with them and explain the nature of
estimation, and offer to always estimate on the low end, while
recommending against it.
Or, I might suggest producing a range plan: five [virtually?]
guaranteed, seven most likely, nine if we get really lucky.
But I've never had that happen. In my experience, after a little
startup confusion, customers always appreciate the honesty and know
that the team is working hard to deliver according to the plan. It
would be an odd customer who didn't recognize the nature of an
estimate: one who never fell short on his own estimates. That would
be a rare person indeed.
Comments?
Ron Jeffries
www.XProgramming.com
The greatest mistake we make is living in constant fear that we will make one.
-- John Maxwell
Yahoo! Groups Sponsor
ADVERTISEMENT
________________________________
Yahoo! Groups Links
http://groups.yahoo.com/group/xpbookdiscussiongroup/
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

[Ron Jeffries]

Post by Nigel Thorne
Please tell me about your "Kentucky windage" Ron.

"Welp, Bessie Mae, last iteration we planned 30 points and only got
24 done. But we were slowed down by the All Hands Convocation;
otherwise we would probably have made it. So we should schedule 30
this iteration, not just 24. But Billy Bob is going hunting for the
second week. That'll cost us four. Let's schedule 26."

Ron Jeffries
www.XProgramming.com
To follow the path:
Look to the master; Follow the master; Walk with the master;
See through the master; Become the master. -- Modern Zen Poem

[Erik Meade]

Kent, thanks for the reply.

Sorry if I missed that gold and silver coins are a tactic to build
trust. Like bug tracking for a greenfield xp project, I assumed we
don't need the tool to start with. I've coached teams who's customers
didn't trust them, sometimes the customers where to busy to be in
the same room with the developers and didn't see how long/hard/
dedicated the team did work. Sometimes a team really blows an
interation and the customer gets surprised (if he wasn't in the
room and not attending the standups). But most times even if we
didn't hit our estimates 100% everytime, the customer had no doubts
that we did better than "the old way". If I used the gold silver
coin tactic I would be looking forward to the time when earned
enough trust to not need it.

Erik Meade

Post by Kent Beck
Erik,
It is a question of working on what's important. The relationship is what is
important. Delivering all that you've committed to every iteration shows
your team to be trustworthy--they(customer, management, team members) can
believe what you tell them. The Winner Habit is extremely valuable, both for
the team and the organization. It frees you to get on with what you do best,
writing great programs(or lots of mediocre ones!).
Kent Beck
Three Rivers Institute

-----Original Message-----
Sent: Thursday, March 10, 2005 12:08 PM
Subject: Re: [xpe2e] Expected value of slack

Post by Ron Jeffries

Post by Rex Madden
I'm getting confused by this analogy. Are we assuming that the 4
silver are less work? If it's the same amount of work,

why wouldn't

Post by Ron Jeffries

Post by Rex Madden
you just say that we'll commit to 8 gold, and if

everything goes well,

Post by Ron Jeffries

Post by Rex Madden
we'll get to the other 4?

If the above is the idea, like you, I'm not getting it. I'd be
inclined to commit to what I was sure of, with a range of
uncertainty scaled to the taste of the customer, and always to work
on important things rather than less important.

I'm having a hard time as well. If the customer understands
the value in slack, can't we just work on what is important?
Erik Meade
Yahoo! Groups Links

Yahoo! Groups Links

[Erik Meade]

Thinking more about silver coins, seems that they are not
so different from "sand". Only they are scheduled. In
some cases I see getting them scheduled is better than
not doing them at all. I've seen sand used for more for
small techincal stories than customer features though.
The customer does gets value out of the sand, because
cleaning up the sand helps the team maintain it's pace
or go faster.

Erik Meade

Post by Erik Meade
Kent, thanks for the reply.
Sorry if I missed that gold and silver coins are a tactic to build
trust. Like bug tracking for a greenfield xp project, I assumed we
don't need the tool to start with. I've coached teams who's customers
didn't trust them, sometimes the customers where to busy to be in
the same room with the developers and didn't see how long/hard/
dedicated the team did work. Sometimes a team really blows an
interation and the customer gets surprised (if he wasn't in the
room and not attending the standups). But most times even if we
didn't hit our estimates 100% everytime, the customer had no doubts
that we did better than "the old way". If I used the gold silver
coin tactic I would be looking forward to the time when earned
enough trust to not need it.
Erik Meade

Post by Kent Beck
Erik,
It is a question of working on what's important. The relationship is what is
important. Delivering all that you've committed to every iteration shows
your team to be trustworthy--they(customer, management, team members) can
believe what you tell them. The Winner Habit is extremely valuable, both for
the team and the organization. It frees you to get on with what you do best,
writing great programs(or lots of mediocre ones!).
Kent Beck
Three Rivers Institute

-----Original Message-----
Sent: Thursday, March 10, 2005 12:08 PM
Subject: Re: [xpe2e] Expected value of slack

Post by Ron Jeffries

Post by Rex Madden
I'm getting confused by this analogy. Are we assuming that the 4
silver are less work? If it's the same amount of work,

why wouldn't

Post by Ron Jeffries

Post by Rex Madden
you just say that we'll commit to 8 gold, and if

everything goes well,

Post by Ron Jeffries

Post by Rex Madden
we'll get to the other 4?

If the above is the idea, like you, I'm not getting it. I'd be
inclined to commit to what I was sure of, with a range of
uncertainty scaled to the taste of the customer, and always to work
on important things rather than less important.

I'm having a hard time as well. If the customer understands
the value in slack, can't we just work on what is important?
Erik Meade
Yahoo! Groups Links

Yahoo! Groups Links

Yahoo! Groups Links

[BenAveling]

Hi Ron,

Normally, as engineers, we have the objective 'deliver maximum value
measured in functionality'.

That's usually the same thing as 'deliver maximum business value' but
not always.

Sometimes there are external dependencies.

Suppose that each coin has a nominated recipient who expects to receive
that coin on a given date.

They're making plans based on that date. We're fairly free to set any
expectation we like, but if we then move that date, there's a cost.

Consider the following schedules, each based on 3 coins per iteration.

.1..2..3..4..5..6.
GGGGGGGGGGGGGGGGGG

.1..2..3..4..5..6.
GGsGGsGGsGGsGGsGGs

Consider the impact of a one coin slip in iteration 1.

With schedule 1, there's a chain reaction and 6 gold coins slip by one
iteration.

With schedule 2, we discard one silver coin.

Sometimes, that's cheaper, and especially so if delivering coins early
also has a cost.

Regards, Ben

Post by Ron Jeffries
Kent,
I understand the notion, I think, about committing 12 gold vs 6, and
it strikes me as valid right now, though my brain has been sucked
out by students here in New Mexico so I will think on it further
after it grows back.
However, one of the ideas that was being bandied about was asking
whether we should schedule 12 gold, or 8 gold and 4 silver. It seems
to me that in that case, we ask customers all the questions, the
sales guys sell the 4 silver, and so on and so on. So the down sides
are more or less equal, but the upside is lower.
So I get that we might want to under-commit and over-deliver. But I
still don't see the argument for 8G+4S being better than 12G, except
under the Root Canal Theory of Scheduling. That's where I'm still
stuck.
Thanks,
Ron Jeffries
www.XProgramming.com
No one expects the Spanish Inquisition ...

Post by Kent Beck
I've been thinking about your question, "Isn't the expected value of 12 gold
higher than the expected value of 8 gold and 4 silver?" I believe the answer
is yes, the expected value is higher for 12 gold *IF* you only look at the
mirco-scale of development itself. If you look at the bigger picture, of the
whole organization creating value from software, then the expected value of
a 95% chance of 6 gold is most likely much higher than the expected value of
a 50% chance of 12 gold. If we put 12 gold into our schedule, marketing
prepares their materials based on 12 gold, we ask customers lots of
questions about all 12 gold so they start anticipating having all 12, the
sales teams sells all 12 gold, then, when half the time we don't deliver the
whole thing comes apart. We put more up-front planning in place (which can
easily chew up 30-40% of the schedule). We put in QA phases which are really
slack-in-disguise to finish the features. Marketing insists on beta testing,
which is a big disruption. Sales knows they are mostly selling vaporware, so
they act accordingly and so do the customers. The friction of uncertainty
brings the flow of value to a crawl.
That's why you insert slack. You crank up the certainty of your scheduling
until the value begins to flow. Then you slowly crank up the speed as your
ability to estimate improves.

Yahoo! Groups Links

[Tim King]

Post by BenAveling
Suppose that each coin has a nominated recipient who expects to receive
that coin on a given date.
They're making plans based on that date. We're fairly free to set any
expectation we like, but if we then move that date, there's a cost.
Consider the following schedules, each based on 3 coins per iteration.

Hi, Ben. You're making two new assumptions here. (At least, they're new
to me.) Firstly, that we are scheduling stories 6 iterations in advance.
Secondly, that we are _not_ adjusting our schedule based on ongoing
performance.

If we slip by one coin in the first iteration, is it because we
mis-estimated? Or is it due to normal statistical variation? If the
latter, other stories will likely be shorter and make up the difference,
and we will not be late overall. Probably, however, as we all know, it
was the former: we mis-estimated; and now we have to readjust our
schedule for only two coins per iteration. Or else we're likely to slip
by an additional coin in the other iterations, too.

-TimK

[Ron Jeffries]

Post by BenAveling
Normally, as engineers, we have the objective 'deliver maximum value
measured in functionality'.
That's usually the same thing as 'deliver maximum business value' but
not always.
Sometimes there are external dependencies.
Suppose that each coin has a nominated recipient who expects to receive
that coin on a given date.
They're making plans based on that date. We're fairly free to set any
expectation we like, but if we then move that date, there's a cost.
Consider the following schedules, each based on 3 coins per iteration.
.1..2..3..4..5..6.
GGGGGGGGGGGGGGGGGG
.1..2..3..4..5..6.
GGsGGsGGsGGsGGsGGs
Consider the impact of a one coin slip in iteration 1.
With schedule 1, there's a chain reaction and 6 gold coins slip by one
iteration.
With schedule 2, we discard one silver coin.
Sometimes, that's cheaper, and especially so if delivering coins early
also has a cost.

True, if you actually think you'll execute a pre-planned release
plan as originally planned. I'm not so sure the same reasoning
applies to iteration-by-iteration planning.

What would have to be true in iteration N to make it better to work
on a low business value story instead of a high business value one?
And can you answer that in such a way that I can't come back and
say, "Well, then doesn't the s have higher real business value than
the G?"

Ron Jeffries
www.XProgramming.com
Steering is more important than speed,
in driving and in software development.

[J. B. Rainsberger]

Post by Ron Jeffries

Post by BenAveling
Normally, as engineers, we have the objective 'deliver maximum value
measured in functionality'.
That's usually the same thing as 'deliver maximum business value' but
not always.
Sometimes there are external dependencies.
Suppose that each coin has a nominated recipient who expects to receive
that coin on a given date.
They're making plans based on that date. We're fairly free to set any
expectation we like, but if we then move that date, there's a cost.
Consider the following schedules, each based on 3 coins per iteration.
.1..2..3..4..5..6.
GGGGGGGGGGGGGGGGGG
.1..2..3..4..5..6.
GGsGGsGGsGGsGGsGGs
Consider the impact of a one coin slip in iteration 1.
With schedule 1, there's a chain reaction and 6 gold coins slip by one
iteration.
With schedule 2, we discard one silver coin.
Sometimes, that's cheaper, and especially so if delivering coins early
also has a cost.

True, if you actually think you'll execute a pre-planned release
plan as originally planned. I'm not so sure the same reasoning
applies to iteration-by-iteration planning.
What would have to be true in iteration N to make it better to work
on a low business value story instead of a high business value one?
And can you answer that in such a way that I can't come back and
say, "Well, then doesn't the s have higher real business value than
the G?"

I don't know whether I can do that, but I will point out that different
people will see different business value from the same stories, and not
just in the trivial kind of "we're all different" way.

The immediate customer might want stories that maximum her
organization's gross profit for 2005. The company employing that
customer might want stories that help sustain the company's production
rate from 2004-2009. The two are in opposition.

So let me ask you, if the s story improves production capacity over a
5-year period and the G story improved earned value over a 2-year
period, which has higher real business value?

[Ron Jeffries]

Post by J. B. Rainsberger
I don't know whether I can do that, but I will point out that different
people will see different business value from the same stories, and not
just in the trivial kind of "we're all different" way.
The immediate customer might want stories that maximum her
organization's gross profit for 2005. The company employing that
customer might want stories that help sustain the company's production
rate from 2004-2009. The two are in opposition.
So let me ask you, if the s story improves production capacity over a
5-year period and the G story improved earned value over a 2-year
period, which has higher real business value?

The customer has to decide, in the presence of as much information
as we can give.

Ron Jeffries
www.XProgramming.com
The rules are ways of thinking, not ways to avoid thinking.

[J. B. Rainsberger]

Post by Ron Jeffries

Post by J. B. Rainsberger
I don't know whether I can do that, but I will point out that different
people will see different business value from the same stories, and not
just in the trivial kind of "we're all different" way.
The immediate customer might want stories that maximum her
organization's gross profit for 2005. The company employing that
customer might want stories that help sustain the company's production
rate from 2004-2009. The two are in opposition.
So let me ask you, if the s story improves production capacity over a
5-year period and the G story improved earned value over a 2-year
period, which has higher real business value?

The customer has to decide, in the presence of as much information
as we can give.

Which "the customer"? Therein lies the rub.

I suppose one answer is simple: the only customer we have with us at the
present moment.

Are there any more satisfying answers out there?

[Nigel Thorne]

With
.1..2..3..4..5..6.
GGGGGGGGGGGGGGGGGG

.1..2..3..4..5..6.
GGsGGsGGsGGsGGsGGs

At the end of 6 iterations you have 18G vs 12G + 6s. Assuming G
contains more value than S ( which I think is the definition) then you
are delivering less value to the customer with the second schedule.

If you slip in iteration 1 you still deliver 17G vs 12G + 5s. The
customer can re-order the Gs to gain the most value, so the argument
that you are slipping 6Gs makes no sence to me. If you choose to slip
6Gs its because the G you choose to keep in 2 is of more value to you
than the one you slipped to 3... and so on. You are still delivering
the most value you can at any point in time.

Regards, Nigel

Post by BenAveling
Hi Ron,
Normally, as engineers, we have the objective 'deliver maximum value
measured in functionality'.
That's usually the same thing as 'deliver maximum business value' but
not always.
Sometimes there are external dependencies.
Suppose that each coin has a nominated recipient who expects to receive
that coin on a given date.
They're making plans based on that date. We're fairly free to set any
expectation we like, but if we then move that date, there's a cost.
Consider the following schedules, each based on 3 coins per iteration.
.1..2..3..4..5..6.
GGGGGGGGGGGGGGGGGG
.1..2..3..4..5..6.
GGsGGsGGsGGsGGsGGs
Consider the impact of a one coin slip in iteration 1.
With schedule 1, there's a chain reaction and 6 gold coins slip by one
iteration.
With schedule 2, we discard one silver coin.
Sometimes, that's cheaper, and especially so if delivering coins early
also has a cost.
Regards, Ben

Post by Ron Jeffries
Kent,
I understand the notion, I think, about committing 12 gold vs 6, and
it strikes me as valid right now, though my brain has been sucked
out by students here in New Mexico so I will think on it further
after it grows back.
However, one of the ideas that was being bandied about was asking
whether we should schedule 12 gold, or 8 gold and 4 silver. It seems
to me that in that case, we ask customers all the questions, the
sales guys sell the 4 silver, and so on and so on. So the down sides
are more or less equal, but the upside is lower.
So I get that we might want to under-commit and over-deliver. But I
still don't see the argument for 8G+4S being better than 12G, except
under the Root Canal Theory of Scheduling. That's where I'm still
stuck.
Thanks,
Ron Jeffries
www.XProgramming.com
No one expects the Spanish Inquisition ...

Post by Kent Beck
I've been thinking about your question, "Isn't the expected value of 12

gold

Post by Ron Jeffries

Post by Kent Beck
higher than the expected value of 8 gold and 4 silver?" I believe the

answer

Post by Ron Jeffries

Post by Kent Beck
is yes, the expected value is higher for 12 gold *IF* you only look at

the

Post by Ron Jeffries

Post by Kent Beck
mirco-scale of development itself. If you look at the bigger picture, of

the

Post by Ron Jeffries

Post by Kent Beck
whole organization creating value from software, then the expected value

of

Post by Ron Jeffries

Post by Kent Beck
a 95% chance of 6 gold is most likely much higher than the expected value

of

Post by Ron Jeffries

Post by Kent Beck
a 50% chance of 12 gold. If we put 12 gold into our schedule, marketing
prepares their materials based on 12 gold, we ask customers lots of
questions about all 12 gold so they start anticipating having all 12, the
sales teams sells all 12 gold, then, when half the time we don't deliver

the

Post by Ron Jeffries

Post by Kent Beck
whole thing comes apart. We put more up-front planning in place (which

can

Post by Ron Jeffries

Post by Kent Beck
easily chew up 30-40% of the schedule). We put in QA phases which are

really

Post by Ron Jeffries

Post by Kent Beck
slack-in-disguise to finish the features. Marketing insists on beta

testing,

Post by Ron Jeffries

Post by Kent Beck
which is a big disruption. Sales knows they are mostly selling vaporware,

so

Post by Ron Jeffries

Post by Kent Beck
they act accordingly and so do the customers. The friction of uncertainty
brings the flow of value to a crawl.
That's why you insert slack. You crank up the certainty of your

scheduling

Post by Ron Jeffries

Post by Kent Beck
until the value begins to flow. Then you slowly crank up the speed as

your

Post by Ron Jeffries

Post by Kent Beck
ability to estimate improves.

Yahoo! Groups Links

Yahoo! Groups Sponsor
ADVERTISEMENT
________________________________
Yahoo! Groups Links
http://groups.yahoo.com/group/xpbookdiscussiongroup/
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

[William Wake]

For the 12 gold vs. 8 gold + 4 silver problem, what do you think of
Scrum's approach? (At least in some manifestations..) They identify
both the set of stories for this sprint and a sprint goal. The sprint
goal is the "no matter what - bottom-line commitment". The other is a
commitment, but perhaps less so in some sense.

[Ilja Preuss]

Post by Kent Beck
Ron,
The rule I have for how much to schedule seems simple but it
isn't easy--be honest with yourself and your customer about how much
you can do.

Sounds good.

But, putting it into the context of prior posts, it seems to imply that you
say "committing to 8 gold plus 4 silver stories (where we don't know wether
we will actually complete the 4 silver) is more honest than comitting to 8
gold stories and leaving the option open for doing 4 more if we get the
time."

Is that what you are saying?

Confused, Ilja

[Ilja Preuss]

Post by Kent Beck
Ron,
I've been thinking about your question, "Isn't the expected
value of 12 gold higher than the expected value of 8 gold and
4 silver?" I believe the answer is yes, the expected value is
higher for 12 gold *IF* you only look at the mirco-scale of
development itself. If you look at the bigger picture, of the
whole organization creating value from software, then the
expected value of a 95% chance of 6 gold is most likely much
higher than the expected value of a 50% chance of 12 gold.

How does the former compare to the expected value of 95% chance of 6 gold
plus 50% chance of 6 more gold?

Curious, Ilja

[J. B. Rainsberger]

Post by Kent Beck
Erik,
It is a question of working on what's important. The relationship is what is
important. Delivering all that you've committed to every iteration shows
your team to be trustworthy--they(customer, management, team members) can
believe what you tell them. The Winner Habit is extremely valuable, both for
the team and the organization. It frees you to get on with what you do best,
writing great programs(or lots of mediocre ones!).

I wonder whether this whole Slack issue is merely (not to trivialize it)
a manifestation of Kent's personal experience with a string of customers
who just don't like their teams continually underdelivering?

So Kent, did you introduce Slack to solve a specific pattern of problems
you have encountered in projects? or did you simply decide it was a good
idea in general?

[Joshua Kerievsky]

Post by J. B. Rainsberger
I wonder whether this whole Slack issue is merely (not to trivialize it)
a manifestation of Kent's personal experience with a string of customers
who just don't like their teams continually underdelivering?
So Kent, did you introduce Slack to solve a specific pattern of problems
you have encountered in projects? or did you simply decide it was a good
idea in general?

J.B. -- I don't know Kent's reasoning -- and would love to hear it. I
do know that DeMarco's book on Slack is so excellent that having a
practice built around the idea makes a whole lot of sense. A few years
back I discussed with Kent the idea of substituting "Sustainable Pace"
for "Slack" in IXP. Back then I decided to stick with "Sustainable
Pace." At present, I don't have plans to include it. I see Slack as
being fully present in two IXP practices: Balanced Life (a forthcoming
replacement for "Sustainable Pace") and Continuous Learning.
--
best regards,
jk

----
I n d u s t r i a l L o g i c , I n c .
Joshua Kerievsky
Founder, Industrial XP Coach
http://industriallogic.com
http://industrialxp.org
866-540-8336 (toll free)
510-540-8336 (phone)
Berkeley, California

[J. B. Rainsberger]

Post by Joshua Kerievsky
J.B. -- I don't know Kent's reasoning -- and would love to hear it. I
do know that DeMarco's book on Slack is so excellent that having a
practice built around the idea makes a whole lot of sense. A few years
back I discussed with Kent the idea of substituting "Sustainable Pace"
for "Slack" in IXP. Back then I decided to stick with "Sustainable
Pace." At present, I don't have plans to include it. I see Slack as
being fully present in two IXP practices: Balanced Life (a forthcoming
replacement for "Sustainable Pace") and Continuous Learning.

I absolutely see how Slack likely follows from those two. Nice.

[Kent Beck]

JB,

I don't think slack is a manifestation of my experience alone. DeMarco wrote
a whole book on it. Theory of Constraints preaches about the value of
appropriately sized buffers. Even God had slack in his plan (see the fourth
commandment). I think that it would be arrogant for me to claim credit for
this as my personal contribution.

Kent Beck
Three Rivers Institute

-----Original Message-----
Sent: Tuesday, March 15, 2005 3:13 PM
Subject: Re: [xpe2e] Expected value of slack
I wonder whether this whole Slack issue is merely (not to
trivialize it)
a manifestation of Kent's personal experience with a string
of customers
who just don't like their teams continually underdelivering?
So Kent, did you introduce Slack to solve a specific pattern
of problems
you have encountered in projects? or did you simply decide it
was a good
idea in general?
--
J. B. (Joe) Rainsberger
Diaspar Software Services
http://www.diasparsoftware.com
Author, JUnit Recipes: Practical Methods for Programmer Testing

[J. B. Rainsberger]

Post by Kent Beck
a whole book on it. Theory of Constraints preaches about the value of
appropriately sized buffers. Even God had slack in his plan (see the fourth
commandment). I think that it would be arrogant for me to claim credit for
this as my personal contribution.

I don't think that was the question I wanted to ask. Let me try again.

Did you introduce slack as an explicit part of your description of XP
because of (insert rest of previous question here)?

No, Kent, I don't think you discovered slack. I read DeMarco and
Goldratt, too. :)

[Dakshinamurthy Karra]

On Thu, 17 Mar 2005 10:17:53 -0500, J. B. Rainsberger

Post by J. B. Rainsberger
No, Kent, I don't think you discovered slack. I read DeMarco and
Goldratt, too. :)

I did not read Goldratt, but read Slack by DeMarco. Mr. DeMarco's
Slack sounded like a message to organizations not to overload teams.
Kent's Slack seems entirely different to me. I am following this
thread closely and still did not understand the need for slack, except
as a practice to be used during the trust-building stage with the
customer. Let the discussions go on... may be at some time the fog
will clear for me.

Thanks and Regards
KD

[Keith Ray]

I think my understanding of this practice would be improved if it were
described like a design pattern:

context

what problem(s) does this solve (or not solve)

what forces are present

how to implement the solution

what alternative solutions address these and other forces

[Kent Beck]

JB,

Thanks for insisting on an answer. I introduced slack as a concept in XP to
free people to make and meet commitments. When there is a sense of enough
time, it is safe to commit. When you can do what you commit to do, there is
an increase in confidence and ability to produce and a deepening trust
relationship which frees you to do more with less stress.

Kent Beck
Three Rivers Institute

-----Original Message-----
Sent: Thursday, March 17, 2005 7:18 AM
Subject: Re: [xpe2e] Expected value of slack

Post by Kent Beck
I don't think slack is a manifestation of my experience
a whole book on it. Theory of Constraints preaches about

the value of

Post by Kent Beck
appropriately sized buffers. Even God had slack in his plan

(see the fourth

Post by Kent Beck
commandment). I think that it would be arrogant for me to

claim credit for

Post by Kent Beck
this as my personal contribution.

I don't think that was the question I wanted to ask. Let me try again.
Did you introduce slack as an explicit part of your description of XP
because of (insert rest of previous question here)?
No, Kent, I don't think you discovered slack. I read DeMarco and
Goldratt, too. :)

[J. B. Rainsberger]

Post by Kent Beck
Thanks for insisting on an answer. I introduced slack as a concept in XP to
free people to make and meet commitments. When there is a sense of enough
time, it is safe to commit. When you can do what you commit to do, there is
an increase in confidence and ability to produce and a deepening trust
relationship which frees you to do more with less stress.

So Slack is a way to make it safer to commit to work. I understand.

[Nigel Thorne]

Slack assumes the company want you to be more predictable and possibly
less prodictive.


On Thu, 24 Mar 2005 11:39:45 -0500, J. B. Rainsberger

Post by J. B. Rainsberger

Post by Kent Beck
Thanks for insisting on an answer. I introduced slack as a concept in XP

to

Post by Kent Beck
free people to make and meet commitments. When there is a sense of enough
time, it is safe to commit. When you can do what you commit to do, there

is

Post by Kent Beck
an increase in confidence and ability to produce and a deepening trust
relationship which frees you to do more with less stress.

So Slack is a way to make it safer to commit to work. I understand.
--
J. B. (Joe) Rainsberger
Diaspar Software Services
http://www.diasparsoftware.com
Author, JUnit Recipes: Practical Methods for Programmer Testing
Yahoo! Groups Sponsor
ADVERTISEMENT
________________________________
Yahoo! Groups Links
http://groups.yahoo.com/group/xpbookdiscussiongroup/
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

[Kent Beck]

Predictability leads to higher throughput.

Kent Beck
Three Rivers Institute

-----Original Message-----
Sent: Thursday, March 24, 2005 4:41 PM
Subject: Re: [xpe2e] Expected value of slack
Slack assumes the company want you to be more predictable and possibly
less prodictive.
On Thu, 24 Mar 2005 11:39:45 -0500, J. B. Rainsberger

Post by J. B. Rainsberger

Post by Kent Beck
Thanks for insisting on an answer. I introduced slack as

a concept in XP

Post by J. B. Rainsberger
to

Post by Kent Beck
free people to make and meet commitments. When there is a

sense of enough

Post by J. B. Rainsberger

Post by Kent Beck
time, it is safe to commit. When you can do what you

commit to do, there

Post by J. B. Rainsberger
is

Post by Kent Beck
an increase in confidence and ability to produce and a

deepening trust

Post by J. B. Rainsberger

Post by Kent Beck
relationship which frees you to do more with less stress.

So Slack is a way to make it safer to commit to work. I understand.
--
J. B. (Joe) Rainsberger
Diaspar Software Services
http://www.diasparsoftware.com
Author, JUnit Recipes: Practical Methods for Programmer Testing
Yahoo! Groups Sponsor
ADVERTISEMENT
________________________________
Yahoo! Groups Links
http://groups.yahoo.com/group/xpbookdiscussiongroup/
Your use of Yahoo! Groups is subject to the Yahoo! Terms of

Service.
--
Nigel Thorne
Extreme Programmer & Coach
www.nigelthorne.com
Yahoo! Groups Links

[Nigel Thorne]

I don't doubt you, but please can you explain how?

An example would be useful too.

thanks,
Nigel

Post by Kent Beck
Predictability leads to higher throughput.
Kent Beck
Three Rivers Institute

-----Original Message-----
Sent: Thursday, March 24, 2005 4:41 PM
Subject: Re: [xpe2e] Expected value of slack
Slack assumes the company want you to be more predictable and possibly
less prodictive.
On Thu, 24 Mar 2005 11:39:45 -0500, J. B. Rainsberger

Post by J. B. Rainsberger

Post by Kent Beck
Thanks for insisting on an answer. I introduced slack as

a concept in XP

Post by J. B. Rainsberger
to

Post by Kent Beck
free people to make and meet commitments. When there is a

sense of enough

Post by J. B. Rainsberger

Post by Kent Beck
time, it is safe to commit. When you can do what you

commit to do, there

Post by J. B. Rainsberger
is

Post by Kent Beck
an increase in confidence and ability to produce and a

deepening trust

Post by J. B. Rainsberger

Post by Kent Beck
relationship which frees you to do more with less stress.

So Slack is a way to make it safer to commit to work. I understand.
--
J. B. (Joe) Rainsberger
Diaspar Software Services
http://www.diasparsoftware.com
Author, JUnit Recipes: Practical Methods for Programmer Testing
Yahoo! Groups Sponsor
ADVERTISEMENT
________________________________
Yahoo! Groups Links
http://groups.yahoo.com/group/xpbookdiscussiongroup/
Your use of Yahoo! Groups is subject to the Yahoo! Terms of

Service.
--
Nigel Thorne
Extreme Programmer & Coach
www.nigelthorne.com
Yahoo! Groups Links

Yahoo! Groups Sponsor
ADVERTISEMENT
________________________________
Yahoo! Groups Links
http://groups.yahoo.com/group/xpbookdiscussiongroup/
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

[William Wake]

Post by Kent Beck
Predictability leads to higher throughput.

You lost me here. I'd have said, "if you're willing to give up
certainty on an iteration-by-iteration basis, you'll have higher
throughput over time."

Think of a bell curve that represents the team's velocity. Team 1 is
willing to estimate on the peak, a 50/50 chance of making it or not.
Team 2 wants more security, and estimates something to the left of the
peak.

If there's no psychology involved, team 1 is predicting "velocity 10"
and delivering "velocity 10" on average. Team 2 is predicting
"velocity 8" and delivering "velocity 10" on average.

If you care about predicting the overall velocity, Team 1 is better at
predicting. If you care about "no surprises" every iteration, Team 2
is better. So which kind of predictability do you mean?

Throw in psychology, and I think Team 2 will tend to deliver less
overall (Parkinson's law etc.)

[Kent Beck]

At the team scale, there may be some short-term increase in productivity as
a consequence of promising more. It smacks of magical thinking, though, that
all you have to do to deliver more is to say you're going to deliver more. I
know I am not alone in having experienced the limits of this strategy. After
a certain level of over-commitment, everyone slows down because they know
they aren't going to make it.

Where predictability shines is when you look at the whole value stream,
including marketing, managers, customers, operations, sales, QA, and
programming. Free and open communications based on solid commitments and
frequent updates leads to a higher flow of value. Sales people make
confident commitments and make more sales. Marketing people free their
creativity to look at markets and products innovatively. Management quits
trying to ferret out the truth and starts leading. QA improves communication
instead of simply providing adult supervision. Programmers work with higher
quality. Most important, customers sense that they are working with an
organization with integrity, an organization that has their best interest in
mind.

That's why I'd rather work with a team that could deliver on modest plans
95% of the time instead of "stretch" [unrealistic] plans 50% of the time.

Kent Beck
Three Rivers Institute

-----Original Message-----
Sent: Sunday, March 27, 2005 6:18 AM
Subject: Re: [xpe2e] Expected value of slack
On Fri, 25 Mar 2005 09:10:23 -0800, Kent Beck

Post by Kent Beck
Predictability leads to higher throughput.

You lost me here. I'd have said, "if you're willing to give up
certainty on an iteration-by-iteration basis, you'll have higher
throughput over time."
Think of a bell curve that represents the team's velocity. Team 1 is
willing to estimate on the peak, a 50/50 chance of making it or not.
Team 2 wants more security, and estimates something to the left of the
peak.
If there's no psychology involved, team 1 is predicting "velocity 10"
and delivering "velocity 10" on average. Team 2 is predicting
"velocity 8" and delivering "velocity 10" on average.
If you care about predicting the overall velocity, Team 1 is better at
predicting. If you care about "no surprises" every iteration, Team 2
is better. So which kind of predictability do you mean?
Throw in psychology, and I think Team 2 will tend to deliver less
overall (Parkinson's law etc.)
--
Yahoo! Groups Links

[William Wake]

Post by Kent Beck
At the team scale, there may be some short-term increase in productivity as
a consequence of promising more. It smacks of magical thinking, though, that
all you have to do to deliver more is to say you're going to deliver more. I
know I am not alone in having experienced the limits of this strategy. After
a certain level of over-commitment, everyone slows down because they know
they aren't going to make it.

My point is not that you promise more than you can sustainably
deliver. (My example had one team estimating 10, delivering 10; the
other committing to 8, delivering 10. Both teams had the same
velocity.) Perhaps we're just back to the point of "estimate vs.
commitment".

Consider 3 teams. The first commits at the release level: they build
their promises around delivering the planned stories in the planned
time, and do it 95% of the time. The second commits at the iteration
level: they deliver their stories 95% of the time. The third commits
at the task level: they ensure that they'll meet 95% of their task
"estimates."

I guess this puts us back to Goldratt-type stuff - the third team has
lots of safety buffers. My guess is that their safety buffers will add
up to more than that of the first team.

Post by Kent Beck
Where predictability shines is when you look at the whole value stream,

[...]

Post by Kent Beck
That's why I'd rather work with a team that could deliver on modest plans
95% of the time instead of "stretch" [unrealistic] plans 50% of the time.

Am I hearing you say, "Build in slack at the iteration level; make
commitments (not just estimates) about what you can deliver there.
This lets the organization make solid plans based on what you've
promised."?

[Kent Beck]

Bill,

I think I see a little better the intellectual issues around slack. I'll
summarize my understanding of how Critical Chain Project Management uses
buffers and then try to relate that back to software development.

One way to improve the predictability of a project is to attach buffers to
each task. This results in a long project and doesn't really protect you
from overruns, because if one tasks eats its buffer and more, downstream
tasks will have to slip.

One of the key insights of CCPM is that it is more efficient to have a
single buffer for the whole project rather than buffers for individual
tasks. If you start eating deep into the project buffer, then you should get
concerned about the completion date. Otherwise just keep executing the tasks
even if some of them are over and some under. Any one task that blows up
can't affect the end date. The result is a much shorter schedule that is
(seemingly paradoxically) much more likely to be met.

Including slack in each iteration seems to contradict this insight. Part of
the reason I still encourage iteration slack is there is so much change in
the plan while executing it. What does a project buffer mean if half the
tasks in the original plan have been replaced and the estimates of most of
the remaining tasks have been changed by the time you reach the end of the
plan? A project buffer doesn't seem to me to help much with improving
predictability in the face of massive churn. The goals of building
confidence and trust and working sustainably are supported by iteration
slack. On balance, I think iteration slack is appropriate in most
situations.

Within an iteration I think the CCPM idea of a shared buffer comes into
play. You don't care whether some tasks are over as long as you don't eat to
far into the iteration buffer. There is no need to buffer individual tasks.
I think that is the way most XPers work already. The difference between CCPM
buffers and XP-style slack is that CCPM doesn't schedule anything in the
buffer time. The cards are blank. I don't know what happens to unused buffer
at the end of the project.

All of which is my long way of say, "I agree with your restatement. Include
iteration slack so people can count on you."

Kent Beck
Three Rivers Institute

-----Original Message-----
Sent: Thursday, March 31, 2005 4:24 AM
Subject: Re: [xpe2e] Expected value of slack
On Wed, 30 Mar 2005 23:56:02 -0800, Kent Beck

Post by Kent Beck
At the team scale, there may be some short-term increase in

productivity as

Post by Kent Beck
a consequence of promising more. It smacks of magical

thinking, though, that

Post by Kent Beck
all you have to do to deliver more is to say you're going

to deliver more. I

Post by Kent Beck
know I am not alone in having experienced the limits of

this strategy. After

Post by Kent Beck
a certain level of over-commitment, everyone slows down

because they know

Post by Kent Beck
they aren't going to make it.

My point is not that you promise more than you can sustainably
deliver. (My example had one team estimating 10, delivering 10; the
other committing to 8, delivering 10. Both teams had the same
velocity.) Perhaps we're just back to the point of "estimate vs.
commitment".
Consider 3 teams. The first commits at the release level: they build
their promises around delivering the planned stories in the planned
time, and do it 95% of the time. The second commits at the iteration
level: they deliver their stories 95% of the time. The third commits
at the task level: they ensure that they'll meet 95% of their task
"estimates."
I guess this puts us back to Goldratt-type stuff - the third team has
lots of safety buffers. My guess is that their safety buffers will add
up to more than that of the first team.

Post by Kent Beck
Where predictability shines is when you look at the whole

value stream,
[...]

Post by Kent Beck
That's why I'd rather work with a team that could deliver

on modest plans

Post by Kent Beck
95% of the time instead of "stretch" [unrealistic] plans

50% of the time.
Am I hearing you say, "Build in slack at the iteration level; make
commitments (not just estimates) about what you can deliver there.
This lets the organization make solid plans based on what you've
promised."?

[Rex Madden]

I'm starting to come around to the idea of slack. I think of it as
allowing the iteration to converge upon a solution. Some stories
finish a little early. Some are finished, but need some
design/template work. I could have the developers that are finished
start working on a story for the next iteration, but they may be
called back to work on the stories they thought were done (maybe a
manual test caught something). Having a little slack would allow us
to put on the finishing touches, make sure everything is tested and
working, etc. So those developers can then work on "lower priority"
stuff - this iteration I'm eyeing our ant build. It takes about 7
minutes, but for no good reason. Reducing build time is not critical,
but it sure would make the team happier.

Thanks, Kent.

Post by Kent Beck
Bill,
I think I see a little better the intellectual issues around slack. I'll
summarize my understanding of how Critical Chain Project Management uses
buffers and then try to relate that back to software development.
One way to improve the predictability of a project is to attach buffers to
each task. This results in a long project and doesn't really protect you
from overruns, because if one tasks eats its buffer and more, downstream
tasks will have to slip.
One of the key insights of CCPM is that it is more efficient to have a
single buffer for the whole project rather than buffers for individual
tasks. If you start eating deep into the project buffer, then you should get
concerned about the completion date. Otherwise just keep executing the tasks
even if some of them are over and some under. Any one task that blows up
can't affect the end date. The result is a much shorter schedule that is
(seemingly paradoxically) much more likely to be met.
Including slack in each iteration seems to contradict this insight. Part of
the reason I still encourage iteration slack is there is so much change in
the plan while executing it. What does a project buffer mean if half the
tasks in the original plan have been replaced and the estimates of most of
the remaining tasks have been changed by the time you reach the end of the
plan? A project buffer doesn't seem to me to help much with improving
predictability in the face of massive churn. The goals of building
confidence and trust and working sustainably are supported by iteration
slack. On balance, I think iteration slack is appropriate in most
situations.
Within an iteration I think the CCPM idea of a shared buffer comes into
play. You don't care whether some tasks are over as long as you don't eat to
far into the iteration buffer. There is no need to buffer individual tasks.
I think that is the way most XPers work already. The difference between CCPM
buffers and XP-style slack is that CCPM doesn't schedule anything in the
buffer time. The cards are blank. I don't know what happens to unused buffer
at the end of the project.
All of which is my long way of say, "I agree with your restatement. Include
iteration slack so people can count on you."
Kent Beck
Three Rivers Institute

-----Original Message-----
Sent: Thursday, March 31, 2005 4:24 AM
Subject: Re: [xpe2e] Expected value of slack
On Wed, 30 Mar 2005 23:56:02 -0800, Kent Beck

Post by Kent Beck
At the team scale, there may be some short-term increase in

productivity as

Post by Kent Beck
a consequence of promising more. It smacks of magical

thinking, though, that

Post by Kent Beck
all you have to do to deliver more is to say you're going

to deliver more. I

Post by Kent Beck
know I am not alone in having experienced the limits of

this strategy. After

Post by Kent Beck
a certain level of over-commitment, everyone slows down

because they know

Post by Kent Beck
they aren't going to make it.

My point is not that you promise more than you can sustainably
deliver. (My example had one team estimating 10, delivering 10; the
other committing to 8, delivering 10. Both teams had the same
velocity.) Perhaps we're just back to the point of "estimate vs.
commitment".
Consider 3 teams. The first commits at the release level: they build
their promises around delivering the planned stories in the planned
time, and do it 95% of the time. The second commits at the iteration
level: they deliver their stories 95% of the time. The third commits
at the task level: they ensure that they'll meet 95% of their task
"estimates."
I guess this puts us back to Goldratt-type stuff - the third team has
lots of safety buffers. My guess is that their safety buffers will add
up to more than that of the first team.

Post by Kent Beck
Where predictability shines is when you look at the whole

value stream,
[...]

Post by Kent Beck
That's why I'd rather work with a team that could deliver

on modest plans

Post by Kent Beck
95% of the time instead of "stretch" [unrealistic] plans

50% of the time.
Am I hearing you say, "Build in slack at the iteration level; make
commitments (not just estimates) about what you can deliver there.
This lets the organization make solid plans based on what you've
promised."?

________________________________
Yahoo! Groups Links
http://groups.yahoo.com/group/xpbookdiscussiongroup/
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

[William Wake]

Post by Kent Beck
One of the key insights of CCPM is that it is more efficient to have a
single buffer for the whole project rather than buffers for individual
tasks.
Including slack in each iteration seems to contradict this insight.

Perhaps not contradict, but certainly put a claim in about the level
at which you want predictability.

The CCPM reasoning applies at the next level up - if you're willing to
tolerate more unpredicatability at the iteration level, you can
increase throughput at the project level.

And it applies another level up too - if you're willing to tolerate
more uncertainty at the project level, you can increase throughput at
the project portfolio level. I had a CIO type friend who raved about
small releases - run ten projects for two or three months each, then
pick the winners and really put force behind them.

Post by Kent Beck
On balance, I think iteration slack is appropriate in most situations.
All of which is my long way of say, "I agree with your restatement. Include
iteration slack so people can count on you."

Gotcha.

[Restatement was...]

Post by Kent Beck

Post by William Wake
Am I hearing you say, "Build in slack at the iteration level; make
commitments (not just estimates) about what you can deliver there.
This lets the organization make solid plans based on what you've
promised."?

[J. B. Rainsberger]

Post by William Wake

Post by Kent Beck
At the team scale, there may be some short-term increase in productivity as
a consequence of promising more. It smacks of magical thinking, though, that
all you have to do to deliver more is to say you're going to deliver more. I
know I am not alone in having experienced the limits of this strategy. After
a certain level of over-commitment, everyone slows down because they know
they aren't going to make it.

My point is not that you promise more than you can sustainably
deliver. (My example had one team estimating 10, delivering 10; the
other committing to 8, delivering 10. Both teams had the same
velocity.) Perhaps we're just back to the point of "estimate vs.
commitment".

Indeed we are. We used to say, "It's just an estimate; stop asking for a
commitment." I gather from Kent's words that his customers are happier
with smaller commitments than with larger estimates. Granted, my
customers have been happy with my estimates for the most part -- even
when I miss -- but I wonder how much /better/ it would be if I could
commit confidently and regularly. Those customers might love me instead
of just kinda like me.

Post by William Wake
Am I hearing you say, "Build in slack at the iteration level; make
commitments (not just estimates) about what you can deliver there.
This lets the organization make solid plans based on what you've
promised."?

I know that's what /I/'m hearing.

[Donald Roby]

Post by Kent Beck
Within an iteration I think the CCPM idea of a shared buffer comes into
play. You don't care whether some tasks are over as long as you

don't eat to

Post by Kent Beck
far into the iteration buffer. There is no need to buffer individual

tasks.

Post by Kent Beck
I think that is the way most XPers work already. The difference

between CCPM

Post by Kent Beck
buffers and XP-style slack is that CCPM doesn't schedule anything in the
buffer time. The cards are blank. I don't know what happens to

unused buffer

Post by Kent Beck
at the end of the project.

What happens is quite simple. The project ends early, and everyone
cheers.

A buffer is a mechanism for allowing the possibility of early
delivery. Projects without buffers can only deliver on-time or late.

The unused buffer can be used by starting the next project earlier
than previously planned.

[J. B. Rainsberger]

Post by Kent Beck
Where predictability shines is when you look at the whole value stream,
including marketing, managers, customers, operations, sales, QA, and
programming. Free and open communications based on solid commitments and
frequent updates leads to a higher flow of value.

I really think this is the key point, folks. Call me a "critical chain"
zealot, if you want, but the predictability of the pace of development
has unknown (and perhaps surprisingly high, to some) value in itself.
This means that delivering 18, 18, 18, 19, 18, 18, ... is more valuable
than delivering 22, 17, 21, 22, 16, 22, ... even though the latter
delivers more stuff.

Thought experiment: you are a salesman working with a team that delivers
according to the more varied schedule above. You are trying to close a
sale with someone who wants a key feature you just got into the plan.
It's currently the 19th and 20th points in the iteration. If you make
the sale, you're done for the month in commissions (it's April 2,
remember). If you don't, you might lose your job. How do you feel?

Now, suppose it's the 16th and 17th point of the iteration for a team
that delivers according the less varied schedule above. Everything else
is the same. /Now/ how do you feel?

I apologize for the Blatantly Leading Questions.

[William Wake]

Post by J. B. Rainsberger
I really think this is the key point, folks. Call me a "critical chain"
zealot, if you want, but the predictability of the pace of development
has unknown (and perhaps surprisingly high, to some) value in itself.
This means that delivering 18, 18, 18, 19, 18, 18, ... is more valuable
than delivering 22, 17, 21, 22, 16, 22, ... even though the latter
delivers more stuff.

At some level, it's "bonds or stocks?" Someone with higher risk
tolerance can accept the latter averaging more overall value, but also
running the "risk" of mega-success or total loss.

[J. B. Rainsberger]

Post by William Wake

Post by J. B. Rainsberger
I really think this is the key point, folks. Call me a "critical chain"
zealot, if you want, but the predictability of the pace of development
has unknown (and perhaps surprisingly high, to some) value in itself.
This means that delivering 18, 18, 18, 19, 18, 18, ... is more valuable
than delivering 22, 17, 21, 22, 16, 22, ... even though the latter
delivers more stuff.

At some level, it's "bonds or stocks?" Someone with higher risk
tolerance can accept the latter averaging more overall value, but also
running the "risk" of mega-success or total loss.

A great metaphor. The closer to release, the more we want to convert
high-risk equities into low-risk ones. Early on, when the release is
young, it can handle more risk; but later, when it gets close to
"retirement" (ironic, since we actually deliver it so it can start
really working), it can handle less risk.

Thanks.

[a***@public.gmane.org]

sorry, I forgot to put the tongue-in-cheek marker on my posting ;-)
just that this thread was starting to look startlingly CMM /
predictability-based
Alistair

In a message dated 4/3/2005 12:13:25 P.M. Mountain Daylight Time,
xpbookdiscussiongroup-***@public.gmane.org writes:

From: Steven Gordon <sagordon-***@public.gmane.org>
Subject: RE: Digest Number 110

Maybe when we diagnose and resolve root cause issues we would tend to
transform 22, 17, 21, 22, 16, 22 into 23, 19, 24, 25, 18, 23 rather than a sequence
of 18s. Maybe the variability is not due to our process, but rather the
unpredictable nature of creativity and the complexity of the problem space.
Ideal solutions sometimes appear seridipitously and other times require working
through a series of less than ideal solutions. The intensions of the
customer are sometimes clearly understood and other times requires a series of
conversations to work out.

Attempting to achieve even productivity in the face of a complex and
changing problem space seems like the kind of overengineering that could make a
process more brittle. Software development is not a repeatable process like
manufacturing the same item over and over again. Each iteration is a bit
different.

Increasing the minimum productivity is a much more straight forward goal for
self-reflective activities. We still cannot lead the customer into believe
that we will deliver more than our observed minimum, but is there a real
problem when we beat our observed minimum too often?

-----Original Message-----
From: acockburn-***@public.gmane.org [mailto:acockburn-***@public.gmane.org]
Sent: Sat 4/2/2005 11:07 PM
To: xpbookdiscussiongroup-***@public.gmane.org
Cc:
Subject: Re: [xpe2e] Digest Number 110



Hmm, you mean you would like to reduce process variation over time? by e.g.
getting the process parameters into the right tolerances? by investigating
root causes of outcome variation and uniform-izing them at their source?
... that sounds like a good idea --- maybe I've heard that idea somewhere
else before?

In a message dated 4/2/2005 12:53:26 P.M. Mountain Standard Time,
xpbookdiscussiongroup-***@public.gmane.org writes:

Subject: Re: Expected value of slack

Where predictability shines is when you look at the whole value stream,
including marketing, managers, customers, operations, sales, QA, and
programming. Free and open communications based on solid commitments and
frequent updates leads to a higher flow of value.

I really think this is the key point, folks. Call me a "critical chain"
zealot, if you want, but the predictability of the pace of development
has unknown (and perhaps surprisingly high, to some) value in itself.
This means that delivering 18, 18, 18, 19, 18, 18, ... is more valuable
than delivering 22, 17, 21, 22, 16, 22, ... even though the latter
delivers more stuff.

Thought experiment: you are a salesman working with a team that delivers
according to the more varied schedule above. You are trying to close a
sale with someone who wants a key feature you just got into the plan.
It's currently the 19th and 20th points in the iteration. If you make
the sale, you're done for the month in commissions (it's April 2,
remember). If you don't, you might lose your job. How do you feel?

Now, suppose it's the 16th and 17th point of the iteration for a team
that delivers according the less varied schedule above. Everything else
is the same. /Now/ how do you feel?

I apologize for the Blatantly Leading Questions.
--
J. B. (Joe) Rainsberger






==============================================
Alistair Cockburn
President, Humans and Technology

801.582.3162
1814 Ft Douglas Cir,
Salt Lake City, UT 84103
_http://alistair.cockburn.us/_ (http://alistair.cockburn.us/)
acockburn-***@public.gmane.org
(fax: [phone])
===============================

"Surviving Object-Oriented Projects" (1998)
"Writing Effective Use Cases" (Jolt Productivity Award 2001)
"Agile Software Development" (Jolt Productivity Award 2002)
"Crystal Clear: A Human-Powered Methodology for Small Teams" (Jolt Award
Finalist 2004)

"La perfection est atteinte non quand il ne reste rien a ajouter,
mais quand il ne reste rien a enlever." (Saint-Exupery)

"The first thing to build is trust." (Brad Appleton)
==============================================