... I placed limits on the scope and schedule of our software releases. Until this point, my team and the NIH had boasted about their ability to release new software daily, claiming that this release rate reflected their flexibility and agility. I was convinced – and was later proved correct – that this daily rate was symptomatic of the lack of process control.

To my mind, software goes from a development build, to a milestone build and finally to a release build.

Each of those stages needs more rigorous QA than the previous level. I can imagine a team that would produce a development build every day. I can't imagine a milestone build every day, and a full release, every day, is ridiculous.

For me, agile development means that you can get a framework of the application up in a few days or weeks, and that bugs can be fixed and new features can be added fairly easily. It doesn't mean daily releases.

The only exception to this that I can imagine is if you have some kind of rolling development going on, where teams leapfrog each other, and the releases are from alternating teams. I'm not sure that's practical in the field of software development.

This sounds like some CIO's 'idea' of what agile is -- someone who hasn't done actual development in 5-10 years, or maybe has never done software development, but 'knows' what the right approach is.