Some of our subscriber inquiries have to do with accelerating their website and CMS deployment times.  Having been burnt by waterfall-oriented development methodologies in the past, enterprises are now looking to "agile" development for answers. But already, many are becoming equally disillusioned with agile. Is it really just as problematic as waterfall?

I'd say it's perfectly feasible to be more agile in your web development. The process itself shouldn't be a problem. The cross-organizational change required to put the process in place is much more of an issue. Yet, 9 out of 10 companies I've talked to the past few years seem to get stuck in first gear.

So get past the scrum and back into play: start with getting the basics right.  Here are some ideas.

Remember you're developing websites, not software
Often, the process works like this.  A concept of a site will get specified. The specification will then be handed over to developers. They will work to turn it into a functioning CMS implementation and front-end website, using agile methods. There's a watershed between marketing/communications departments and IT -- and it's reinforced by agile methods themselves. (See for instance the Chicken and the Pig analogy.)

This is doomed to fail, because agile is not meant for completing 100% of a set specification at a specific deadline date. And even if the developers would succeed, the goals of the project will have shifted and moved on by the time they're done. Because you're aiming at a moving target -- that's the nature of the web.

Instead, think about this as web development. That may sound obvious, but it really means that every stage, from concept to UX and IA, from content strategy, to graphical design, to software customization and templating, should be part of the agile process. Not just the software development bit. You can't just drop an idea and move on: everyone needs to be actively involved in the ongoing agile process, but most notably the business team. Remember: watersheds tend to lead to waterfalls.

Agile is not an excuse for not knowing what you need
Problems get exacerbated if the original concept is too vague. That'll lead to dissatisfaction if you're using waterfall methods -- but agile will only serve to amplify the effect. If you keep changing your mind, then asking developers to change their plans to suit you, you're just leading them on a wild goose chase. The project will never be finished.

Yes, your website should be in constant evolution to keep up with a rapidly changing reality. But you still need a clear plan. Conceptualize and develop what you can chew off in the short term -- and let that be part of an iterative agile process. But also keep a sense of direction for the longer term. You don't have to know where you'll be in five years, but you do have to know whether you want to turn left or right at the next crossing. Otherwise, you'll just wander aimlessly, chasing an elusive mirage.

There's a time and a place for waterfall and agile
You can't just throw a switch and start being agile. You need the technical and organizational infrastructure first. Take the time to do this thoroughly. Don't jump in the water right away. You might drown before you figure out how to be agile enough to swim.

If you're starting an overhaul of your organization, the CMS, and the website, get a thorough foundation in place. A friend of mine claims the Tower of Pisa was built using agile methods from day one -- which is why the building itself looks nice enough, but it's rather noticeably lopsided. Foundations need thorough specification and execution, because no matter how agile your fixes afterward, they'll always be crooked.

Finally, and I've said this a couple of times before: a website isn't like a book that's finished and sent of to the printers. You're never done with it. Agile methods suit this constant evolution very well. But getting into a constant flow is far from easy; don't underestimate the expertise and time you'll need. We can help you with expertise -- but don't expect miraculous quick fixes.