I like 1-week iterations because they focus the mind and the effort. They're not for the faint hearted, however. They do have a downside, as Mishkin Berteig points out in his post about The Pros and Cons of Short Iterations. Here's some advice on how to avoid or at least minimise the affect of the cons:
1. Intensity of work can lead to burnout
Use the Extreme Programming practice of energized work. Work only for those hours where you are genuinely productive. Manage the time you spend at work carefully and protect your flow time. When programming, come up for air regularly. Take breaks often to refresh your brain and your senses. Work as many hours as you can sustain without a detrimental affect on the quality of your work, your health, and of course your personal life outside work. Burning yourself out today and spoiling the next two days of work isn't good for you or the team. It's important to retain a sensible perspective and find the right balance between work and play.
2. Strategic thinking can be hard to fit into the schedule
Strategic thinking can occur at many levels. The challenge is to do just enough strategic thinking from one opportunity for inspection and adaptation to the next.
If there must be regular strategy meetings with other stakeholders then the team's velocity should accommodate these. I prefer to avoid these meetings if at all possible. Instead strategic thinking should be part of the normal routine. I like doing monthly releases (even if they don't go into production) because they provide a release planning meeting every 4 weeks. This is an ideal forum in which to review the strategic roadmap and adjust it if necessary. When there's some strategic thinking to be done that's pertinent to an iteration, it can either occur during the iteration planning meeting, if it has possible consequences for the planning, or it can be done around a whiteboard following the iteration planning meeting. If someone deems a strategic issue to be worth discussing, any developer, or the customer, is free to start a whiteboard session at any time.
When coding you don't want to look too far into the future because, maybe, YAGNI. You should rely on the developers abilities to refactor to evolve a suitable architecture and accommodate change. Pair programming enables the person not driving the keyboard to think strategically about the coding goal - Can this method be avoided? What are the implications of this approach? Are there simpler approaches? We'll need to refactor so-and-so too - while the person typing is concerned with tactical issues writing the code.
3. Overhead tasks that must be done every iteration take a larger proportion of the time in the iteration
The durations of the iteration planning meeting, review and retrospective should be proportional to the iteration's duration, so they should consume no additional time. Overhead tasks, e.g. extra processes, task switching, waiting around, any motion such as chasing the customer, should be considered waste and should be eliminated.
Any other overhead tasks should be minimised. Invest in continuous integration and a 10-minute build. In my last project, we continually optimised our automated build process. In one iteration we refactored the build to use Maven 2 so that we could use profiles on the command line. These allowed us to deploy easily to different server environments. We also configured Cruisecontrol with new projects, one for each server environment.These projects were programmed to fire at certain times, e.g. an overnight build would be automatically deployed onto the DEV environment, and at a certain hour every Friday (i.e. at the end of the iteration) the checked-in code would be automatically deployed to the UAT environment.
4. Waiting for resources or people outside of the team can make it more likely for work to span iterations
The customer should be collocated with the development team. If other stakeholders are heavily involved, collocate them too. Beyond this, it comes down to aligning resources, coordinating efforts, and managing the risks of external dependencies.
Plan with appropriate buffering when you have an external dependency. If the external party is delivering code, and they're not doing iterative and incremental development, you want to initiate their work so that delivery correlates with your release plan. When I deal with external dependencies I make a point of over-communicating. I set time-boxes for everything and insist that the external party does the same. I treat them as I would an opponent in tennis - I keep the ball in their court at all times. Everytime they ask a question or provide something, I get the answer to them or give feedback as quickly as possible. The worst thing you can do is keep an external party waiting.
As stated previously, waiting around or chasing around is a waste and should be eliminated. Ask yourself: Can you bring the code in-house and remove that external dependency? Are you empowered to make decisions on behalf of that absent or difficult to get hold of stakeholder?
Previous Topic
