We're going to try something on a project we're kicking off here at work: "Agile" programming methodologies in the service of sticky business problems. We're not coders, but we're going to apply what we understand of the approach. We'll use "stories" to get our focus on the problems we need to crack for the marketers we work with, the stories we want to be able to tell when we've solved them. We'll have a list of these stories and work through them one at a time. We'll do that in quick (2 weeks), focused efforts (aka "sprints"). And, we'll if we don't get it right, we'll iterate through them again until we've got it right. We'll be focusing on "shipping", that is getting the project done and implemented. We'll focus less on the beauty of a comprehensive, centrally controlled process (ie. "waterfall), and more on getting working "software" (ie the tools and methods) into the hands of the teams we work with. Lastly, we're going to try to dramatically improve communication via "huddles" and may even try full team huddles to communicate with a much larger audience. The IT group will probably laugh at how we're doing it, but we're going to take a shot and get it right over time if the first efforts aren't spot on. 

Any suggestions on how to apply agile programming methods to a non-programming problem? 

Updated: 8:30 PM

Lots of good suggestions from folks around the web. For sure, check out Rohn J Millers post on the subject from last year. Lot's of good ideas in there. And, here's a pretty good overview from PJ Shrivasta. Finally, i look forward to re-reading Greg Meyers Agile Marketing Manifesto in a couple months to see how we're doing.