Even before I discovered the benefits of using an agile software development process, I used an iterative process. Throughout the early and mid–1990s the process I used was a hybrid of Barry Boehm’s risk–based spiral model, Tom Gilb’s evolutionary delivery, and Scrum. While most of my projects from that period were quite successful, I certainly made plenty of mistakes. One of the mistakes I made was not establishing a rhythm on those projects.
Even though I was using an iterative and incremental process, and one we’d call agile today, I allowed the project’s iteration lengths to vary. I was rigid about keeping the iteration within whatever timebox had been established for it but I would sometimes do a two–week iteration followed by a six–week iteration followed by a four–week iteration. When planning a new iteration, the team would get together and discuss the work we wanted to accomplish. If that work was something that looked large, we’d plan a six–week iteration. If it looked small, we’d plan a two week one.
This worked well enough but after about three years of having flexible iteration lengths I worked with a team that happened to run a handful of four–week iterations in a row. I learned something interesting that has since been part of how I’ve managed all subsequent projects: the established rhythm of a fixed iteration length is very beneficial to the team and its stakeholders.“Even if you don’t schedule iteration reviews well in advance, the regularity of the iterations is noticed by all involved parties.”
The rhythm acts like a heartbeat or drumbeat for the project. Every four weeks (or two, or whatever a team chooses) everyone knows the team will complete some increment of new functionality. Delivering on a regular basis becomes a valuable habit for the team. Because the team selects the amount of work they will do in each short, regular iteration, they know they will meet each deadline. Their planning is simplified because each iteration is the same length. The team knows that they can plan for about the same amount of work in the coming iteration as they completed in the iteration just finished.
The regularity of fixed iteration lengths is a similar benefit to the project’s stakeholders. They don’t have to wonder or remember when the next iteration ends; each iteration ends a known number of days after the end of the prior iteration. This allows the team to schedule end of iteration reviews well in advance. In many organizations, this is necessary if you want the participation of key stakeholders, executives, or managers.
Even if you don’t schedule iteration reviews well in advance, the regularity of the iterations is noticed by all involved parties. Over time they become used to it and will start to have thoughts such as “It seems like about time for another release by the Napa team; I should check in with them.”
Another benefit to consistent iteration lengths is how it smoothes the level of intensity over the entire duration of the project. If you were to graph the intensity of a typical project over a twelve–month release cycle, it would start low during the analysis phase and rise steadily through the release date. An unknowing stranger could walk into the project team’s workspace and get a feel for where they are in the release cycle. In the first few months there is less intensity and lunches may be longer. In the last month or two, piles of pizza boxes and empty soda cans will be evident and the team will be tired from working late nights and weekends. A well–run iterative project will not feel this same way. Yes, there will be more stress in the air during the fourth and final week of an iteration than during the first week. But, the variation will be far less than on a waterfall–style project with a year–long release cycle.
Over the past few years, I’ve built on the idea of having a regular rhythm or heartbeat to the project. What I’ve found works best is a pattern of three nested rhythms. At the smallest level is a daily rhythm, which is established through a short, 15–minute daily standing meeting. Surrounding this is the rhythm of the iteration, typically lasting two or four weeks, depending on the team’s preference and the needs of the organization. Finally, I surround a quarter’s worth of iterations with an extra, one–week iteration which follows one slightly different rule: During the regular iterations, the business directs the priorities; during the one–week last iteration, the team sets their own priorities. Most teams will use this time to experiment with new technologies, pay down technical debt, or otherwise improve the guts of their project. The mental break from constantly having a delivery due to the organization also helps keep them mentally refreshed. An additional benefit of this 13–week super–cycle is that it keeps the team more approximately aligned with the organization’s quarters, which facilitates some medium to long–term planning.
If you’re already working iteratively but not using consistent iteration lengths, try standardizing the length and see if you get the benefits of that regular heartbeat. If you’ve already standardized, consider wrapping a sequence of those iterations within a larger quarterly cycle.
