Practice: Slack

[Kent Beck]

In any plan, include some minor tasks that can be dropped if you get behind.
You can always add more stories later and deliver more than you promised. It
is important in an atmosphere of distrust and broken promises to meet your
commitments. A few met commitments go a long way toward rebuilding
relationships.
In Iceland, one of the winter sports is taking monstrous trucks bouncing
around the backcountry. These trucks all have four-wheel-drive; but when
they are out crashing around, they only use two-wheel-drive. If they get
stuck in two-wheel-drive they have four-wheel-drive to get them out. If they
get stuck in four-wheel-drive they're just stuck.
I remember two conversations: one with a middle manager who had one
hundred people reporting to him and another with his executive manager who
had three hundred people in his organization. I suggested to the middle
manager that he encourage his teams to only sign up for what they were
confident they could actually do. They had a long history of overcommitting
and underdelivering. "Oh, I couldn't do that. If I don't agree to aggressive
[i.e. unrealistic] schedules, I'll be fired." The next day, I talked to the
executive. "Oh, they never come in on time. It's okay. They still deliver
enough of what we need."
I had been watching first-hand the incredible waste generated by their
habitual overcommitment: unmanageable defect loads, dismal morale, and
antagonistic relationships. Meeting commitments, even modest ones,
eliminates waste. Clear, honest communication relieves tension and improves
credibility.
You can structure slack in many ways. One week in eight could be "Geek
Week". Twenty percent of the weekly budget could go to programmer-chosen
tasks. You may have to begin slack with yourself, telling yourself how long
you actually think a task will take and giving yourself time to do it, even
if the rest of the organization is not ready for honest and clear
communication.



------------------------ Yahoo! Groups Sponsor --------------------~-->
$4.98 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/Q7_YsB/neXJAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~->

[Keith Ray]

How do you prevent "minor tasks that can be dropped if you get behind"
from being interpreted as broken promises/comittements?

Post by Kent Beck
In any plan, include some minor tasks that can be dropped if you get behind.
You can always add more stories later and deliver more than you promised. It
is important in an atmosphere of distrust and broken promises to meet your
commitments. A few met commitments go a long way toward rebuilding
relationships.

----
C. Keith Ray
<http://homepage.mac.com/keithray/blog/index.html>
<http://homepage.mac.com/keithray/xpminifaq.html>
<http://homepage.mac.com/keithray/resume2.html>


------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~->

[Dale Emery]

Hi Keith,

Post by Keith Ray
How do you prevent "minor tasks that can be dropped if you get
behind" from being interpreted as broken
promises/comittements?

One possibility is not to promise them or commit to them. That
isn't a foolproof way to prevent people interpreting the change
in scope as a broken commitment, but you can sometimes negotiate
expectations up front. "We promise to deliver these three
things. And if we have time, we'll do those other two things,
but we can't promise that until we see how these first three
things go."

Dale
--
Dale Emery, Consultant
Inspiring Leadership for Software People
Web: http://www.dhemery.com
Weblog: http://www.dhemery.com/cwd

Positive, adj. Mistaken at the top of one's voice. --Ambrose Bierce


------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~->

[Ron Jeffries]

Post by Dale Emery

Post by Keith Ray
How do you prevent "minor tasks that can be dropped if you get
behind" from being interpreted as broken
promises/comittements?

One possibility is not to promise them or commit to them. That
isn't a foolproof way to prevent people interpreting the change
in scope as a broken commitment, but you can sometimes negotiate
expectations up front. "We promise to deliver these three
things. And if we have time, we'll do those other two things,
but we can't promise that until we see how these first three
things go."

The Scrum process takes an interesting angle. The team /commits/ to
accomplishing the "Sprint Goal". This does not mean a specific set
of "stories", though that would be the ideal solution. But the
commitment is to accomplishing all the functionality that the
stories call for ... somehow.

This is somewhat stronger, it seems to me, than some people's
interpretation of the XP Planning Game. I've seen teams deliver
absolutely nothing in an iteration, and then want to have that be
OK: "Well, I guess our velocity was zero." I think this relates back
to Kent's comments on accountability: it's really not OK to commit
to something and deliver nothing.

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




------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~->

[Russell Gold]

On Tue, 28 Dec 2004 20:44:03 -0500, Ron Jeffries

Post by Ron Jeffries
This is somewhat stronger, it seems to me, than some people's
interpretation of the XP Planning Game. I've seen teams deliver
absolutely nothing in an iteration, and then want to have that be
OK: "Well, I guess our velocity was zero." I think this relates back
to Kent's comments on accountability: it's really not OK to commit
to something and deliver nothing.

No, it's really not OK - but what if it happens? Presumably with a
too-short iteration, it is possible that all of the tasks really did
need more time than was available. So, scolding and recriminations
aside, what DO you do in that case? Surely you cannot use "yesterday's
weather" to predict that you will not accomplish anything in the next
iteration, can you?


------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~->

[William Wake]

Post by Russell Gold
On Tue, 28 Dec 2004 20:44:03 -0500, Ron Jeffries

[...] I think this relates back
to Kent's comments on accountability: it's really not OK to commit
to something and deliver nothing.

No, it's really not OK - but what if it happens? Presumably with a
too-short iteration, it is possible that all of the tasks really did
need more time than was available. So, scolding and recriminations
aside, what DO you do in that case?

It's rare, but it does happen. We'd look at why, and consider how to
make stories and tasks smaller. We seem to be more prone to forgetting
tasks than just estimating wildly wrong on the tasks that we thought
of, so we may make it a point to discuss stories more.

But the subtext to the customer is, "We predicted this and it didn't
happen - so our predictions are suspect. We know we didn't complete
anything, but please let us tackle one story for this coming week."

(And that's not so different from the case where we finish an
iteration's stories, and go back for another one. The trick is that
we've moved into "one story at a time".)

Post by Russell Gold
Surely you cannot use "yesterday's
weather" to predict that you will not accomplish anything in the next
iteration, can you?

Well... it works quite nicely. What's to say our estimates aren't off
by a factor of 3 or 4 or 10 - why should it have been two? (If you
want to assume we'll finish those leftovers in the upcoming
iteration.)

I haven't had a team finish no stories two iterations in a row. But if
I did, that'd be powerful information for the customer to be aware of,
and powerful feedback for the team.

[Ron Jeffries]

Post by Russell Gold
On Tue, 28 Dec 2004 20:44:03 -0500, Ron Jeffries

Post by Ron Jeffries
This is somewhat stronger, it seems to me, than some people's
interpretation of the XP Planning Game. I've seen teams deliver
absolutely nothing in an iteration, and then want to have that be
OK: "Well, I guess our velocity was zero." I think this relates back
to Kent's comments on accountability: it's really not OK to commit
to something and deliver nothing.

No, it's really not OK - but what if it happens? Presumably with a
too-short iteration, it is possible that all of the tasks really did
need more time than was available. So, scolding and recriminations
aside,

Was someone recommending scolding and recriminations? I hope not.

Post by Russell Gold
what DO you do in that case? Surely you cannot use "yesterday's
weather" to predict that you will not accomplish anything in the next
iteration, can you?

Why couldn't we predict that? What more likely prediction would seem
preferable? What would happen if we did predict that? How soon would
we be so far ahead of schedule that we'd ask for more work to do?

However, my point is that wise teams focus on meeting the sense of
the stories, even if the specific stories cannot all be
accomplished.

Ron Jeffries
www.XProgramming.com
I was smarter before I donated my brain to science.
I didn't know they meant NOW.




------------------------ Yahoo! Groups Sponsor --------------------~-->
$4.98 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/Q7_YsB/neXJAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~->

[Steve Hayes]

Post by Ron Jeffries

Post by Dale Emery

Post by Keith Ray
How do you prevent "minor tasks that can be dropped if you get
behind" from being interpreted as broken
promises/comittements?

One possibility is not to promise them or commit to them. That
isn't a foolproof way to prevent people interpreting the change
in scope as a broken commitment, but you can sometimes negotiate
expectations up front. "We promise to deliver these three
things. And if we have time, we'll do those other two things,
but we can't promise that until we see how these first three
things go."

The Scrum process takes an interesting angle. The team /commits/ to
accomplishing the "Sprint Goal". This does not mean a specific set
of "stories", though that would be the ideal solution. But the
commitment is to accomplishing all the functionality that the
stories call for ... somehow.
This is somewhat stronger, it seems to me, than some people's
interpretation of the XP Planning Game. I've seen teams deliver
absolutely nothing in an iteration, and then want to have that be
OK: "Well, I guess our velocity was zero." I think this relates back
to Kent's comments on accountability: it's really not OK to commit
to something and deliver nothing.

I've seen the same "our velocity was zero" kind of behaviour. I now
prefer to use the term "commitment level" instead of "velocity" in the
iteration planning game. I still tend to use "velocity" when doing
higher levels of planning and projection.

Steve Hayes

[Kent Beck]

Keith,

If we are working together as a team with our customers, we are on the same
side of the equation. I am not breaking promises to them if we are deciding
together how to proceed in changing circumstances.

The reality of software development is that sometimes stories take as long
as estimated or shorter and sometimes they take longer. If the people on
whose behalf the software is deployed are part of the team and we make the
decision together about how to create the most value when work takes longer
than expected, then we have agreement about the process and the satisfaction
of having done our best, all of us together. It's the fact of the whole team
deciding together that makes this process part of XP, and not a step away as
Tim King feared. Satisfaction at full effort is the best outcome I can
imagine that's fully under my control.
What do you think?

Kent Beck
Three Rivers Institute

-----Original Message-----
From: Keith Ray [mailto:keith.ray-***@public.gmane.org]
Sent: Tuesday, December 28, 2004 9:39 AM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: Re: [xpe2e] Practice: Slack


How do you prevent "minor tasks that can be dropped if you get behind"
from being interpreted as broken promises/comittements?

[Tim King]

Post by Kent Beck
In any plan, include some minor tasks that can be dropped if you get behind.
You can always add more stories later and deliver more than you promised. It
is important in an atmosphere of distrust and broken promises to meet your
commitments.
...
I suggested to the middle
manager that he encourage his teams to only sign up for what they were
confident they could actually do.

I agree slack is a must. All good decision-making happens in the
wiggle-room that is slack.

There is a flip-side, however. Firstly, remember Parkinson's Law.
Padding one's schedule may encourage one not to be energized about the
work. I find it best for energized work to estimate not optimistically,
not pessimistically, but just to estimate it. This means a fairly high
likelihood that any given story will take longer to implement. And
high-risk stories, perhaps much longer. Therefore, to combat distrust,
I've seen some put off the riskiest features till last, because they
weren't confident they could deliver a working solution in time.

I'm not sure all the tactics that can be used to cope with a hostile
environment. I'm not even sure if you can truly do XP in the midst of
distrust. One thing I tried, successfully, was to keep many estimates
private to the developers. The customer saw one set of committments; we
were shooting at a different set. When we adjusted what was going to be
delivered in a given release, the customer was happy because the main
things he needed were there.

This is very similar to what you, Kent, suggest above, including tasks
that can be dropped, sometimes delivering more than what was promised.
But I feel like the customer then isn't a first-class member of the
team, and therefore this is a step away from XP. Comments?

-TimK


------------------------ Yahoo! Groups Sponsor --------------------~-->
$4.98 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/Q7_YsB/neXJAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~->

[J. B. Rainsberger]

Post by Tim King

Post by Kent Beck
In any plan, include some minor tasks that can be dropped if you get behind.
You can always add more stories later and deliver more than you promised. It
is important in an atmosphere of distrust and broken promises to meet your
commitments.
...
I suggested to the middle
manager that he encourage his teams to only sign up for what they were
confident they could actually do.

I agree slack is a must. All good decision-making happens in the
wiggle-room that is slack.
There is a flip-side, however. Firstly, remember Parkinson's Law.
Padding one's schedule may encourage one not to be energized about the
work. I find it best for energized work to estimate not optimistically,
not pessimistically, but just to estimate it. This means a fairly high
likelihood that any given story will take longer to implement. And
high-risk stories, perhaps much longer. Therefore, to combat distrust,
I've seen some put off the riskiest features till last, because they
weren't confident they could deliver a working solution in time.

I felt the same way, and reacted strongly, when Kent first described
this practice to me. I have come to interpret it differently now.

Slack enables us to complete those important, but not urgent, tasks.
Because they are not urgent, it is all right not to complete them; but
because they are important, we do not want to put them off indefinitely,
until they become both urgent and important.

In other words, we're not "padding" and we're not undercommitting. We're
simply providing some room in the budget for maintaining or increasing
production capacity from iteration to iteration.

[Ron Jeffries]

Post by J. B. Rainsberger
I felt the same way, and reacted strongly, when Kent first described
this practice to me. I have come to interpret it differently now.
Slack enables us to complete those important, but not urgent, tasks.
Because they are not urgent, it is all right not to complete them; but
because they are important, we do not want to put them off indefinitely,
until they become both urgent and important.
In other words, we're not "padding" and we're not undercommitting. We're
simply providing some room in the budget for maintaining or increasing
production capacity from iteration to iteration.

Would it be fair to say, therefore, that if we understood the "true"
business value of those stories, we would schedule them right
alongside regular stories ... and that we might favor the regular
ones a bit if we went slower than anticipated, in order not to upset
the customer?

I keep feeling that there's a good idea here that is tangled up with
lack of information, lack of understanding of the value of some
stories, and some fear of disappointing the customer.

I know nothing is ever as sharply delineated as we'd like it, but I
have the sense that this one can be made more crisp than it is right
now.

Ron Jeffries
www.XProgramming.com
If you're not throwing some gravel once in a while,
you're not using the whole road.

[J. B. Rainsberger]

Post by Ron Jeffries
Would it be fair to say, therefore, that if we understood the "true"
business value of those stories, we would schedule them right
alongside regular stories ... and that we might favor the regular
ones a bit if we went slower than anticipated, in order not to upset
the customer?

False implies anything.

There is no true business value of those stories. What we typically
identify as "business value of a story" is really only the business
value as perceived by the customer of this project, which might
be a (misguided) local optimization within the company.

Suppose we only work on what's important to the customer of this product
right now. Suppose we work at 100% capability for two years. Suppose at
the end of that time, 80% of the team quits because they are burnt out.

Were we really working on the stories with the most business value? The
only answer I can think of that really fits is "yes and no." Therein
lies a problem.

[J. B. Rainsberger]

Post by Kent Beck
In any plan, include some minor tasks that can be dropped if you get behind.
You can always add more stories later and deliver more than you promised. It
is important in an atmosphere of distrust and broken promises to meet your
commitments. A few met commitments go a long way toward rebuilding
relationships.

I find this interesting, given the experience I have just gone through
this past week.

I'm currently flying to San Jose to give a tutorial at SD West Expo. I
had to prepare this tutorial, and so I left the entire week open to do
just that. I had all the ideas and the presentation slides done, but I
needed a codebase to go with it. I decided I would test-drive one simple
and one technologically interesting feature, then deliver a downloadable
codebase for the participants in the form of an Eclipse project.

The simple feature turned out not to be so simple; I had a great deal to
learn about how to use parts of Spring with which I was familiar but not
intimate. I also went down a pretty annoying rathole as late as Saturday
before I finally gave in and got things done.

So what does this have to do with slack? Simple: I added a few slack
stories, but not nearly enough.

SLACK STORIES I HAD:
* create one-step build for the Eclipse project
* put Eclipse and JBoss on CD for the various platforms

Not bad, but I could have done much better.

STORIES I WISH I'D MAKE SLACK FROM THE BEGINNING:
* do everything the way SimpleFormController wants to do it
* use a message-driven bean to handle asynchronous requests
* enable internationalization

These three things cost me approximately 12-16 hours in a 60-hour
schedule, or about 30-40% of the schedule. I should have known better,
but (of course) I didn't have a pair tapping my shoulder, and asking,
"Might there be an easier way to do this?"

No why would these slack stories have helped me so much this week?

Jury duty cost me enough time.

Well, thanks for reading.