I was helping one of my clients, a project manager for a major Canadian bank, compile a list of risks for an Agile project.

"What about the risk of delivering late?" he asked. "Surely that can happen with Agile too?"

"Yes," I answered. "Agile is certainly configured to have you ship on time (if that time is realistic), but if you're not careful, you will be late."

Back in Waterfall, the ship date was sacrosanct. Everybody knew it. We used Change Management to avoid slipping the date and Critical Chain to understand our bottlenecks. Development had “seasons”: requirements definition, a concentrated period of design meetings, months of coding, and a death march.

Agile methods, despite retaining the concept of releases, are much more relaxed. Generally speaking, you draw a line through the product backlog indicating the product increment you plan to ship in a couple of months, and you evolve it in iterations (sprints). You might require a "readying" iteration just before delivering to the customer: finalize user-facing documentation, marketing materials, packaging, support training, perhaps some data readying. You work at a Sustainable Pace, iteration by iteration.

The thing is, many companies who switched to Agile have discovered that many a project's "end" is really artificial. The important thing is to deliver something valuable when it can still be used.

Well-performing Agile teams attain a certain cadence. Their customers provide a smooth flow of value definition, and the teams provide a smooth flow of value delivery. Their engineering practices and tooling allow them to ship anytime.

And so, some fall into the trap of shipping very little! The pressure to release something is off, the customer is generally happy because developed value is frequently demonstrated, and users might not make ready use of that value... So the teams just work from iteration to iteration, not really bothering to define release dates, and they ship when they feel it's a good time to do so. After all, why "punctuate" the cycle, if there's always more work anyway?

For some, that's a perfectly workable, low-stress approach. But more often than not, I've seen it become a risk. Inevitably, the amount of "readying" work grows with more undeployed software. It's a political risk, because the absence of more frequent releases is interpreted as weakness or laziness. And because teams are ready to just pull more and more work from the backlog, they might well take on work that the organization could do without, which is simply waste.

While flow, cadence and iterative development are certainly desirable qualities of high performance, I think it is good to be diligent about maintaining releases. Don't just drink from the backlog firehose. Make sure you also reintroduce the release "punctuation" into the stream:

• Charter each release
• Plan for a release, not just a sequence of iterations
• Work towards your release criteria
• Actually deploy when you're done
• Hold a release retrospective

... and let me know how this works for you!