RE: Practice: Weekly Cycle

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-mn4gwa5WIIQysxA8WJXlww@xxxxxxxxxxxxxxxx] 
Sent: Tuesday, December 21, 2004 6:24 PM
To: xpbookdiscussiongroup-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx
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    

Kent Beck wrote:

> 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-mn4gwa5WIIQysxA8WJXlww@xxxxxxxxxxxxxxxx]
> Sent: Wednesday, December 15, 2004 5:33 PM
> To: xpbookdiscussiongroup-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx
> 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
--------------------------------------------------------------------~->