Can Agile Work For Content?

Go to article

Elizabeth S. Bennett   September 20, 2011

Not your average content high wire act. (image courtesty of Mark Setchell)

The Breakdown: Liz Bennett and Rachel Lovinger give us a first-hand report from the front line of where content strategy meets the agile process.  What works? What doesn’t? Read on and decide for yourself. >>

Agile.

Content.

Sigh.

Do not mistake this sigh for a condemnation of the Agile approach to project management. Rather, it is a physical manifestation of the emotional peaks and valleys we find ourselves scaling during two separate web development projects for which we are leading the content and editorial strategy.

Some context: Rachel’s task is to rework how content is organized and written on a content-heavy site. She’s working with some existing content and the business will be responsible for filling in the gaps. The site will be completely redesigned and use a new publishing platform. Sprints are two weeks in duration.

Similarly, Liz’s project involves a design overhaul of a corporate website that will launch with content that is used on the current site and will be built out over time. Her sprints are four weeks each with one week in between for review, planning and clean up.

As we approach our 18^th and 7^th sprints, respectively, we thought it might be useful to review what has and hasn’t worked using the Agile development framework for creative and content work. As it happens, and perhaps not coincidentally, our experiences have not been far apart in terms of process ups and downs.

Let’s start with some of the peaks.

Flexibility. We developed the design templates for the site, one section at a time rather than taking on the site as a whole. This naturally had its bugaboos, but the ability to adjust designs in subsequent sprints with minimal drama was a huge benefit. As our thinking evolved on the creative, user experience and content fronts, we were able to approach our developers and essentially say,  “Hey, we have some updates to the templates and that work will be part of our next sprint.”

Teamwork. Some people take issue with the multi-disciplinary nature of Agile but our overriding experience was exceptionally positive. It took our teams several weeks to find their grooves, but once we did, it was a creative if sometimes messy joy. Like a trust fall, or blind spelunking. When you’re all feeling your way in the dark, it creates an environment for bonding – in the best scenarios – and the work, in our opinion, is stronger.

Speed. Without question, we were able to produce finished work quickly with Agile and Liz’s team even launched one complex site section during Sprint 3. Her client was very pleased with our pace and the team was excited to see the product in action so early on.

Focus. There was definitely something freeing about the targeted nature of sprint planning. When our teams agreed upon the stories for each sprint, we felt cushioned from the distraction and disruption of scope creep. When new features and ideas were proposed, it felt great to not have to address them immediately. We just put them in the backlog and prioritized them later. Nothing was off the table and it allowed us time to make more thoughtful decisions and not respond reactively.

Now for the things that worked less well. In our next go with Agile, we’ll be able to fine tune certain aspects of the process. However, from our current vantage point, some of the pitfalls seem to come with the Agile territory.

Part vs. Whole. If anything plagued the content portion of our projects it was the tension that arose from our needing to participate in nearly every UX conversation for weeks on end and at the same time desperately wanting to create some foundational approaches and deliverables that would set us up for success later on. For example, in an ideal world, Liz would have done a complete content inventory and gap analysis up front, but there was no time. She had to focus exclusively on developing the first site section we had scheduled to launch in Sprint 3.

For Rachel’s part, the information architect assigned to her project pinched hit with some content analysis but only went as far as identifying the pages that needed to be redesigned, when a more in-depth evaluation would have been helpful for tasks down the line.

User Stories. Look, we get the whole story thing and how they can keep a team focused, help prioritize work and serve as an ongoing reminder of visitor and business needs. It makes a whole lot of sense in many ways. However, there were so many content components that fell outside the tidy Mad Lib construct of, “As a _______, I want to ________ so that I can _______.”  At one point, a touch frustrated, Liz framed a story in this way: “As a content person, I want to create a content model that meets the needs of the entire site so that I can feel like I’m doing my job properly.”  Her project manager wasn’t wild about that one, as it was far too big a hunk of work to bite off when there were other pressing content items. As such, the content modeling happened piecemeal, which was frustrating and inefficient.

Rachel’s team didn’t adhere that closely to the user story format above, which was sometimes problematic in that the stories were more akin to business requirements or project tasks. Often there wasn’t enough detail, making them a challenge to scope. And sometimes the stories were too prescriptive, leaving little opportunity for the team to develop their own solution.

Content Management Systems Lack Agility. The Agile process might be flexible but most CMS’s are not.  Their database tables and presentation layers are made up of a web of code that is based on names and structures that cannot easily be changed. For both of us, this meant getting locked into ways of publishing in early sprints that weren’t the most efficient or comprehensive based on knowledge we gained in later work. And the rules of Agile don’t really apply at that point. Some things simply cannot be “refactored” and you just have to live with earlier decisions.

Generalist vs. Specialist. Agile was originally designed for web development projects where teams were made up of coders with roughly the same expertise. Any team member could conceivably be assigned any task.  These days, the Agile approach is applied to projects that require individuals with many specialties, like content strategy. Where one coder could just as easily do the work of another in a big software project, it does not follow in a website redesign project that a designer who finishes her tasks  can simply take on the work of a content strategist and vice versa.  As a result, we found it especially challenging to keep up with our core content activities while always needing to be the “voice of content” for parallel work. It sometimes left us feeling like everything suffered from a lack of attention.

So, how can we adjust for these less-than-ideal conditions?  Improvements will come with working smarter now that we have a sense of what Agile is all about.  It’s easy to think that more resources would solve many of the problems, and maybe that’s true. But funds are not limitless and we keep boomeranging to the same conclusion – that content professionals should have the opportunity to do foundational work prior to immersion in the design process.

When it comes down to it, dicing up core content activities to coordinate with a sprint schedule or design and UX tasks is utterly counterintuitive. For so much of our foundational work, we want to be looking at a site as a complex whole, tackling the prickly issues as we survey the entire landscape rather than a few frames at a time. Blind spelunking is great for brainstorms and team bonding, less great for thoughtful and thorough content strategy.

We’re not the only ones thinking about this subject. Here are some other perspectives on content and the Agile Way.

Do you agree? Disagree? Please let us know how you’ve approached the challenge of developing content strategies in an Agile framework.