Practice: Weekly Cycle

[kent beck]

Plan work a week at a time. Have a meeting at the beginning of every week. During this meeting:
1. Review progress to date, including how actual progress for the previous week matched expected progress.
2. Have the customers pick a week's worth of stories to implement this week.
3. Break the stories into tasks. Team members sign up for tasks and estimate them.

Start the week by writing automated tests that will run when the stories are completed. Then spend the rest of the week completing the stories and getting the tests to pass. A team proud of its work will fully implement the stories, not just do enough work to get the tests to pass. The goal is to have deployable software at the end of the week which everyone can celebrate as progress.

The week is a widely shared time scale. The nice thing about a week as opposed to two or three (as I recommended in the first edition) is that everyone is focused on Friday. The team's job--programmers, testers, and customers together--is to write the tests and then get them to run in five days. If you get to Wednesday and it is clear that all the tests won't be running, that the stories won't be completed and ready to deploy, you still have time to choose the most valuable stories and complete them.

Some people like to start their week on a Tuesday or Wednesday. I was surprised when I first saw it, but it's common enough to mention. As one manager told me, "Monday's are unpleasant and planning is unpleasant, so why put them together?" I don't think planning should be unpleasant; but in the meantime, shifting the start of the cycle makes some sense as long as it doesn't put pressure on people to work over the weekend. Working weekends is not sustainable; if the real problem is that the estimates are overly optimistic, then work on improving your estimates.

Planning is a form of necessary waste. It doesn't create much value all by itself. Work on gradually reducing the percentage of time you spend planning. Some teams start with a whole day of planning for a week, but gradually refine their planning skills until they spend an hour planning for the week.

I like to break stories into tasks that individuals take responsibility for and estimate. I thin ownership of tasks goes a long way towards satisfying the human need for ownership. I've seen other styles work well, though. You can write small stories that eliminate the need for separate tasks. The cost of this approach is more work for the customer. You can also eliminate sign-up by keeping a stack of tasks. When a programmer is ready to start a new task, he takes one from the top of the stack. This eliminates the opportunity for him to choose a task he particularly cares about or is especially good at, but ensures that each programmer gets a variety of tasks. (Pairing gives programmers a change to use specialist skills, whoever holds the task.)

The weekly heartbeat also gives you a convenient, frequent, and predictable platform for team and individual experiments. "OK, for the next week we're going to switch pair partners every hour on the hours," or "I'll juggle for five minutes every morning before I start programming."


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

[Ron Jeffries]

My experience and the resulting preferences vary a bit from what Kent has
written here. I'll interleave some short items for conversation should we

Post by kent beck
1. Review progress to date, including how actual progress for the
previous week matched expected progress.
2. Have the customers pick a week's worth of stories to implement this week.
3. Break the stories into tasks. Team members sign up for tasks and estimate them.

I, too, favor weekly iterations. However, I have recently had teems,
having tried one-week iterations, go to two weeks. I believe this was due
to the fact that they were in a legacy situation and the medium was too
sticky to get much done in a week. If I were doing it, I'd push to get back
to a week, but I'd support the stretching to two weeks given where they
currently found themselves.

Post by kent beck
Start the week by writing automated tests that will run when the stories
are completed. Then spend the rest of the week completing the stories and
getting the tests to pass. A team proud of its work will fully implement
the stories, not just do enough work to get the tests to pass. The goal
is to have deployable software at the end of the week which everyone can
celebrate as progress.

I'm not sure of the feeling behind the "A team proud of its work" sentence.
Is slacking a common concern on XP teams, solved only by pride of work? Is
it a fear likely held by some class of readers? What "fear" is represented
here, I'm wondering.

Post by kent beck
Some people like to start their week on a Tuesday or Wednesday. I was
surprised when I first saw it, but it's common enough to mention. As one
manager told me, "Monday's are unpleasant and planning is unpleasant, so
why put them together?" I don't think planning should be unpleasant; but
in the meantime, shifting the start of the cycle makes some sense as long
as it doesn't put pressure on people to work over the weekend. Working
weekends is not sustainable; if the real problem is that the estimates
are overly optimistic, then work on improving your estimates.

Yes. I've seen weekend work all too often, however, either imposed by
management or by the programmers themselves. I'm not sure what to do about
it: I wish we had some kind of measure or metric or statistic that would
let us better manage this area.

Post by kent beck
I like to break stories into tasks that individuals take responsibility
for and estimate. I think ownership of tasks goes a long way towards
satisfying the human need for ownership. I've seen other styles work
well, though. You can write small stories that eliminate the need for
separate tasks. The cost of this approach is more work for the customer.
You can also eliminate sign-up by keeping a stack of tasks. When a
programmer is ready to start a new task, he takes one from the top of the
stack. This eliminates the opportunity for him to choose a task he
particularly cares about or is especially good at, but ensures that each
programmer gets a variety of tasks. (Pairing gives programmers a chance
to use specialist skills, whoever holds the task.)

I continue to find task focus to be a problem. At least three problems, in
fact:

1. Task focus comes at the expense of story focus. Tasks get done but
somehow the story does not.

2. Task estimates too commonly become proof that we can't really do the
story in a week. The reason is that the task becomes overblown in some
way that isn't needed for current stories, and still falls short in some
way that another task or the whole story needs.

3. The initial task breakdown is a design without feedback. Focusing on
the tasks thereafter commonly misses the more creative solution to the
story.

I strongly favor brainstorming tasks and then spiking through stories with
the tasks in mind but without task focus. Then elaborate the code, again
with tasks in mind, until the story is complete. The tasks brainstormed may
not be complete -- they may not even be necessary.


Submitted for your consideration ...

Ron Jeffries
www.XProgramming.com
Replacing an on-site customer with some use cases is about as effective
as replacing a hug from your Mom with a friendly note.




------------------------ 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
--------------------------------------------------------------------~->

[Steve Freeman]

Post by Ron Jeffries
I, too, favor weekly iterations. However, I have recently had teems,
having tried one-week iterations, go to two weeks. I believe this was due
to the fact that they were in a legacy situation and the medium was too
sticky to get much done in a week. If I were doing it, I'd push to get back
to a week, but I'd support the stretching to two weeks given where they
currently found themselves.

I've had this pattern. We had a legacy codebase and one-week iterations
were just too tight. We compromised on having major/minor weeks: a two
week iteration with some coordination on the off week. Had the project
lasted we would have pushed up the rate.

S.



------------------------ 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
--------------------------------------------------------------------~->

[Michael Feathers]

Post by Ron Jeffries

Post by Ron Jeffries
I, too, favor weekly iterations. However, I have recently had teems,
having tried one-week iterations, go to two weeks. I believe this

was due

Post by Ron Jeffries
to the fact that they were in a legacy situation and the medium was too
sticky to get much done in a week. If I were doing it, I'd push to

get back

Post by Ron Jeffries
to a week, but I'd support the stretching to two weeks given where they
currently found themselves.

I've had this pattern. We had a legacy codebase and one-week iterations
were just too tight. We compromised on having major/minor weeks: a two
week iteration with some coordination on the off week. Had the project
lasted we would have pushed up the rate.

Same. Two week iterations are the norm for my teams.

Michael



------------------------ 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
--------------------------------------------------------------------~->

[Brad Appleton]

Post by Steve Freeman

Post by Ron Jeffries
I, too, favor weekly iterations. However, I have recently had teems,
having tried one-week iterations, go to two weeks. I believe this was due
to the fact that they were in a legacy situation and the medium was too
sticky to get much done in a week. If I were doing it, I'd push to get back
to a week, but I'd support the stretching to two weeks given where they
currently found themselves.

I've had this pattern. We had a legacy codebase and one-week iterations
were just too tight. We compromised on having major/minor weeks: a two
week iteration with some coordination on the off week. Had the project
lasted we would have pushed up the rate.

I also have this pattern in a different context. When one's project and team is but one in a whole set of projects and project teams that have to be coordinated together, and when all the other project teams aren't doing "iterative" (mcu less XP) and/or aren't doing releases that are <= 1month, then trying to get one's own team and project to do weekly iterations was getting too difficult because there was too much friction in coordinating with the other projects/teams that simply couldn't deal with us moving that fast. We needed the extra week not only for additional planning and interfacing but also to give them (and the customers) something much more stable to use/evaluate for at least 2-3 days.

So we took a vote between (#1) going to 2 weeks for our iterations, or (#2) somehow making all the other projects and teams go "agile". We all preferred option #2, but agreed that option #1 was more within our sphere of influence (at least for the current project). Some of us ALSO set out on the longer-term goal of getting the others to go agile :-)
--
Brad Appleton <brad-***@public.gmane.org> www.bradapp.net
Software CM Patterns (www.scmpatterns.com)
Effective Teamwork, Practical Integration
"And miles to go before I sleep." -- Robert Frost


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

[William Wake]

All -
When you have two-week iterations, I'm curious what that means:

- do you have twice as many stories "in process"?
- is your typical story unable to be completed in a single week?
- or is a story the "usual" :) size, but you have "wait time" within it?
- do you tie releases to the iteration length at all?
- ... (the other 20 reasons I'm not clever enough to make up here)

In Brad's case,

Post by Brad Appleton
When one's project and team is but one in a whole set of projects and
project teams that have to be coordinated together, and when all the other
project teams aren't doing "iterative" (mcu less XP) and/or aren't doing
releases that are <= 1month, then trying to get one's own team and project
to do weekly iterations was getting too difficult because there was
too much friction in coordinating with the other projects/teams that simply
couldn't deal with us moving that fast. We needed the extra week not
only for additional planning and interfacing but also to give them (and
the customers) something much more stable to use/evaluate for at least
2-3 days.

Did you feel you couldn't do one-week iterations yourselves, and have
a "drop" ready for the other teams on a slower basis? The "extra week
for planning and interfacing" just sounds funny at some level, like no
more work was done but the pace was better. (Note that I don't mean
2-week iterations were wrong for your situation, I'm just trying to
understand what couples your "internal" cycle to their pace.)


I've used a variety of iteration lengths. I've noticed that teams
almost always want to push for longer rather than shorter, but rarely
for reasons I've particularly liked. (Like some of you, I have on
occasion gone with the team's consensus.) Of course, I have the same
challenge about how much testing to do and lots of other stuff as
well.

One effect I worry about is the "software in process" idea - iteration
length to some degree controls your responsiveness. At some level, a
2-week iteration suggests you either average 3 weeks turnaround from a
fresh new idea, or you use the Scrum idea of "cancel the iteration",
or you set up some expediting.

[Andrew McDonagh]

Post by kent beck
-----Original Message-----
Sent: 25 November 2004 01:28
Subject: Re: [xpe2e] Practice: Weekly Cycle
All -
- do you have twice as many stories "in process"?
- is your typical story unable to be completed in a single week?
- or is a story the "usual" :) size, but you have "wait time" within it?
- do you tie releases to the iteration length at all?
- ... (the other 20 reasons I'm not clever enough to make up here)

In our case, we typically have around 5 stories per iteration, with the
stories estimated at being between 2 and 5 days to complete.

We always produce a labelled release at the end of an iteration (whilst
still having un labelled daily builds).

Coupling this with only having manual acceptance tests, it leaves us with
little time in a weekly iteration.

What we have seen is that when we have 'many smaller' stories per iteration,
rather than the usual 'few larger', we are more likely to finish them within
the iteration. I can almost guarantee that the 5 day estimated stories are
worked upon right up to the last minute before release, and usually there's
some code smells left untreated.

Currently there's some discussion within the team of whether we should have
a refactoring iteration to address these code smells. As the coach I'm
trying to show how we can address these issues without resorting to this.

Post by kent beck
In Brad's case,

snipped

Post by kent beck
I've used a variety of iteration lengths. I've noticed that teams
almost always want to push for longer rather than shorter, but rarely
for reasons I've particularly liked. (Like some of you, I have on
occasion gone with the team's consensus.) Of course, I have the same
challenge about how much testing to do and lots of other stuff as
well.

I agree, I've seen our team perform better when the stories are smaller.
Better in terms of the story estimates are more accurate, stories actually
be completed on time, the Stories are more in line with what the customer
actually wanted - due to quicker better feedback. Obviously, this effects
our velocity as well. Also, the team's sense of accomplishment increases
when we achieve more stories per iteration.

But, despite all of this, as a whole the team finds it hard to break stories
down into smaller stories. Some members still question the 'value' of
breaking a story down.

Our lack of automated acceptance tests means it would be very difficult to
use a weekly iteration. Yet weirdly I think it may actually be a catalyst
for improving development as a team if we did attempt weekly iterations

Andrew



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

[Ron Jeffries]

Some members still question the 'value' of breaking a story down.

This comment made me think of creating some kind of information radiator
relating story size to accuracy of estimate. Have you tried that?

Ron Jeffries
www.XProgramming.com
Anyone can make the simple complicated.
Creativity is making the complicated simple. -- Charles Mingus






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

[Andrew McDonagh]

A cracking idea! - which strangely enough I've been thinking about just
this week, due mainly because of talk about information radiators at this
years XPDay in London, last week.

I think I try...scrub that... I AM going to try it over this iteration and
the next few.

Post by kent beck
-----Original Message-----
Sent: 30 November 2004 11:13
Subject: Re: [xpe2e] Practice: Weekly Cycle

Some members still question the 'value' of breaking a story down.

This comment made me think of creating some kind of information radiator
relating story size to accuracy of estimate. Have you tried that?
Ron Jeffries
www.XProgramming.com
Anyone can make the simple complicated.
Creativity is making the complicated simple. -- Charles Mingus
Yahoo! Groups Links

------------------------ 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 Pietri]

Post by Ron Jeffries
I continue to find task focus to be a problem. At least three problems, in
1. Task focus comes at the expense of story focus. Tasks get done but
somehow the story does not.

One compromise a recent team I coached came to was to break a story down
not into tasks but into tiny chunks of story. E.g., if an interaction
had several stages, the stages would be listed and checked off one by
one. Or if there were many fields involved, the whole flow might be
completed for just a couple of fields, and then additional fields were
added a few at a time.

I'm not sure how much that behavior contributed, but we rarely had the
problem of thinking that we were done when we weren't.

William
--
William Pietri <william-***@public.gmane.org>



------------------------ 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
--------------------------------------------------------------------~->

[Luiz Esmiralha]

Post by William Pietri

Post by Ron Jeffries
I continue to find task focus to be a problem. At least three problems,

in

Post by Ron Jeffries
1. Task focus comes at the expense of story focus. Tasks get done but
somehow the story does not.

One compromise a recent team I coached came to was to break a story down
not into tasks but into tiny chunks of story. E.g., if an interaction
had several stages, the stages would be listed and checked off one by
one. Or if there were many fields involved, the whole flow might be
completed for just a couple of fields, and then additional fields were
added a few at a time.
I'm not sure how much that behavior contributed, but we rarely had the
problem of thinking that we were done when we weren't.

How did you deal with the dependecies between the story chunks?

Thanks,

Luiz Esmiralha


------------------------ 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 Luiz Esmiralha
How did you deal with the dependecies between the story chunks?

That might be a good discussion for the extremeprogramming group.

My starting position is that there is only one kind of real inter-story
dependency: the sequential nature of the /stories/ such as the fact that
you can't save an edited file until you have one. (And I even know a way
around that one.)

I believe that for all practical purposes, there are no technical
dependencies between stories. After two stories are programmed, there may
be opportunities for refactoring. And a team that is in full communication
sees these coming, and starts the refactoring early.

I'm interested in what kind of dependencies you're interested in ... and
again, suggest that we'd benefit from the attention of the whole
extremeprogramming group, as this list is about the book.

Ron Jeffries
www.XProgramming.com
It is not because things are difficult that we do not dare,
it is because we do not dare that they are difficult. --Seneca




------------------------ 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 Pietri]

Post by Luiz Esmiralha

Post by William Pietri
One compromise a recent team I coached came to was to break a story down
not into tasks but into tiny chunks of story.

How did you deal with the dependecies between the story chunks?

I could think of a number of things you might mean by that. I'll guess
at which one it is, but if I guess wrong, please do correct me.

Generally, it wasn't a big concern; because we had scheduled the story
for the iteration, we were pretty sure it would be done when it
mattered.

But as with selecting stories, we always worked to find something
minimal to get working first. E.g., we'd start with the first page of
the sequence with just a couple of fields. Then we'd try it out, check
in, and look for the next small unit of work, like the error cases for
those fields. If we went for more than 60-90 minutes without something
we could look at and check in, we felt like we were on thin ice.

William

[olibye]

I'm one of those who's tended to making the PlanningGame on the
Tuesday.
* Most bank holidays occur on Mondays
* Users often have busy mail boxes and can't make monday.
* Mondays tend to be high volume days in banking.
* You don't get peoples excuses until Monday morning.

In the spirit of XP this was killing us, so we tried Tuesday and it
worked.

----

Two week cycles were requested twice in 2 years at WDS, the users
were certain they wanted something we said would take two iterations
(maybe they didn't want another planning meeting). Each time, one
week in, a new planning game was called and half finished work was
thrown away.

If we'd done it in one week iterations we'd atleast have something.

Now I'm at JP Morgan Chase and trying to sell agile again.
I'm insisting that we need to atleast aim for one week cycles.

People's objections
* "It's shorter than the budget approval process"
* "It's shorter than the change approval process"
* "It's shorter than people can technology can possibly imagine"

IMHO people often ask where the "Extreme" comes from. XP isn't a
bandwagon it's a Ferrari. Unless you're atleast prepared to imagine
the incredible effort it's going to take delivery functionality to
users closer to when they ask for it, then XP isn't for you.

PS You'll still be a week later than users actually need this stuff.

OliBye





------------------------ 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
--------------------------------------------------------------------~->

[kent beck]

Ron,

All of your arguments against tracking tasks can be mitigated by good coaching, keeping the team focused on delivering value to the customer. A team that gets focused on the micro-scale is what I was getting at with my comment about pride. A team proud of delivering will take the time to focus on delivery as the customer sees it. A team afraid of getting blamed will focus on plausible deniability--I got my tasks done, you can't blame me if the story doesn't work. The behavior you describe sounds like symptoms of deeper problems. Eliminating tasks won't eliminate those problems.

In my practice the task list isn't carved in stone. There is a picture of a task list in Planning XP that shows tasks elininated, cut in half, and added in the course of an iteration. The tasks give you individual accountability and the sense of being a team keeps you focused on the big picture. Both are necessary.

Kent Beck
Three Rivers Institute

-----Original Message-----
From: Ron Jeffries <ronjeffries-***@public.gmane.org>
Sent: Nov 24, 2004 3:35 AM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: Re: [xpe2e] Practice: Weekly Cycle

I continue to find task focus to be a problem. At least three problems, in
fact:

1. Task focus comes at the expense of story focus. Tasks get done but
somehow the story does not.

2. Task estimates too commonly become proof that we can't really do the
story in a week. The reason is that the task becomes overblown in some
way that isn't needed for current stories, and still falls short in some
way that another task or the whole story needs.

3. The initial task breakdown is a design without feedback. Focusing on
the tasks thereafter commonly misses the more creative solution to the
story.

I strongly favor brainstorming tasks and then spiking through stories with
the tasks in mind but without task focus. Then elaborate the code, again
with tasks in mind, until the story is complete. The tasks brainstormed may
not be complete -- they may not even be necessary.



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

[Ron Jeffries]

Certainly good coaching can help. Many teams choose to operate without
coaches, and I find that they fairly consistently have difficulty getting
focus away from the micro-scale.

(I understand your point about pride now. Thank you.)

Recently I visited a team who had fallen into a couple of traps: big
refactoring "stories", and large numbers of independent tasks adding up to
more work and less story value. They were sure that they were doing
something wrong, but weren't sure what to do. Coaching would have helped,
and in fact I trust that it did. Brian Marick and I sat with them and
paired through what they thought was a many-day story and helped them to
get it spiked in a day. Based on their reaction the next day, it seems fair
to say that they were "enlightened".

I fully agree that the task list ought not be carved in stone. Agreeing
that it takes coaching, pride, and a certain kind of team spirit to get the
story focus and task flexibility to balance out right, I've come to prefer
the approach of having the team treat the task list as "one way", making it
clear that it's not "the way", by not raising the tasks to the point of
accountability.

I would think -- but have not measured this so I'm just thinking -- that
the more flexibly the team treats the task list, the less individual
accountability for tasks one would have anyway. As I'm more interested in
team progress and team accountability than individual accountability, I'm
probably setting the story/task balance differently. If individual
accountability came up as more important, I'd consider at least two
options: tracking individual performance on stories, and then breaking down
into tasks and tracking that.

And of course, in the presence of pair programming, individual
accountability at any level is somewhat mitigated. That would be a whole
'nother topic.

Ron Jeffries
www.XProgramming.com
Prediction is very difficult, especially if it's about the future. -- Niels Bohr

Post by kent beck
All of your arguments against tracking tasks can be mitigated by good
coaching, keeping the team focused on
delivering value to the customer. A team that gets focused on the
micro-scale is what I was getting at with
my comment about pride. A team proud of delivering will take the time
to focus on delivery as the customer
sees it. A team afraid of getting blamed will focus on plausible
deniability--I got my tasks done, you can't
blame me if the story doesn't work. The behavior you describe sounds like symptoms of deeper problems.
Eliminating tasks won't eliminate those problems.
In my practice the task list isn't carved in stone. There is a picture of a task list in Planning XP that
shows tasks elininated, cut in half, and added in the course of an
iteration. The tasks give you individual
accountability and the sense of being a team keeps you focused on the big picture. Both are necessary.

End quotation from kent beck, on Wednesday, November 24, 2004, at 1:13:14 PM




------------------------ 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
--------------------------------------------------------------------~->

[Marko van der Puil]

Practice: Weekly Cycle

Actually, this is the best part yet, and very recognisable. Since we
started working agile we somehow found that a one week iteration cycle
is giving us optimum performance.

Anything shorter than one week would be almost unworkable because of the
increase in the percentage of overhead (planning game / stand-up) on the
whole. Anything longer than a week just seemed to lead to student
syndrome.

( Johanna Rothman writes about student syndrome in her log:
http://www.jrothman.com/weblog/archive/2004_11_01_mpdarchive.html#109942
422980640438 )

Longer iterations have another danger. I've seen teams with four week
iterations. Now people tend to be busy. Sometimes the planning game gets
postponed, or even skipped all together. You don't want that, but that's
the sort of thing that just happens. Imagine what that would do to a
four week iteration project. In a one week iteration project skipping a
planning game is still a hazard, but the risk is significantly lower.

Having one week iterations has shortened our project time considerably.
We very seldom have a project of over three month's duration. Our
clients just let us run their project for three to four weeks then take
it home and play with it for a month or two. This allows them to
evaluate the project and gather feedback. After a while they come back
for any missing functionality or optimizations, if any, which we run
into a new project. These follow up projects are often less than half
the size of the first. Say at most a week or two.

This works extremely well for government organizations or banking or
other larger organisations whose internal decision making just takes up
more time. As an added benefit it allows the team to shift their focus
to other projects in the mean time.

As a second benefit this cycle gives clients the ability to discover
their real needs and priorities in contrast to their wants or initial
beliefs really well.

Post by kent beck
3. Break the stories into tasks. Team members sign up for tasks and
estimate them.

This is probably the part where our practise differs the most from
traditional XP. Because of the short iterations stories are simpler and
much more straight-forward. In the setup I've described above, the team
found splitting up stories into tasks and writing them on cards and then
signing up for them too much overhead. Sometime you do need to think the
tasks over. When a story is slightly more complex, or when someone has a
clear idea of how to implement the story, they write the tasks somewhere
on the story card. Because of the decreased complexity of the stories,
most of the time a pair signs up for a story, seeking assistance from
others where they feel they need it.

The planning game is rarely on a Monday. The planning game is usually on
the day the project starts, which might be any day of the week, but
Wednesdays and Thursdays seem more popular.

Post by kent beck
Planning is a form of necessary waste. It doesn't create much value

all

Post by kent beck
by itself. Work on gradually reducing the percentage of time you spend
planning. Some teams start with a whole day of planning for a week,

but

Post by kent beck
gradually refine their planning skills until they spend an hour

planning

Post by kent beck
for the week.

I don't necessarily agree to this phrasing. I think planning is a very
valuable activity and that a plan is a form of necessary waste that
doesn't create much value by itself. We've found that planning time
increases exponentially with iteration duration and the number of pairs
simultaneously on a project. Better split the project up and integrate
it later.

Post by kent beck
I thin*K* ownership of tasks goes a long way towards
satisfying the human need for ownership. I've seen other styles work

well,

Post by kent beck
though. You can write small stories that eliminate the need for

separate

Post by kent beck
tasks. The cost of this approach is more work for the customer.

As you can see ownership is covered by a person or pair signing up for a
story in our team. That works well because the pair also gets to
experience the sense of fulfilment of delivering that value to the
customer themselves.

Somehow the seven day week is a pattern that humans have ultimately
adjusted to at perhaps an unconscious or even genetic (or religious)
level. It balances effort and regeneration. Adjusting your iteration
length along it looks like a very good idea.

Cheers,


Marko van der Puil.

ZeelandNet B.V. de provider die meer doet.
Postbus 35
4493 ZG Kamperland
Het Rip 9
4493 RL Kamperland
T:0031 (0) 113 37 77 78
F:0031 (0) 113 37 77 84
http://www.zeelandnet.nl

-------------
Op de inhoud van dit e-mailbericht en de daaraan gehechte bijlagen is de inhoud van de volgende disclaimer van toepassing: http://www.zeelandnet.nl/disclaimer.php


------------------------ 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
--------------------------------------------------------------------~->

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

-----Original Message-----
From: William Wake <william.wake-***@public.gmane.org>

All -
When you have two-week iterations, I'm curious what that means:
- do you have twice as many stories "in process"?
- is your typical story unable to be completed in a single week?
- or is a story the "usual" :) size, but you have "wait time" within it?
- do you tie releases to the iteration length at all?
- ... (the other 20 reasons I'm not clever enough to make up here)

I'm curious about the question behind all of this. What problem are we trying to solve? I know Scrum teams that have four week sprints and they work fine for them. Teams I work with tend to have 2 week iterations. There are two reasons why I occasionally try 1 week iterations: 1) to develop more practice discipline, and help people learn how to work in smaller increments, 2) to give the customer more control. But, generally these are not long term concerns.

I do see the benefit of shorter iterations, but to me it should be tied to a concrete problem. Otherwise, aren't we optimizing something that may not need to be optimized?


Michael Feathers
http://butunclebob.com/ArticleS.MichaelFeathers.TheNewGuy








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

[John Goodsen]

Post by kent beck
-----Original Message-----
All -
- do you have twice as many stories "in process"?
- is your typical story unable to be completed in a single week?
- or is a story the "usual" :) size, but you have "wait time" within it?
- do you tie releases to the iteration length at all?
- ... (the other 20 reasons I'm not clever enough to make up here)
I'm curious about the question behind all of this. What problem are
we trying to solve? I know Scrum teams that have four week sprints
and they work fine for them. Teams I work with tend to have 2 week
iterations. There are two reasons why I occasionally try 1 week
iterations: 1) to develop more practice discipline, and help people
learn how to work in smaller increments, 2) to give the customer more
control. But, generally these are not long term concerns.
I do see the benefit of shorter iterations, but to me it should be
tied to a concrete problem. Otherwise, aren't we optimizing something
that may not need to be optimized?

It's a feedback issue. How a quickly do you want or need your feedback
to (a)
stay on track and (b) identify your velocity. I like the iteration to
end before I
go off the road, preferably before I hit the rumble strip or the gravel.

One week iterations are nice, because they are on a natural human
cycle. Monthly
iterations are nice because they are also on a natural human cycle.
I've used bi-monthly iterations a lot and they have also seemed to work
well.

SIze of project also matters ... bigger projects seem to migrate
towards longer iterations.

----
John Goodsen RADSoft / Better Software Faster
jgoodsen-***@public.gmane.org Extreme Programmer and Coach
http://www.radsoft.com Enterprise Java and .NET Solutions



------------------------ 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]

On Wed, 24 Nov 2004 23:22:56 -0500 (GMT-05:00),

Post by kent beck
-----Original Message-----
- do you have twice as many stories "in process"?
- is your typical story unable to be completed in a single week?
- or is a story the "usual" :) size, but you have "wait time" within it?
- do you tie releases to the iteration length at all?
- ... (the other 20 reasons I'm not clever enough to make up here)
I'm curious about the question behind all of this. What problem are
we trying to solve?

If the question is "solve by having shorter iterations in all cases",
I don't think I know. If the question is "solve by answering these
questions", it's really to help me understand better the pressures
teams feel & how they deal with it.

I'd say I've seen often enough that a shorter iteration can help
teams, by teaching them things like "parts of stories are often
valuable" or "actually delivering something today is worth a lot of
talk about how great it's gonna be" or "smaller stories have fewer
bugs" etc.

But I've often heard argument that the iteration (or the release
cycle) "oughta" be longer - (in one case, arguing against quarterly
releases in an IT shop).

[Keith Ray]

When the team is small, and it is difficult to figure out how to break
stories down into really small stories [or the customer just doesn't
want to do that], moving from one-week iterations to two-week
iterations has worked in my experience -- in the sense that more
stories are complete at the end of an iteration, and having a story
"half-done" doesn't happen as often.


------------------------ 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
--------------------------------------------------------------------~->

[Andrew McDonagh]

This is our current situation, and likewise, two week iterations work best
for us. Yet I think we maybe papering of a deeper problem(s). My previous
post highlights some of my teams issues.

Post by kent beck
-----Original Message-----
Sent: 29 November 2004 17:33
Subject: Re: [xpe2e] Practice: Weekly Cycle
When the team is small, and it is difficult to figure out how to break
stories down into really small stories [or the customer just doesn't
want to do that], moving from one-week iterations to two-week
iterations has worked in my experience -- in the sense that more
stories are complete at the end of an iteration, and having a story
"half-done" doesn't happen as often.

------------------------ 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
--------------------------------------------------------------------~->

[Kent Beck]

The problems to be solved are:
* Having a sense of progress
* Having an accurate measure of progress
* Delivering efficiently
* Tracking changing needs
* Building a trust-based relationship inside and outside the team
* Enabling the team to offer accountability

One of my principles is working with human nature, including natural time
cycles. One week and one month are common cycles. That's why I'm suspicious
of two-week iterations--fortnights aren't nearly as widely used as either
weeks or months.

I have a question for those using two week iterations. After the first week,
how do you know if you are half done? Is this even an interesting question?

Kent Beck
Three Rivers Institute

-----Original Message-----
From: mfeathers-***@public.gmane.org [mailto:mfeathers-***@public.gmane.org]
Sent: Wednesday, November 24, 2004 8:23 PM
To: xpbookdiscussiongroup-***@public.gmane.org;
xpbookdiscussiongroup-***@public.gmane.org
Subject: Re: [xpe2e] Practice: Weekly Cycle




-----Original Message-----
From: William Wake <william.wake-***@public.gmane.org>

All -
When you have two-week iterations, I'm curious what that means:
- do you have twice as many stories "in process"?
- is your typical story unable to be completed in a single week?
- or is a story the "usual" :) size, but you have "wait time" within it?
- do you tie releases to the iteration length at all?
- ... (the other 20 reasons I'm not clever enough to make up here)

I'm curious about the question behind all of this. What problem are we
trying to solve? I know Scrum teams that have four week sprints and they
work fine for them. Teams I work with tend to have 2 week iterations.
There are two reasons why I occasionally try 1 week iterations: 1) to
develop more practice discipline, and help people learn how to work in
smaller increments, 2) to give the customer more control. But, generally
these are not long term concerns.

I do see the benefit of shorter iterations, but to me it should be tied to a
concrete problem. Otherwise, aren't we optimizing something that may not
need to be optimized?


Michael Feathers
http://butunclebob.com/ArticleS.MichaelFeathers.TheNewGuy










Yahoo! Groups Links










------------------------ 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
--------------------------------------------------------------------~->

[Keith Ray]

we know we're half done if about half of our current iteration's
stories are implemented and passing their acceptance tests.

Post by Kent Beck
* Having a sense of progress
* Having an accurate measure of progress
* Delivering efficiently
* Tracking changing needs
* Building a trust-based relationship inside and outside the team
* Enabling the team to offer accountability
One of my principles is working with human nature, including natural time
cycles. One week and one month are common cycles. That's why I'm suspicious
of two-week iterations--fortnights aren't nearly as widely used as either
weeks or months.
I have a question for those using two week iterations. After the first week,
how do you know if you are half done? Is this even an interesting question?
Kent Beck
Three Rivers Institute
-----Original Message-----
Sent: Wednesday, November 24, 2004 8:23 PM
Subject: Re: [xpe2e] Practice: Weekly Cycle
-----Original Message-----
All -
- do you have twice as many stories "in process"?
- is your typical story unable to be completed in a single week?
- or is a story the "usual" :) size, but you have "wait time" within it?
- do you tie releases to the iteration length at all?
- ... (the other 20 reasons I'm not clever enough to make up here)
I'm curious about the question behind all of this. What problem are we
trying to solve? I know Scrum teams that have four week sprints and they
work fine for them. Teams I work with tend to have 2 week iterations.
There are two reasons why I occasionally try 1 week iterations: 1) to
develop more practice discipline, and help people learn how to work in
smaller increments, 2) to give the customer more control. But, generally
these are not long term concerns.
I do see the benefit of shorter iterations, but to me it should be tied to a
concrete problem. Otherwise, aren't we optimizing something that may not
need to be optimized?
Michael Feathers
http://butunclebob.com/ArticleS.MichaelFeathers.TheNewGuy
Yahoo! Groups Links
Yahoo! Groups Links

--
----
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 --------------------~-->
$4.98 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/Q7_YsB/neXJAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~->

[John Goodsen]

Kent,

We typically do 1 or 2 week iterations, depending upon the project.
I have observed team/project size to be a relative factor. Smaller
teams (1-4 developers or so) seem to handle 1week iterations well.
Larger teams seem to handle two week iterations better than 1 week
iterations. I wonder why? Perhaps it is due to a reduce producitivty
per developer as you increase the team size (which increases
communication
overhead).

----
John Goodsen RADSoft / Better Software Faster
jgoodsen-***@public.gmane.org Extreme Programmer and Coach
http://www.radsoft.com Enterprise Java and .NET Solutions

[Friedrich Brunzema]

Our XP team (8 Programmers, 8 customer team members [Lead customer,
domain experts, testers, User Experience Expert, technical writer] is
in the process of making two major changes in the way we work, with
the ideas come from Kent Beck's book [weekly cycle]

1. Moving from 2 week iterations to 1 week iterations.
2. Moving from estimating in nuts (ideal units) to pair hours.

We were finding that our most productive day was the day before the
end of the iteration. Sometimes one half of the stories on the board
got accepted on the last day! We think that the one week iteration
will make us more productive, as it forces us to do quick iteration
planning. Also with 1 week iterations, its easy to see the Friday as
the goal that you are working towards. The shorter iterations will
force our customers to be more agile - they have to be able to get the
stories and the acceptance tests ready in time.

We also think that the estimates in pair hours will force greater
accountability from the programmers. It will be easier to figure out
how long the story took to execute vs. how much time was planned for
it. This will give programmers better feedback, and cause us to learn
to make better estimates. When asking for time extensions for a
story(revised estimates based on new learning), it will become clear
if the new length of time will cause the story to go beyond the end of
the iteration.

We are treating this as an experiment, that we will run for 4 weeks.
We feel that it will take a bit of time to "get good" at one week
iterations. I can keep the group posted on our experiences.

Friedrich Brunzema
Extreme Programmer & Coach

Post by John Goodsen
Kent,
We typically do 1 or 2 week iterations, depending upon the project.
I have observed team/project size to be a relative factor. Smaller
teams (1-4 developers or so) seem to handle 1week iterations well.
Larger teams seem to handle two week iterations better than 1 week
iterations. I wonder why? Perhaps it is due to a reduce producitivty
per developer as you increase the team size (which increases
communication
overhead).
----
John Goodsen RADSoft / Better Software Faster
http://www.radsoft.com Enterprise Java and .NET Solutions
Yahoo! Groups Links

[Paul Hodgetts]

Post by Andrew McDonagh
What we have seen is that when we have 'many smaller' stories per iteration,
rather than the usual 'few larger', we are more likely to finish them within
the iteration. I can almost guarantee that the 5 day estimated stories are
worked upon right up to the last minute before release, and usually there's
some code smells left untreated.
Currently there's some discussion within the team of whether we should have
a refactoring iteration to address these code smells. As the coach I'm
trying to show how we can address these issues without resorting to this.

Here's an idea:

In your iteration retrospective, briefly visit each story, and
ask if the story was "comfortably completed," where "comfort"
means it wasn't rushed at the end of the iteration, minimal
code smells were left un-addressed, there was sufficient time
for Customer review and feedback, etc. Keep track of the
answers vs. story size over time. Post these results on a BVC.

If your hunch is correct, the larger stories should score low
on the comfortably complete scale, and the small ones higher.

If the team doesn't know how to answer "comfortably complete,"
or can't agree on the criteria, that's another issue to visit.

Regards,
Paul
-----
Paul Hodgetts -- CEO, Principal Consultant
phodgetts-***@public.gmane.org -- [phone]

Agile Logic
www.agilelogic.com
1519 E. Chapman Ave. #254 -- Fullerton, CA, USA 92831
Consulting, Coaching, Training -- On-Site & Out-Sourced Development
Agile Processes/Lean/XP/Scrum -- Java/J2EE, C++, OOA/D, UI/IA, XML



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

[Andrew McDonagh]

Post by kent beck
-----Original Message-----
Sent: 01 December 2004 02:50
Subject: [xpe2e] Re: Practice: Weekly Cycle

snipped

Post by kent beck

Post by Andrew McDonagh
a refactoring iteration to address these code smells. As the coach I'm
trying to show how we can address these issues without

resorting to this.
In your iteration retrospective, briefly visit each story, and
ask if the story was "comfortably completed," where "comfort"
means it wasn't rushed at the end of the iteration, minimal
code smells were left un-addressed, there was sufficient time
for Customer review and feedback, etc. Keep track of the
answers vs. story size over time. Post these results on a BVC.
If your hunch is correct, the larger stories should score low
on the comfortably complete scale, and the small ones higher.

Thanks Paul,

Thats a great idea and as we are having a Retro today, I think I try it...

Post by kent beck
If the team doesn't know how to answer "comfortably complete,"
or can't agree on the criteria, that's another issue to visit.

Agreeing upon the criteria will no doubt be a problem, as there are
differing opinions as what 'complete' means. The amount of refactoring and
the amount of code TDDd, how to test, etc, varies amongst the team members -
which is currently cause some 'friction'.

Andrew



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

[Ben Hogan]

Paul,

Is the fact that a story is "comfortably completed" a side-effect of
the ordering or priority in the iteration?

Iterations are in some ways just a reporting boundary, so the last
card in an iteration will often be incomplete, and if you have a
larger team, you will have multiple incomplete stories. This is
assuming that you have a constant pace, and you don't speed up or slow
down to accomodate the iteration boundary. Both speeding up and
slowing down seem like a bad idea to me.
--
Ben Hogan
http://geekbeers.blogspot.com
bwhogan AT gmail.com


On Tue, 30 Nov 2004 18:49:47 -0800, Paul Hodgetts

Post by Paul Hodgetts
In your iteration retrospective, briefly visit each story, and
ask if the story was "comfortably completed," where "comfort"
means it wasn't rushed at the end of the iteration, ...

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

[Andrew McDonagh]

I agree with you wrt slowing down/speeding up at the iteration boundaries.
However, having larger stories that are not completed, greatly effects the
velocity of the team, as the uncompleted stories can not be counted as being
done.

When have a few large stories, the effect upon our over all velocity is
greater when stories are not finished.

When have many smaller stories, the effect upon our over all velocity is
lower when stories are not finished.

Aside from this, I find (in general) the bigger the estimate/story, the
least the team actually understands it and often miss many tasks.
Essentially larger stories tend to always be under-estimated.

Andrew

Post by kent beck
-----Original Message-----
Sent: 01 December 2004 14:41
Subject: Re: [xpe2e] Re: Practice: Weekly Cycle
Paul,
Is the fact that a story is "comfortably completed" a side-effect of
the ordering or priority in the iteration?
Iterations are in some ways just a reporting boundary, so the last
card in an iteration will often be incomplete, and if you have a
larger team, you will have multiple incomplete stories. This is
assuming that you have a constant pace, and you don't speed up or slow
down to accomodate the iteration boundary. Both speeding up and
slowing down seem like a bad idea to me.
--
Ben Hogan
http://geekbeers.blogspot.com
bwhogan AT gmail.com
On Tue, 30 Nov 2004 18:49:47 -0800, Paul Hodgetts

Post by Paul Hodgetts
In your iteration retrospective, briefly visit each story, and
ask if the story was "comfortably completed," where "comfort"
means it wasn't rushed at the end of the iteration, ...

Yahoo! Groups Links

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

[Ben Hogan]

On Wed, 1 Dec 2004 15:47:00 -0000, Andrew McDonagh

Post by Andrew McDonagh
When have a few large stories, the effect upon our over all velocity is
greater when stories are not finished.

Indeed, when your stories are small enough, the impact on your
velocity would be minimal as you suggested, meaning you would have
little incentive to rush at the end.
--
Ben Hogan
http://geekbeers.blogspot.com
bwhogan AT gmail.com


------------------------ 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
--------------------------------------------------------------------~->

[Andrew McDonagh]

Post by kent beck
-----Original Message-----
Sent

Post by Andrew McDonagh
When have a few large stories, the effect upon our over all velocity is
greater when stories are not finished.

Indeed, when your stories are small enough, the impact on your
velocity would be minimal as you suggested, meaning you would have
little incentive to rush at the end.

Yeah, its the incentive to rush at the end that then causes other problems -
code smells, untested code, acceptance tests not run...yada yada yada...



------------------------ 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
--------------------------------------------------------------------~->

[Michael Feathers]

Post by Andrew McDonagh

Post by kent beck
-----Original Message-----
Sent

Post by Andrew McDonagh
When have a few large stories, the effect upon our over all

velocity is

Post by kent beck

Post by Andrew McDonagh
greater when stories are not finished.

Indeed, when your stories are small enough, the impact on your
velocity would be minimal as you suggested, meaning you would have
little incentive to rush at the end.

Yeah, its the incentive to rush at the end that then causes other problems -
code smells, untested code, acceptance tests not run...yada yada yada...

That's a practice I use with teams. I call it "ease off" If it's the
last day of an iteration you should either be pleasantly pleased about
what you've gotten done and perhaps slightly sad about what you
couldn't, but you shouldn't be agitated and trying to get things done.
If you are, you need to find a way back to the other state. Learning
how to "ease off" is very important.

Michael Feathers
http://butunclebob.com/ArticleS.MichaelFeathers.TheNewGuy





------------------------ 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
--------------------------------------------------------------------~->

[Andrew McDonagh]

Post by Michael Feathers
That's a practice I use with teams. I call it "ease off" If it's the
last day of an iteration you should either be pleasantly pleased about
what you've gotten done and perhaps slightly sad about what you
couldn't, but you shouldn't be agitated and trying to get things done.
If you are, you need to find a way back to the other state. Learning
how to "ease off" is very important.

I like that...


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

[Ron Jeffries]

Post by Ben Hogan
Iterations are in some ways just a reporting boundary, so the last
card in an iteration will often be incomplete, and if you have a
larger team, you will have multiple incomplete stories. This is
assuming that you have a constant pace, and you don't speed up or slow
down to accomodate the iteration boundary. Both speeding up and
slowing down seem like a bad idea to me.

Do, or do not. There is no try. -- Yoda

Ron Jeffries
www.XProgramming.com
To be on the wire is life. The rest is waiting. --Karl Wallenda




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

[Keith Nicholas]

Iterations do a few things :-

Focus you on releasing software often
Remind you to keep planning
Timebox a bunch of work so you can predict forward.

What we have found is that *we* don't need an iteration as such. We can
plan ALL the time. We can Release ALL the time. But we still need a
timebox that you can say, we can get X done in X time. We got to this
point though by doing iterations weekly and doing the planning game.
Another Team I'm working with we are using a good ol weekly iteration.

Regards,

Keith

Post by kent beck
-----Original Message-----
Sent: Thursday, 2 December 2004 3:41 a.m.
Subject: Re: [xpe2e] Re: Practice: Weekly Cycle
Paul,
Is the fact that a story is "comfortably completed" a
side-effect of the ordering or priority in the iteration?
Iterations are in some ways just a reporting boundary, so the
last card in an iteration will often be incomplete, and if
you have a larger team, you will have multiple incomplete
stories. This is assuming that you have a constant pace, and
you don't speed up or slow down to accomodate the iteration
boundary. Both speeding up and slowing down seem like a bad
idea to me.
--
Ben Hogan
http://geekbeers.blogspot.com
bwhogan AT gmail.com
On Tue, 30 Nov 2004 18:49:47 -0800, Paul Hodgetts

Post by Paul Hodgetts
In your iteration retrospective, briefly visit each story, and
ask if the story was "comfortably completed," where "comfort"
means it wasn't rushed at the end of the iteration, ...

------------------------ Yahoo! Groups Sponsor
--------------------~-->
$9.95 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------
------~->
Yahoo! Groups Links

------------------------ 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
--------------------------------------------------------------------~->

[Ben Hogan]

Post by Keith Nicholas
Another Team I'm working with we are using a good ol weekly iteration.

In a previous project we used weekly iterations and it was wonderful,
it really helped with what you suggested, especially "Focus you on
releasing software often".
--
Ben Hogan
http://geekbeers.blogspot.com
bwhogan AT gmail.com


------------------------ 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
--------------------------------------------------------------------~->

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

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

Is the fact that a story is "comfortably completed" a side-effect of
the ordering or priority in the iteration?


--->
What I'd do is chart "comfort of completion" against story, and then inquire
each time and over time what might have caused the discomfort. I suspect
different things could turn up over time, and that would inform the group about
their situation and work patterns.

==============================================
Alistair Cockburn

[Paul Hodgetts]

Post by Ben Hogan
Paul,
Is the fact that a story is "comfortably completed" a side-
effect of the ordering or priority in the iteration?

Sure it can be. I think there are a lot of things that can
contribute to a story not being comfortably complete, besides
the story size issue we started with. Leaving a small, high
risk story until the end of the iteration, even though it may
mathematically fit, could be a pattern that produces
uncomfortably complete stories as well.

Post by Ben Hogan
Iterations are in some ways just a reporting boundary, so
the last card in an iteration will often be incomplete, and
if you have a larger team, you will have multiple incomplete
stories. This is assuming that you have a constant pace, and
you don't speed up or slow down to accomodate the iteration
boundary. Both speeding up and slowing down seem like a bad
idea to me.

Iterations are also an important closure point for the team.
There is a rhythm that develops around the iterations. I
really don't see teams that have some constant level of
development activity going on, and then, oh, by the way, the
iteration ends today. There is always something more special
about the iteration boundary.

I think it has to do with the closure of one set of stories,
and the planning of a new set. And the synchronization point
with the Customer and stakeholders when they get another
(as Scrum calls it) potentially shippable increment. So, I
see teams running iterations where the pace is not constant
throughout the whole iteration, and the rhythm within the
iteration has rises and dips, and there is a crescendo at the
end.

I agree that the team running up a bunch of overtime hours in
the last days of an iteration in a mad rush to complete the
last few stories can be an anti-pattern. I like Michael
Feather's pattern of Ease Off as part of a healthy overall
iteration rhythm. IMHO, there needs to be an awareness of
reaching the closure of the iteration. Of course not all
iterations are intended to ship, but I think it's healthier
to act as if they all should be able to.

It would be ideal if there were no half-finished stories
hanging around at the end of an iteration, but it happens.
For the purposes of the original comfort metric, I'd say the
team just uses some common sense. If they know there is a
partially completed story that happened as part of the
"normal" state of things, they don't have to hold that up as
an example of an uncomfortable story. I would say it's more
useful to look at the stories that the team (or part of the
team) thinks of as being delivered by the iteration and see
how comfortably complete they really are.

The "comfortably complete" metric is intended to be simple,
subjective and imprecise. Perhaps trying to analyze it and
define it for general use has diminishing returns, and it's
best left up to a team to figure out what to do with it. I
thought it was a good example of how a simple metric that
takes just a few minutes per iteration to gather could be
very useful for an important process attribute like story
sizing. Something like: "Gather the simplest metrics that
could possibly help." ;-)

Paul
-----
Paul Hodgetts -- CEO, Principal Consultant
phodgetts-***@public.gmane.org -- [phone]

Agile Logic
www.agilelogic.com
1519 E. Chapman Ave. #254 -- Fullerton, CA, USA 92831
Consulting, Coaching, Training -- On-Site & Out-Sourced Development
Agile Processes/Lean/XP/Scrum -- Java/J2EE, C++, OOA/D, UI/IA, XML



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

[Paul Hodgetts]

Post by Andrew McDonagh
Thanks Paul,
Thats a great idea and as we are having a Retro today, I
think I try it...

Please let us know what happens.

Post by Andrew McDonagh

Post by Paul Hodgetts
If the team doesn't know how to answer "comfortably complete,"
or can't agree on the criteria, that's another issue to visit.

Agreeing upon the criteria will no doubt be a problem, as
there are differing opinions as what 'complete' means. The
amount of refactoring and the amount of code TDDd, how to
test, etc, varies amongst the team members - which is
currently cause some 'friction'.

I think a common agreement across the team (everyone, not just
the developers) of what "complete" means is so important that I
now include a "What is complete?" exercise as part of my agile
transition approach. It's often useful to do a little overall
value stream mapping along with it to provide a context to make
sure all the important aspects of "done" are considered.

A team can reach an agreement on "complete" over time via their
iteration retrospectives, but I find that a little up-front
discussion, and a little ceremony around the agreement, can get
everyone on the same page more quickly, they know what to expect
from each other, and then they can refine things over time.

Paul
-----
Paul Hodgetts -- CEO, Principal Consultant
Agile Logic -- www.agilelogic.com
Consulting, Coaching, Training -- On-Site & Out-Sourced Development
Agile Processes/Lean/XP/Scrum -- Java/J2EE, C++, OOA/D, UI/IA, XML



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

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

Post by kent beck
-----Original Message-----

...

Post by kent beck
I believe that for all practical purposes, there are no technical
dependencies between stories. After two stories are programmed, there may
be opportunities for refactoring. And a team that is in full communication
sees these coming, and starts the refactoring early.

Hi Ron,

I don't quite understand. What do you mean by "early"?
Not before there is duplication, I hope. And I imagine
not before the bar is Green.

You seem to be saying that dependencies between stories
are really just "preemptive refactorings" in the minds of
the developers. And, if you just except the fact that
you *may* need refactoring afterwards, then you can keep
the stories independent. I agree.

But, suggesting that a team "starts the refactoring early"
doesn't sound much different then the preemptive mental
refactorings that lead to the belief in story dependencies.
I have to admit that I often fall prey to this - denying
there is any real dependency between the stories, but then
being very careful to pick the right one first...

Could you explain this a bit more? Thanks.

-- Jim Long



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

[Ron Jeffries]

Post by j***@public.gmane.org
I don't quite understand. What do you mean by "early"?
Not before there is duplication, I hope. And I imagine
not before the bar is Green.
You seem to be saying that dependencies between stories
are really just "preemptive refactorings" in the minds of
the developers. And, if you just except the fact that
you *may* need refactoring afterwards, then you can keep
the stories independent. I agree.
But, suggesting that a team "starts the refactoring early"
doesn't sound much different then the preemptive mental
refactorings that lead to the belief in story dependencies.
I have to admit that I often fall prey to this - denying
there is any real dependency between the stories, but then
being very careful to pick the right one first...
Could you explain this a bit more? Thanks.

When two or more pairs work on related stories, it often takes a while for
duplication to be noticed, because it's often duplication of functionality,
but not of code. It can sometimes be quite a few iterations before anyone
notices. But if you're brainstorming tasks, and otherwise communicating
intensely about the design, you can catch the duplication earlier and
therefore not let yourself get behind on the refactoring.

Ron Jeffries
www.XProgramming.com
I could be wrong, but I'm not. --Eagles, Victim of Love




------------------------ 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 E Caputo]

<html><body> <FONT face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size=2><DIV>Jim Long:</DIV><DIV>&gt;<FONT face="Courier New">But, suggesting that a team "starts the refactoring early"<BR>&gt;doesn't sound much different then the preemptive mental<BR>&gt;refactorings that lead to the belief in story dependencies.</FONT><BR></DIV><DIV>I'm not Ron (obviously) and his answer may be different (probably), but my feeling about this is that its the&nbsp;difference between doing something unknowingly, and doing something conciously. </DIV><DIV>&nbsp;</DIV><DIV>Or for the pragmatic: It's the sort of thing described by the Dreyfus Model of Skill Acquisition (Pragmatic Dave has&nbsp;a good blog on the topic here: <A href="http://pragprog.com/pragdave/Practices/ValueWorker.rdoc/style/print" target=blank>http://pragprog.com/pragdave/Practices/ValueWorker.rdoc/style/print</A>)</DIV><DIV>&nbsp;</DIV>
<DIV>Or for the more mystical: It follows the pattern:&nbsp;ignore the path, learn the&nbsp;path, follow the path, adapt the path, forget (ignore) the path.</DIV><DIV>&nbsp;</DIV><DIV>Or for the more artistic: Its the difference between being a novice painter and thus not following the rules, and an expert painter and thus not following the rules.</DIV><DIV>&nbsp;</DIV><DIV>Or for the skeptic: It's, all of course BullSh*t -- except that all project teams do seem to get to this point eventually when things are really working. </DIV><DIV>&nbsp;</DIV><DIV>:-)</DIV><DIV><BR>Best,<BR>Bill (Channelling Mike H.)<BR><BR>William E. Caputo<BR>ThoughtWorks, Inc.<BR>http://<A href="http://www.williamcaputo.com" target=blank>www.williamcaputo.com</A><BR>--------<BR>"The user of social software is the group, not the individual." -- Clay Shirky<BR></DIV></FONT>

<br>

<!-- |**|begin egp html banner|**| -->

<table border=0 cellspacing=0 cellpadding=2>
<tr bgcolor=#FFFFCC>
<td align=center><font size="-1" color=#003399><b>Yahoo! Groups Sponsor</b></font></td>
</tr>
<tr bgcolor=#FFFFFF>
<td align=center width=470><table border=0 cellpadding=0 cellspacing=0> <tr> <td align=center><font face=arial size=-2>ADVERTISEMENT</font><br><a href="http://us.ard.yahoo.com/SIG=129balgru/M=298184.5639630.6699735.3001176/D=groups/S=1705007207:HM/EXP=1102443446/A=2434971/R=0/SIG=11eeoolb0/*http://www.netflix.com/Default?mqso=60185400" alt=""><img src="Loading Image..." alt="click here" width="300" height="250" border="0"></a></td></tr></table> </td>
</tr>
<tr><td><img alt="" width=1 height=1 src="http://us.adserver.yahoo.com/l?M=298184.5639630.6699735.3001176/D=groups/S=:HM/A=2434971/rand=657937975"></td></tr>
</table>

<!-- |**|end egp html banner|**| -->



<!-- |**|begin egp html banner|**| -->

<br>
<tt><hr width="500">
<b>Yahoo! Groups Links</b><br>
<ul>
<li>To visit your group on the web, go to:<br><a href="http://groups.yahoo.com/group/xpbookdiscussiongroup/">http://groups.yahoo.com/group/xpbookdiscussiongroup/</a><br>&nbsp;
<li>To unsubscribe from this group, send an email to:<br><a href="mailto:xpbookdiscussiongroup-unsubscribe-***@public.gmane.org?subject=Unsubscribe">xpbookdiscussiongroup-unsubscribe-***@public.gmane.org</a><br>&nbsp;
<li>Your use of Yahoo! Groups is subject to the <a href="http://docs.yahoo.com/info/terms/">Yahoo! Terms of Service</a>.
</ul>
</tt>
</br>

<!-- |**|end egp html banner|**| -->


</body></html>

[david hussman]

Restating the obvious - a simple posting of stories for the iteration
and a gas gauge showing progress provides many teams a view that can be
discussed during the standup and determine some answer to "are we half
done." How does a team using a one week iteration know they are half
done the middle of the day Wednesday?

I coach all teams using two week iterations to discuss the "half done"
issue at the end of week one. This discussion sometimes causes the team
to move toward one week iterations.

Struggles I have had with one week iterations have to do with developer
skills (not able to find a groove until the iteration it almost over)
and customers frustrated with what they often call "unnatural" story
telling and writing (e.g. the customer starts telling a story only to
have the developers say that that amount of work cannot be accomplished
in one week).

I dig the strong focus and immediacy associated with shorter iterations,
but I think the cycle time must fit for the entire community, not just
the developers.

-----Original Message-----
From: Kent Beck [mailto:kentb-***@public.gmane.org]
Sent: Wednesday, December 15, 2004 11:04 AM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: RE: [xpe2e] Practice: Weekly Cycle


The problems to be solved are:
* Having a sense of progress
* Having an accurate measure of progress
* Delivering efficiently
* Tracking changing needs
* Building a trust-based relationship inside and outside the team
* Enabling the team to offer accountability

One of my principles is working with human nature, including natural
time
cycles. One week and one month are common cycles. That's why I'm
suspicious
of two-week iterations--fortnights aren't nearly as widely used as
either
weeks or months.

I have a question for those using two week iterations. After the first
week,
how do you know if you are half done? Is this even an interesting
question?

Kent Beck
Three Rivers Institute

-----Original Message-----
From: mfeathers-***@public.gmane.org [mailto:mfeathers-***@public.gmane.org]
Sent: Wednesday, November 24, 2004 8:23 PM
To: xpbookdiscussiongroup-***@public.gmane.org;
xpbookdiscussiongroup-***@public.gmane.org
Subject: Re: [xpe2e] Practice: Weekly Cycle




-----Original Message-----
From: William Wake <william.wake-***@public.gmane.org>

All -
When you have two-week iterations, I'm curious what that means:
- do you have twice as many stories "in process"?
- is your typical story unable to be completed in a single week?
- or is a story the "usual" :) size, but you have "wait time" within it?
- do you tie releases to the iteration length at all?
- ... (the other 20 reasons I'm not clever enough to make up here)

I'm curious about the question behind all of this. What problem are we
trying to solve? I know Scrum teams that have four week sprints and
they
work fine for them. Teams I work with tend to have 2 week iterations.
There are two reasons why I occasionally try 1 week iterations: 1) to
develop more practice discipline, and help people learn how to work in
smaller increments, 2) to give the customer more control. But,
generally
these are not long term concerns.

I do see the benefit of shorter iterations, but to me it should be tied
to a
concrete problem. Otherwise, aren't we optimizing something that may
not
need to be optimized?


Michael Feathers
http://butunclebob.com/ArticleS.MichaelFeathers.TheNewGuy










Yahoo! Groups Links












Yahoo! Groups Links









------------------------ 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
--------------------------------------------------------------------~->

[Appleton Brad-BRADAPP1]

Post by Kent Beck
One of my principles is working with human nature,
including natural time cycles. One week and one month are
common cycles. That's why I'm suspicious of two-week
iterations--fortnights aren't nearly as widely used as
either weeks or months.

At the large companies Ive worked, two-weeks was actually far more common than one week for anything but the individual task-level of planning. So those folks were more accustomed to having a monthly or semi-monthly/bi-weekly team-wide milestone. (perhaps it had something to do with how often we got our paychecks ;-)

Post by Kent Beck
I have a question for those using two week iterations.
After the first week, how do you know if you are half
done? Is this even an interesting question?

For us, it probably wouldn't have been an interesting question. We still had estimates and target-due-dates for individual tasks. So we would see what tasks/stories were done that were estimated to be done by then, and then decide how to adjust/correct if necessary. We would do that sort of thing in each daily meeting. But I suppose that particular conversation on the last workday of the week perhaps carried a bit more weightiness to it.




------------------------ 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
--------------------------------------------------------------------~->

[Erik Lundh]

Kent,
Two week iterations has worked as a good pace for my teams.
One reasons might be that there, in my part of the world., is always monday
morning meetings anyway with the rest of the company.
The weekly pace is part of human nature.
A team that has no "social synchronization points" outside the team would
probably experience two-week iterations as a desert walk.
But when I suggest weekly iterations in my context, most people get a hunted
expression in their eyes.
I guess iterations should not be so short that people feel fragmented.
Depending on context and organizational overhead, the mental "fragmentation
limit" might be 1,2 or 4 weeks.

Another thing that we should recognize is that the available tools support
productivity in shorter iterations much better today than 5 years ago.
The general availability of no-cost or low-cost tools for refactoring,
test-driven development and continous integration makes a difference.

However, I encourage all the customers on the team , internal as well as
external, to be present at each planning game.
When some of the customers are out there travelling and scouting for the
team, it is more human to call them back to the home base every two weeks
rather than every week.

However, to clarify how we avoid making two week iterations static:
* My teams do not practice big upfront signup of tasks to individuals.
The next available person takes the next task card and invites someone to
pair.
The group figures out how to get the experienced people available as pair
partners.
We apply Mary Poppendiecks "Measusure Up"-principle on the team.
We do not measure on indviduals.
And we save several team-hours on each iteration by not playing the
signup game.
* A completed iteration is not defined as a completed brundown chart (as it
is in SCRUM)
* A completed iteration is defined as the customers on team not being
surprised or disappointed
by what they see at the release & demo preceding the next planning game.

/Erik
----------------------------------------------------------------------------
---------------
Compelcon - develops software industry - www.compelcon.se
www.XPseminarie.nu - Hur du lyckas med utvecklingsprojekt NU!
----- Original Message -----
From: "Kent Beck" <kentb-***@public.gmane.org>
To: <xpbookdiscussiongroup-***@public.gmane.org>
Sent: Wednesday, December 15, 2004 6:04 PM
Subject: RE: [xpe2e] Practice: Weekly Cycle

Post by Kent Beck
* Having a sense of progress
* Having an accurate measure of progress
* Delivering efficiently
* Tracking changing needs
* Building a trust-based relationship inside and outside the team
* Enabling the team to offer accountability
One of my principles is working with human nature, including natural time
cycles. One week and one month are common cycles. That's why I'm

suspicious

Post by Kent Beck
of two-week iterations--fortnights aren't nearly as widely used as either
weeks or months.
I have a question for those using two week iterations. After the first

week,

Post by Kent Beck
how do you know if you are half done? Is this even an interesting

question?

Post by Kent Beck
Kent Beck
Three Rivers Institute
-----Original Message-----
Sent: Wednesday, November 24, 2004 8:23 PM
Subject: Re: [xpe2e] Practice: Weekly Cycle
-----Original Message-----
All -
- do you have twice as many stories "in process"?
- is your typical story unable to be completed in a single week?
- or is a story the "usual" :) size, but you have "wait time" within it?
- do you tie releases to the iteration length at all?
- ... (the other 20 reasons I'm not clever enough to make up here)
I'm curious about the question behind all of this. What problem are we
trying to solve? I know Scrum teams that have four week sprints and they
work fine for them. Teams I work with tend to have 2 week iterations.
There are two reasons why I occasionally try 1 week iterations: 1) to
develop more practice discipline, and help people learn how to work in
smaller increments, 2) to give the customer more control. But, generally
these are not long term concerns.
I do see the benefit of shorter iterations, but to me it should be tied to

a

Post by Kent Beck
concrete problem. Otherwise, aren't we optimizing something that may not
need to be optimized?
Michael Feathers
http://butunclebob.com/ArticleS.MichaelFeathers.TheNewGuy
Yahoo! Groups Links
Yahoo! Groups Links

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

[Erik Lundh]

Clarification:
My teams learns from practice that they sometimes go faster, sometimes
slower, than expected.
They tend to be proud of continously improving the precision of their
estimates and breakdowns into engineering tasks.
And I encourage them to have a few extra tasks ready for each iteration, if
they go faster than expected.
Otherwise they may go idle the last few days before the planning game. if
they struck gold or divine inspiration.
Strict timeboxing means fixed dates that you can trust for each delivery and
planning game.
Needless to say, strict timeboxing is very popular with management and
customers.
Dates you can trust is gold.

The lowest priority user story/ies in an iteration plan is often considered
to be of much less value than a firm date.
At least with a proper management of expectations.

And if the team happens to go faster rather tha slower than expected, I have
never seens an unhappy customer when they get more than they expected.

But the teams should never expect to continue in the next iteration of these
few extra tasks.
They have to be prepared to clean the slate at each planning game.

However, I have made the mistake to let teams make detailed plans
(engineering task level) for several iterations ahead.
The result has been a dramatic decrease in performance.
The lost the learning from each iteration, reflected as new prioritization,
improved breakdown in tasks, and improved estimates.
The continous improvement stopped, and the deviation between current
experience and previously laid plans became painful.


/Erik
----------------------------------------------------------------------------
---------------
Compelcon - develops software industry - www.compelcon.se
www.XPseminarie.nu - Hur du lyckas med utvecklingsprojekt NU!
----- Original Message -----
From: "Kent Beck" <kentb-***@public.gmane.org>
To: <xpbookdiscussiongroup-***@public.gmane.org>
Sent: Wednesday, December 15, 2004 6:04 PM
Subject: RE: [xpe2e] Practice: Weekly Cycle

Post by Kent Beck
* Having a sense of progress
* Having an accurate measure of progress
* Delivering efficiently
* Tracking changing needs
* Building a trust-based relationship inside and outside the team
* Enabling the team to offer accountability
One of my principles is working with human nature, including natural time
cycles. One week and one month are common cycles. That's why I'm

suspicious

Post by Kent Beck
of two-week iterations--fortnights aren't nearly as widely used as either
weeks or months.
I have a question for those using two week iterations. After the first

week,

Post by Kent Beck
how do you know if you are half done? Is this even an interesting

question?

Post by Kent Beck
Kent Beck
Three Rivers Institute
-----Original Message-----
Sent: Wednesday, November 24, 2004 8:23 PM
Subject: Re: [xpe2e] Practice: Weekly Cycle
-----Original Message-----
All -
- do you have twice as many stories "in process"?
- is your typical story unable to be completed in a single week?
- or is a story the "usual" :) size, but you have "wait time" within it?
- do you tie releases to the iteration length at all?
- ... (the other 20 reasons I'm not clever enough to make up here)
I'm curious about the question behind all of this. What problem are we
trying to solve? I know Scrum teams that have four week sprints and they
work fine for them. Teams I work with tend to have 2 week iterations.
There are two reasons why I occasionally try 1 week iterations: 1) to
develop more practice discipline, and help people learn how to work in
smaller increments, 2) to give the customer more control. But, generally
these are not long term concerns.
I do see the benefit of shorter iterations, but to me it should be tied to

a

Post by Kent Beck
concrete problem. Otherwise, aren't we optimizing something that may not
need to be optimized?
Michael Feathers
http://butunclebob.com/ArticleS.MichaelFeathers.TheNewGuy
Yahoo! Groups Links
Yahoo! Groups Links

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

[Steve]

Post by Kent Beck
...
One of my principles is working with human nature, including natural time
cycles. One week and one month are common cycles. That's why I'm
suspicious of two-week iterations--fortnights aren't nearly as
widely used as either weeks or months.

Are we perhaps overemphasizing the connection between iteration
lengths and human nature? I see little reason to associate human
nature with our Gregorian calendar although it's obvious there is
a social influence. Basing iteration length on actual lunar
cycles might be a more natural choice. I've never heard of a
team using that approach. However, I've noticed associated
effects on my own creative cycles (based on very unscientific
observations).

Steve



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

[Zhon Johansen]

Post by Kent Beck
* Having a sense of progress
* Having an accurate measure of progress
* Delivering efficiently
* Tracking changing needs
* Building a trust-based relationship inside and outside the team
* Enabling the team to offer accountability

With many of the same people we tried, three weeks, two weeks and one
week. Most of the time was spent doing two week iterations.
Three weeks:
* Iterations were frequently *broken* by customers, and managers
* Planning took a long time
* The cycle felt wrong
* Progress was measured too infrequently
Two weeks:
* Favorite of the team.
* Progress was measured every two weeks
* The cycle: plan, light design, fix problems, start tasks and
acceptance tests, start focusing on story, focus on story completion
and pass off, focus on optimizing the number of points
* Each iteration had about three days of relaxed work and three days
of very high energy work
* Tracking was done twice: Thursday and Tuesday (iterations started
on Monday)
* Sickness and holidays didn't impact velocity much (except
Christmas :) )
* It gave one weekend to think about your stories and one weekend to
forget work
* It adds a *doing something different* each week
One week iteration:
* Stories and tasks not completed
* Tasks became more important than stories
* Cycle missed the relaxed period
* Iterations were rarely *broken*
* Trouble fitting enough stories into iteration

On the middle Thursday we could tell how the iteration was going. If
things were in trouble we could increase the energy earlier in the final
week. On Wednesday, stories started being passed off. Late nights
occasionally happened on Wednesday and Thursday of the final week.

In answer to your question, we knew early if we our stories were going
to be completed and we reacted accordingly. I still need to think
about accountability. I am now seriously trying one week iterations
with a new team; I will let you know if accountability is increased.

cheers,

Zhon


------------------------ 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
--------------------------------------------------------------------~->

[Michael Feathers]

Post by Kent Beck
* Having a sense of progress
* Having an accurate measure of progress
* Delivering efficiently
* Tracking changing needs
* Building a trust-based relationship inside and outside the team
* Enabling the team to offer accountability
One of my principles is working with human nature, including natural time
cycles. One week and one month are common cycles. That's why I'm
suspicious
of two-week iterations--fortnights aren't nearly as widely used as either
weeks or months.
I have a question for those using two week iterations. After the first
week,
how do you know if you are half done? Is this even an interesting
question?

On one week cycles, how do we know on Wednesday?

Seriously, I don't know what the best cycle time is, but my observation
is that one size really can't fit all.

Michael Feathers





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

[Erik Lundh]

I second that.

/Erik Lundh
----------------------------------------------------------------------------
---------------
Compelcon - develops software industry - www.compelcon.se
www.XPseminarie.nu - Hur du lyckas med utvecklingsprojekt NU!
----- Original Message -----
From: "Michael Feathers" <mfeathers-***@public.gmane.org>
To: <xpbookdiscussiongroup-***@public.gmane.org>
Sent: Thursday, December 16, 2004 2:33 AM
Subject: Re: [xpe2e] Practice: Weekly Cycle

Post by Michael Feathers

Post by Kent Beck
* Having a sense of progress
* Having an accurate measure of progress
* Delivering efficiently
* Tracking changing needs
* Building a trust-based relationship inside and outside the team
* Enabling the team to offer accountability
One of my principles is working with human nature, including natural time
cycles. One week and one month are common cycles. That's why I'm
suspicious
of two-week iterations--fortnights aren't nearly as widely used as either
weeks or months.
I have a question for those using two week iterations. After the first
week,
how do you know if you are half done? Is this even an interesting
question?

On one week cycles, how do we know on Wednesday?
Seriously, I don't know what the best cycle time is, but my observation
is that one size really can't fit all.
Michael Feathers
Yahoo! Groups Links

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

[Kent Beck]

I didn't hear anyone say that one size should fit all. I cited one principle
in support of one-week cycles. I'm sure there are other principles in
support of two-week cycles. I'm interested in hearing them, not in strawman
arguments.

Kent Beck
Three Rivers Institute

-----Original Message-----
From: Michael Feathers [mailto:mfeathers-***@public.gmane.org]
Sent: Wednesday, December 15, 2004 5:33 PM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: Re: [xpe2e] Practice: Weekly Cycle

Seriously, I don't know what the best cycle time is, but my observation
is that one size really can't fit all.



------------------------ 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
--------------------------------------------------------------------~->

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

Post by Kent Beck
I have a question for those using two week iterations. After the first
week, how do you know if you are half done? Is this even an interesting
question?

Kent - One of the teams at Chase (that you kicked off nearly two years
ago) tried iteration lengths of 1, 2, and 3 weeks. They settled on 2-week
iterations because (for them) it provided the right mix of time spent
planning (iteration kick-off & closure) and time spent developing.

As for your "half done" question, the team tracked their daily effort
(both spent and remaining, by story) compared to time planned (by team
member) for the iteration. This allowed the team (and business) to know
the following day if a story was taking longer (or shorter) than planned,
and we could adjust as needed. And the effort to do the daily tracking
was minutes per team member each day.

Bob Jarvis



------------------------ 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
--------------------------------------------------------------------~->

[Keith Ray]

I'm talking to a manager interested in agile development, but he
doesn't think *fixed*-length iterations are the way to go. He
understood my explanation about yesterday's weather and being able to
predict progress using burn-down / burn-up charts. He was also
concerned that iteration planning might take up too much time in short
iterations.

What are the other bullet points in favor of fixed-length iterations
that might persuade him of its usefulness?


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

[Michael Feathers]

Post by Keith Ray
I'm talking to a manager interested in agile development, but he
doesn't think *fixed*-length iterations are the way to go. He
understood my explanation about yesterday's weather and being able to
predict progress using burn-down / burn-up charts. He was also
concerned that iteration planning might take up too much time in short
iterations.
What are the other bullet points in favor of fixed-length iterations
that might persuade him of its usefulness?

I can't really bullet point these right now. A little groggy this
morning, but to me, the benefit of fixed iterations is that it forces
decision making. If the team is under or over on an iteration, the
customer has to be involved. It is one thing to understand velocity and
scope adjustment, yet another to concretely encounter them over and over
again. The amount of understanding that business people gain through
that feedback is invaluable my opinion.

Michael Feathers





------------------------ 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 Keith Ray
I'm talking to a manager interested in agile development, but he
doesn't think *fixed*-length iterations are the way to go. He
understood my explanation about yesterday's weather and being able to
predict progress using burn-down / burn-up charts. He was also
concerned that iteration planning might take up too much time in short
iterations.

What are his issues with fixed-length?

Ron Jeffries
www.XProgramming.com
The practices are not the knowing: they are a path to the knowing.




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

[Kent Beck]

Ron,

The issue I hear clearly from Keith's posting is the overhead of planning.
That doesn't seem to me to relate to fixed- vs. variable-length iterations,
but that's the manager's concern.

At first, planning for a week's work might take a whole day (20%), but with
practice the team should be able to improve. The common experience of teams
that practice short, fixed-length iterations is that pure planning occupies
an hour or half an hour a week (I'm thinking of the XP Labs teams here).
That works out to 2-3%. Keith, is that level of overhead acceptable to him?

The other advantages of fixed-length iterations:
* Implicit communication. If you have weekly cycles or quarterly
deployments, you don't have to communicate explicitly about dates. If this
is Friday it must be the end of a cycle. Do we have a deployment March 31?
Of course.
* Rhythm. Human being thrive on a combination of predictability and chaos
(with different ratios for different people). Fixed-length iterations
provide a welcome element of predictability in what can otherwise be an
overwhelming chaotic process.
* Encouragement to choose scope. It seems to be very difficult to get used
to varying scope to control projects. The urge to say, "Just do it all and
tell me when you're done," must be very strong or we wouldn't hear it so
often. Fixed-length iterations force scope decisions, encouraging people to
slice and dice their desires so as to get the greatest value now.

That said, there is a lot to be said for variable-length iterations. The
ability to always get a "whole" feature, for example, is very attractive.
The advantages have never outweighed the advantages of fixed-length
iterations in my experience, but it's good to keep both options open.

Keith, is there an experiment you could perform so you understood each
others' positions better? I'm thinking of a paper-airplane folding activity
or origami or something like that.

Kent Beck
Three Rivers Institute

-----Original Message-----
From: Ron Jeffries [mailto:ronjeffries-***@public.gmane.org]
Sent: Saturday, December 18, 2004 6:14 AM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: Re: [xpe2e] Practice: Weekly Cycle

Post by Keith Ray
I'm talking to a manager interested in agile development, but he
doesn't think *fixed*-length iterations are the way to go. He
understood my explanation about yesterday's weather and being able to
predict progress using burn-down / burn-up charts. He was also
concerned that iteration planning might take up too much time in short
iterations.

What are his issues with fixed-length?

Ron Jeffries
www.XProgramming.com
The practices are not the knowing: they are a path to the knowing.






Yahoo! Groups Links










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

[Jeff Nielsen]

I'm sitting here writing a little piece about the benefits of having a team
coding standard. I was quoting something I heard Kent say at a conference
about how "Standardizing on the smallest scale enables flexibility at the
larger scale."

Then I got to wondering why "Coding standard" is no longer a practice in
XP2E. I assume it falls under the umbrella of "Shared Code". But perhaps
there is/was a general sentiment in the community that having a team coding
standard no longer rises to the level of an important practice.

I have found implementing a coding standard to be a very useful first step
in getting a team to start working as a team. While sometimes painful,
having a coding standards discussion encourages people to examine whether
they're willing to change their individual behavior for the good of the
team. Almost no one that I coached has questioned the value of having a
team standard in conjunction with collective code ownership.

So I guess I'm asking for others' experience and thoughts.

Jeff Nielsen
Chief Scientist
Digital Focus (www.digitalfocus.com)



------------------------ 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
--------------------------------------------------------------------~->

[david hussman]

Sometimes I find a communications document / poster helpful.

I have worked with communities to create a "development manifesto" that
contains a combination of how they code as well as the supporting
motivators / values. Contents include coding styles, use of tools and
code libraries, unit testing, exception handling, and more (whatever
they need to discuss).

The team reviews / updates the manifesto during a time boxed discussion
period selected by the community (and monitored by the coach). The only
strong rule for the manifesto is Darwinist - if a section is not being
used, and the team does not support it, out it goes.

I guess it could be called a coding standard document, but I moved away
from the term due the amount of associated baggage. When coaching
coaches, the development manifesto is a nice tool to leave behind.

-----Original Message-----
From: Jeff Nielsen [mailto:jeff.nielsen-***@public.gmane.org]
Sent: Monday, December 20, 2004 4:42 PM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: [xpe2e] What happened to coding standard as a practice?


I'm sitting here writing a little piece about the benefits of having a
team
coding standard. I was quoting something I heard Kent say at a
conference
about how "Standardizing on the smallest scale enables flexibility at
the
larger scale."

Then I got to wondering why "Coding standard" is no longer a practice in

XP2E. I assume it falls under the umbrella of "Shared Code". But
perhaps
there is/was a general sentiment in the community that having a team
coding
standard no longer rises to the level of an important practice.

I have found implementing a coding standard to be a very useful first
step
in getting a team to start working as a team. While sometimes painful,
having a coding standards discussion encourages people to examine
whether
they're willing to change their individual behavior for the good of the
team. Almost no one that I coached has questioned the value of having a

team standard in conjunction with collective code ownership.

So I guess I'm asking for others' experience and thoughts.

Jeff Nielsen
Chief Scientist
Digital Focus (www.digitalfocus.com)





Yahoo! Groups Links









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

[Nigel Thorne]

I don't find official coding standards are required if you are working
with a team of experiences developers. They are an aid to
communication. Most experienced developers write easy to read code.

I'm a fan of just in time coding standards. They are only needed when
people dissagree strongly about how something should look. A that
point if the conflicting people cannot decide (see below), get the
team together, vote, and write the decision on the wiki (with reasons
behind the decision).

A tip I picked up from Steve Hayes was to get the two team members in
conflict to vote 1 - 3 on how strongly they feel about the issue.
Strongest wins. If they can't resolve it then all work is stopped
while a quick issue resolution meeting is held. To stop all issues
escalating to a team meeting get the two conflicting people to also
explain to the team why they couldn't decide this issue between
themselves. This is ususally enough that the person that feels least
strongly about the issue backs down.

cheers
Nigel Thorne
www.nigelthorne.com

On Mon, 20 Dec 2004 17:42:17 -0500, Jeff Nielsen

Post by Jeff Nielsen
I'm sitting here writing a little piece about the benefits of having a team
coding standard. I was quoting something I heard Kent say at a conference
about how "Standardizing on the smallest scale enables flexibility at the
larger scale."
Then I got to wondering why "Coding standard" is no longer a practice in
XP2E. I assume it falls under the umbrella of "Shared Code". But perhaps
there is/was a general sentiment in the community that having a team coding
standard no longer rises to the level of an important practice.
I have found implementing a coding standard to be a very useful first step
in getting a team to start working as a team. While sometimes painful,
having a coding standards discussion encourages people to examine whether
they're willing to change their individual behavior for the good of the
team. Almost no one that I coached has questioned the value of having a
team standard in conjunction with collective code ownership.
So I guess I'm asking for others' experience and thoughts.
Jeff Nielsen
Chief Scientist
Digital Focus (www.digitalfocus.com)
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.

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

[Steve Hayes]

Another tip from Steve Hayes is that if you do develop a coding
standard, everyone on the team should have given up something that they
thought was important. Otherwise it becomes "Person X's" coding
standard, rather than the team's coding standard.

Barry Unsworth (an Australian politician) once observed "it was a great
compromise. Everyone walked away unhappy". If you can't make everyone
happy (and I've never found a coding standard that did), it not the
worst possible alternative.

Also, in the spirit of full disclosure, I picked up the 1-3 idea from
the guys at RoleModel (who probably picked it up from someone else).

Steve

Post by Nigel Thorne
I don't find official coding standards are required if you are working
with a team of experiences developers. They are an aid to
communication. Most experienced developers write easy to read code.
I'm a fan of just in time coding standards. They are only needed when
people dissagree strongly about how something should look. A that
point if the conflicting people cannot decide (see below), get the
team together, vote, and write the decision on the wiki (with reasons
behind the decision).
A tip I picked up from Steve Hayes was to get the two team members in
conflict to vote 1 - 3 on how strongly they feel about the issue.
Strongest wins. If they can't resolve it then all work is stopped
while a quick issue resolution meeting is held. To stop all issues
escalating to a team meeting get the two conflicting people to also
explain to the team why they couldn't decide this issue between
themselves. This is ususally enough that the person that feels least
strongly about the issue backs down.
cheers
Nigel Thorne
www.nigelthorne.com
On Mon, 20 Dec 2004 17:42:17 -0500, Jeff Nielsen

Post by Jeff Nielsen
I'm sitting here writing a little piece about the benefits of having

a team

Post by Jeff Nielsen
coding standard. I was quoting something I heard Kent say at a

conference

Post by Jeff Nielsen
about how "Standardizing on the smallest scale enables flexibility

at the

Post by Jeff Nielsen
larger scale."
Then I got to wondering why "Coding standard" is no longer a

practice in

Post by Jeff Nielsen
XP2E. I assume it falls under the umbrella of "Shared Code". But

perhaps

Post by Jeff Nielsen
there is/was a general sentiment in the community that having a team

coding

Post by Jeff Nielsen
standard no longer rises to the level of an important practice.
I have found implementing a coding standard to be a very useful

first step

Post by Jeff Nielsen
in getting a team to start working as a team. While sometimes painful,
having a coding standards discussion encourages people to examine

whether

Post by Jeff Nielsen
they're willing to change their individual behavior for the good of the
team. Almost no one that I coached has questioned the value of

having a

Post by Jeff Nielsen
team standard in conjunction with collective code ownership.
So I guess I'm asking for others' experience and thoughts.
Jeff Nielsen
Chief Scientist
Digital Focus (www.digitalfocus.com)
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.

*Yahoo! Groups Sponsor*
ADVERTISEMENT
click here
<http://us.ard.yahoo.com/SIG=129nrd8s6/M=298184.5639630.6699735.3001176/D=groups/S=1705007207:HM/EXP=1103684893/A=2434971/R=0/SIG=11eeoolb0/*http://www.netflix.com/Default?mqso=60185400>
------------------------------------------------------------------------
*Yahoo! Groups Links*
http://groups.yahoo.com/group/xpbookdiscussiongroup/
* Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service <http://docs.yahoo.com/info/terms/>.

------------------------ 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]

On Mon, 20 Dec 2004 17:42:17 -0500, Jeff Nielsen

Post by Jeff Nielsen
But perhaps
there is/was a general sentiment in the community that having a team coding
standard no longer rises to the level of an important practice.

I wouldn't say it's not important, but to me it always seemed like the
practice to vote "most likely to emerge, given the other practices".
(I had the same reaction with respect to "configuration management"
and XP1E - XP teams usually (always?) do it, but it's not called out
directly; it's sort of a consequence of continuous integration, etc.)

[William Wake]

On Mon, 20 Dec 2004 17:42:17 -0500, Jeff Nielsen

Post by Jeff Nielsen
But perhaps
there is/was a general sentiment in the community that having a team coding
standard no longer rises to the level of an important practice.

I wouldn't say it's not important, but to me it always seemed like the
practice to vote "most likely to emerge, given the other practices".
(I had the same reaction with respect to "configuration management"
and XP1E - XP teams usually (always?) do it, but it's not called out
directly; it's sort of a consequence of continuous integration, etc.)

[Michael Feathers]

Yes, but that might not be the message that people receive given that
you mention 1-4 week cycles in the first edition and 1 week cycles have
become the practice in the second.

I agree that the week is a natural time scale, and that that is a
principle in support of weekly cycles, but what I question is why there
must be principled position on weekly or biweekly cycles at all. Why
isn't it enough to say that XP favors the shortest cycle that allows
meaningful work to be done, gives business sufficient steering and
developers sufficient buffer?

Putting aside any technical issues that affect how much meaningful work
can be done on particular projects, time-period is something that seems
amazingly dependent on team-culture and expectations. Some people don't
mind being essentially in work queue mode, each day a new iteration.
Other people feel that iterations as short as a week feel martial. If
the bottleneck shifts out of software, sometimes you can address it and
help an organization take advantage of 1 week cycles. If you can't,
squeezing the cycle time beyond the comfort level of the customers and
developers seems like an unneeded optimization. It's great to help them
know what they are capable of, but if people aren't comfortable with it,
then why?

Why can go back to principles, but what about empiricism? Some teams
have settled on cycles larger than a week. If they are comfortable with
them and there is no pressing business problem, then why not?

Michael Feathers

Post by Kent Beck
I didn't hear anyone say that one size should fit all. I cited one
principle
in support of one-week cycles. I'm sure there are other principles in
support of two-week cycles. I'm interested in hearing them, not in
strawman
arguments.
Kent Beck
Three Rivers Institute
-----Original Message-----
Sent: Wednesday, December 15, 2004 5:33 PM
Subject: Re: [xpe2e] Practice: Weekly Cycle
Seriously, I don't know what the best cycle time is, but my observation
is that one size really can't fit all.

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

[Dave Hoover]

Post by Michael Feathers
I agree that the week is a natural time scale, and that that is a
principle in support of weekly cycles, but what I question is why there
must be principled position on weekly or biweekly cycles at all. Why
isn't it enough to say that XP favors the shortest cycle that allows
meaningful work to be done, gives business sufficient steering and
developers sufficient buffer?

I'm coming into this discussion late, but I feel compelled to bring up
a point. The Weekly Cycle is a practice, not a principle. One week
is the shortest possible iteration length that works, therefore it is
extreme. Practices should do more than just favor something, they
should provide explicit instructions for practitioners to follow.

As Kent says in the book (can't find the quote right now), let the
values and principles inform your practices in your context. In some
contexts, a Weekly Cycle doesn't fit. Does anyone disagree?

--Dave


------------------------ 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 Pietri]

Post by Michael Feathers
Why
isn't it enough to say that XP favors the shortest cycle that allows
meaningful work to be done, gives business sufficient steering and
developers sufficient buffer?

I agree completely with your point, Michael, that people should find
their own rhythm. But for a lot of people, especially a few years ago,
if you told them to find the shortest cycle that allows meaningful work
to be done, they'd say, "You mean as fast as quarterly?"

I haven't yet done more than peek in XP2E, so I don't know what Kent
might have intended this time around. But certainly the previous edition
challenged a lot of people to move beyond what they thought was
possible, and I'd hope that this retained some of that flavor.

William
--
William Pietri <william-***@public.gmane.org>



------------------------ 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
--------------------------------------------------------------------~->

[Kent Beck]

As always, the practices are stated as absolutes but they are intended to
help teams generate ideas for improvement. If a team is comfortable with a
two-week cycle and there is no pressing business problem, then I can't think
of a reason to change. However, aligning the planning cycle with the cycle
in the rest of life has advantages. If that same team later finds that they
need a stronger rhythm, I encourage them to consider a one-week cycle.

This is the same philosophy, expressing directions for improvement by
identifying their "extreme" form, that was in place for half a dozen
practices covered already in this mailing list and for the five years before
that since the publication of XPE1. Why is it suddenly important to express
general preferences (as short as you guys are comfortable with) instead of
absolutes? That's the part of your post I really don't understand.

Kent Beck
Three Rivers Institute

-----Original Message-----
From: Michael Feathers [mailto:mfeathers-***@public.gmane.org]
Sent: Tuesday, December 21, 2004 6:24 PM
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: Re: [xpe2e] Practice: Weekly Cycle



Yes, but that might not be the message that people receive given that
you mention 1-4 week cycles in the first edition and 1 week cycles have
become the practice in the second.

I agree that the week is a natural time scale, and that that is a
principle in support of weekly cycles, but what I question is why there
must be principled position on weekly or biweekly cycles at all. Why
isn't it enough to say that XP favors the shortest cycle that allows
meaningful work to be done, gives business sufficient steering and
developers sufficient buffer?

Putting aside any technical issues that affect how much meaningful work
can be done on particular projects, time-period is something that seems
amazingly dependent on team-culture and expectations. Some people don't
mind being essentially in work queue mode, each day a new iteration.
Other people feel that iterations as short as a week feel martial. If
the bottleneck shifts out of software, sometimes you can address it and
help an organization take advantage of 1 week cycles. If you can't,
squeezing the cycle time beyond the comfort level of the customers and
developers seems like an unneeded optimization. It's great to help them
know what they are capable of, but if people aren't comfortable with it,
then why?

Why can go back to principles, but what about empiricism? Some teams
have settled on cycles larger than a week. If they are comfortable with
them and there is no pressing business problem, then why not?

Michael Feathers

Post by Kent Beck
I didn't hear anyone say that one size should fit all. I cited one
principle
in support of one-week cycles. I'm sure there are other principles in
support of two-week cycles. I'm interested in hearing them, not in
strawman
arguments.
Kent Beck
Three Rivers Institute
-----Original Message-----
Sent: Wednesday, December 15, 2004 5:33 PM
Subject: Re: [xpe2e] Practice: Weekly Cycle
Seriously, I don't know what the best cycle time is, but my observation
is that one size really can't fit all.

Yahoo! Groups Links










------------------------ 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 Kent Beck
This is the same philosophy, expressing directions for improvement by
identifying their "extreme" form, that was in place for half a dozen
practices covered already in this mailing list and for the five years before
that since the publication of XPE1. Why is it suddenly important to express
general preferences (as short as you guys are comfortable with) instead of
absolutes? That's the part of your post I really don't understand.

Well, when we say "test everything that could possibly break," or
"write no code without a failing test," it quickly becomes clear
that that instruction is a pointer in a direction, not an absolute.

"Work in one-week cycles" may seem to some not to have that same
property of pointing to an unattainable ideal. It might sound more
like a specific goal.

In addition, it may not be clear to some of the folks here that one
week really is better than two, even as a goal. Or that one day or
one hour might not be better still.

Ron Jeffries
www.XProgramming.com
Comments lie. Code doesn't.




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

[William Wake]

Post by Kent Beck
As always, the practices are stated as absolutes but they are intended to
help teams generate ideas for improvement. [...]
This is the same philosophy, expressing directions for improvement by
identifying their "extreme" form, that was in place for half a dozen
practices covered already in this mailing list and for the five years before
that since the publication of XPE1. Why is it suddenly important to express
general preferences (as short as you guys are comfortable with) instead of
absolutes?

Not to generalize my situation to others, but I know one aspect for me
is that there are places where I was comfortably "in the zone"
described in XPE1E (1-3 week iterations, 1-3 month releases,
"continuous integration", etc) but I'm not in the zone described in
XPE2E.

Then I have an emotional side that roots for the practices I already
do, is willing to listen on the ones I'm close ("we *can* get all
tests down to 10 minutes"), and is skeptical about the ones where I'm
not so close ("daily deployment probably isn't the heart of XP":). I
have to untangle that emotional side from the actual arguments for or
against.

It definitely shows me the "gut reaction" involved in things like
"Pretty Extreme Programming." (You get a great label, and you only
have to "adopt" the parts you already do:)

[Ron Jeffries]

Post by William Wake
It definitely shows me the "gut reaction" involved in things like
"Pretty Extreme Programming." (You get a great label, and you only
have to "adopt" the parts you already do:)

Really good point, worth reflecting upon.

Ron Jeffries
www.XProgramming.com
I'm not bad, I'm just drawn that way. -- Jessica Rabbit




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