This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
The importance of rhythm
Stepping away from the Rigidity in Agile Development meme for a minute. I’d like to talk about the importance of a true rhythm. Lately, I’ve met with various teams that have struggled with how to define their iteration length. Some will decide how long an iteration will be based on the amount of work they are being asked to do. Others will base their iteration length on a calendar goal – “we need to be done by spring break, so lets make this a 3 week iteration. Then we can do a 2 week after spring break.” Some folks are now looking at continuous flow, instead of breaking things into iterations at all. I’d like to take a story from history that, I think, illustrates the value of a rhythm, or cadence. Sometimes it is interesting to look at other sources, then apply those lessons to our Agile development projects…so let’s get into our way-back machines and set them to 1948…
The war has been over in Europe for 3 years. Most of Europe is getting back to business, except for Berlin. The Western Allies are at odds with the Soviet Union as to control of the city. Agreements were made that the 4 major powers would jointly share the city, but soon a rift forms between East and West Berlin. In an attempt to starve the West Berliners into unifying under the communist banner, the Soviet Union blocks all road and rail traffic into the city. The western allies decide to supply Berlin by air, which is an unheard of feat, requiring hundreds of flights around the clock, never ending.
At first, the Berlin Airlift was doing OK, planes landing every couple of minutes and food getting delivered. Then, as all project managers know, something happened. In this case, it was the winter weather over Berlin, which is notoriously bad. One plane couldn’t land due to weather, so it went into a holding pattern. This meant each and every other plane had to go into a holding pattern behind it, until the skies above Berlin became so crowded with deliveries that had been delayed, the planes were literally running into each other.
So along came a crotchety old General who decided enough was enough. He declared that all planes were assigned a place in a cadence. If for any reason your plane can’t land when and where it is supposed to, go back to your home base. Don’t wait around, just go back. This established a heart beat that kept beating until the blockade was lifted. The cadence became the key. One plane not being able to land and deliver its cargo was surely a loss, but the amount of materiel that kept getting delivered over the course of the weeks was much higher, as nobody else was waiting on the tarmac to deliver their goods.
So what does this highly abbreviated version of history mean to us in the world of Agile software development? I see two worthwhile lessons: One, if you have a story that is blocking the progress of the entire iteration, or even threatening to do so, it might be worth considering letting it “go back to the airport” so you can focus on the larger delivery stream. And don’t lose a lot of sleep over the fact that this story got missed in this go-around. Once we get a chance to go fix whatever was broken, we can get this story back into the flight plan. The second lesson is the importance of a rhythm. Whether you are doing Lean software development, Extreme Programming, Scrum, or just Agile on the fly, keep a focus on a predictable rhythm. The level of comfort that comes from knowing we will keep delivering something of value every 2 weeks (or one week, or 3 weeks) is an amazing value to the team and to the stakeholders.