Rachel Lovinger started a great thread at the Content Strategy Google Group about agile development. It really hit home with me because I’ve had clients who use both traditional and agile development. From a content strategy perspective, both have their benefits — and downsides.
Best about waterfall:
- Typically has a well-defined process, and if you get in on the front end, it’s easy to define over-arching business goals
- Everyone’s role is clear
Best about agile:
- Fast, fast, fast!
- Favors user stories, which suss out business goals
You cannot create effective content strategy without knowing your business goals.
Waterfall done poorly exacerbates the human tendency toward bureaucracy, both in the development process and in the long-term operational strategy. Agile done poorly swings from insignificant goal to unimportant goal, making little things happen that actually make no difference. So either has the potential to make your website/software product ineffective.
Done well, agile suits me better. I think we all like to feel progress, and agile delivers progress regularly. But when you dive into agile without the big goals written on the wall, you run the risk of doing stuff because you can, not because you should. And while you can create content for any particular goal, if you don’t know the big goal, you don’t know how to craft taxonomy or style and tone, never mind how to create page flows that deliver useful information to your customers, and deliver on your business needs.
Whatever style development you’re using, you have to start with the business goals, and you need content strategy at the table from day one.