Re: Practice: Weekly Cycle

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-ihVZJaRskl1bRRN4PJnoQQ@xxxxxxxxxxxxxxxx>
To: <xpbookdiscussiongroup-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx>
Sent: Wednesday, December 15, 2004 6:04 PM
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-mn4gwa5WIIQysxA8WJXlww@xxxxxxxxxxxxxxxx 
> [mailto:mfeathers-mn4gwa5WIIQysxA8WJXlww@xxxxxxxxxxxxxxxx]
> Sent: Wednesday, November 24, 2004 8:23 PM
> To: xpbookdiscussiongroup-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx;
> xpbookdiscussiongroup-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx
> Subject: Re: [xpe2e] Practice: Weekly Cycle
>
>
>
>
> -----Original Message-----
> From: William Wake <william.wake-Re5JQEeQqe8AvxtiuMwx3w@xxxxxxxxxxxxxxxx>
>
> 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 --------------------~--> 
$4.98 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/Q7_YsB/neXJAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~->