Long IT rule 2: Take walk breaks.

As I've said before, for most people, the marathon is the longest "short" race. Short races are races where seconds count. Where you pace yourself as best you can the whole way, with maybe a little kick at the end. Most people do fade just a bit after 2 and a half hours so, unless you're a pretty fast marathoner, you probably start to move into ultra mode at the end. But, even for the 4-hour crowd, a marathon is still best "run", meaning you push through the whole thing taking only the briefest respite at aid stations.

Ultras are a whole 'nuther thing.

Even the elites find it faster to take walk breaks. Not long breaks, mind you, but definite, conscious beaks. This is also true for IT projects that last longer than six months. A breather is in order. Take some time to recover, gather your thoughts, and then push on.

Unplanned walk breaks can be the beginning of the end: an admission that you've bitten off too much and simply can't stay on plan. This is often followed by long stops at aid stations and ultimately, the dreaded DNF (Did Not Finish). That's obviously not a good thing. In contrast, planned walk breaks are the little pickups that keep a a runner focused on the task and ready to push forward.

Taking walk breaks early in the race allow you to consciously accept that this task is too much to be taken all at once while still believing that it is doable.  Planned walk breaks allow one to assess the pace and make adjustments before going too deep in the hole.

Pulling off a successful walk break in an IT project is no small feat. As with top runners, good developers rarely admit to their own limitations. It's essential for the project manager to slide them in with finesse. Rather than an admission of weakness, they have to be presented as opportunities to reassess progress and make adjustments.I've found that every 2 months is a good time to take a small breather and shore things up.

My current team uses 3-week iterations for delivery. If we are working on a bunch of user stories that lead to a single release more than 3 months in advance, I try to plan every fourth iteration as "light". I'll add some "fluff" stories to the iteration like "Reconcile test results with users" or something similarly vague, which give the developers a chance to think about what they have done rather than what they still have to do.

As we'll see next, it's extremely important that these be walk breaks and not vacations. Forward progress is everything. Even light iterations should have tangible results.