How To Think Short

Decrease the space between your predictions and reality. The best strategy for
doing this is to keep your iterations short.
Early last year, Ward Cunningham visited us to see how we were using XP at
one of our clients. While he was here, Ward paired with several members of the
team. One person recalled how amazed he was at the very small steps Ward took
when he was coding. But they worked. He had almost constant feedback. Iterations
are that principle writ large.
In general, the shorter your iterations, the more focused you will be. Make your
iterations long enough to do something that matters to your customer, but short
enough to avoid a crash. This could be a week in a highly productive environment
with highly productive developers on a small project. The more you stray from that
model, the longer your iterations should be. Two or three weeks is, closer to two, is
what Beck and Fowler suggest. We use four right now on at our largest client, but
we're looking to shorten that.
Once you get into habit of running these small iterations, get into the habit of
releasing early and often. This is uncomfortable for lots of customers. They don't
want to release something until it's "done". Emphasize the fact that doing this
ensures that the system will be done wrong. Focus on producing the most valuable
stories first, so that each release, not matter how small, does something that the
customer values most at that point in the project. Then see if users agree.
What happens if users don't like what you released? That is a good thing if you
are releasing early and often, because you still have time to do something about it. If
you wait until the end of the project to have your grand unveiling, you have only one
chance to give the users exactly what they want.
How To Start Thinking Short
There is no way to start working in an iterative way gradually. Try it out. Grab
two weeks worth of stuff from the stack of stories you came up with in your first
planning session and attack them. Set a hard deadline two weeks away and refuse to
compromise on it. Then work for two weeks.
When your deadline comes, stop. Take stock of what you got done and what you
didn't. Ask yourself some questions:

 How were our estimates? Were they consistently high or low?

 Did we assume we could move faster than we really could?

sure you fold in the lessons you learned. Pretty soon, this will become a habit.
You'll start thinking in iteration-sized chunks of time.
The same goes for releases. According to Kent Beck, if you are doing the other
essentials, this should get much easier1:

 If you're planning, you are the working on the most valuable stories at
any point, so even a small system has high value.

 If you're integrating continuously (more on this in Chapter 16),
packaging a release at any point is easy.

 If you're testing like mad (more on this in Chapter 13), you don't have
to go through a lengthy test phase before you ship.

 If your design is as simple as it can be all the time, it will be sufficient
for the next incremental release.
The biggest barriers to releasing early and often are developers who don't want
to release something before it's "done" and customers who don't want users not to
be impressed. Waiting a long time to release doesn't fix the problem, because you
probably will produce something users aren't happy with anyway.
Think of small releases like an evolving prototype. The more revs you have, the
closer your prototype can get to the reality you're targeting. It is the best way to
reduce the risk of guessing wrong about user requirements.
What If Business & Development Have Different
Ideas of "Short"
We've found that developers are more prone to lose focus if the iterations are
longer than 3 weeks. We've also found that, for many customers, having a planning
session more than every 4 weeks can be counterproductive, and micromanagement
tendencies kick in.
At one client, we addressed this by dividing our four-week iterations into "halfiterations".
We decide which half of the tasks need to be done first and focus on
getting them done in the first two weeks. We have a natural checkpoint to make
adjustments on what our tasks are and our confidence of our estimates. The "time
pressure" is just enough so that we don't get tempted to go down rabbit trails
thinking we have enough time to get back on track later in the iteration.