+ back to News
February 12th, 2013

Agile Development + Content Strategy: An Opportunity or Headache?

Blog Post written by Gareth Morgan

Over the past 12 months, Critical Mass has integrated agile development practices into some of our client engagements. Instead of doing most of the content strategy and execution ourselves, we collaborate with the client to discover and build something together. Is agile an opportunity or a headache for the client-agency relationship? Yes and yes. Like any new way of getting work done, there are benefits and drawbacks to consider. Agile development has a relatively short history in the agency world, so many of us have a lot of lessons to learn. Nonetheless, here are three nuggets of wisdom we picked up along the way.

1. Get to know the fundamentals of agile
Agile is not the latest marketing craze or trendy buzzword. Its origins date back to the 1970s, in the field of software development. Thousands of successful titles have been built with agile methodologies. Take time to understand theagile manifesto and twelve principles, as well as some of agile’s benefits and terminology. If your organization has already kicked off an agile project, it won’t be uncommon to overhear a comment like, “We need to timebox this next acceptance test otherwise our velocity won’t allow time for that spike we need.” Wait, what? (It’s all geek to me!) To become an effective contributor, learn the lingo and key tenets before diving in.

This learning exercise will bring you towards a deeper appreciation of the opportunity/headache issue mentioned earlier. Agile’s clarion calls sound appealing: Faster turnarounds, lower costs, better quality products, happier team members. These promises dazzle many executives. What’s not to like? Yet a superficial understanding of agile does not usually uncover the method’s challenges and pitfalls relating to content development, particularly when you drill down to how your specific project is going to be run.

As we discovered, many challenges arose when the key agile tenets came into conflict with our actual workflows and processes. This wasn’t surprising, considering we took a paradigm for software development out of its native home and pushed it into uncharted territory, with new players and stakeholders from multiple disciplines. If agile teams work best by having daily stand-up meetings and face-to-face interactions, what happens if we build a larger team with people dispersed across the country? Could our clients really embrace thehigher level of uncertainty around deadlines, budgets and feature scope that comes with agile? How would we keep our content quality and user experience standards high while also rushing to crank out a “minimum viable product?” Would our familiar (or subconscious) preferences for traditional waterfall methods and command/control decision-making sabotage our efforts? How would we interact with other stakeholders who aren’t yet trained (or sold) on the agile process? These questions and many others continue to loom large. Arming ourselves with knowledge and self-awareness helped mitigate some of the friction.

2. Define the engagement model, roles and responsibilities
If agency and client staff intend to collaborate and build something through

a joint partnership, defining the engagement model is crucial. Who will come up with the content strategy? Manage the production? How will tasks be divvied up among the contributors? Who is responsible for developing the big-picture experience vision, and maintaining fidelity to that vision? Who needs to review and approve the various outputs? Who has the final say on decisions large and small? Don’t kick off an agile project without considering these important questions.

Go a step further and make clear the specific roles and responsibilities of the contributors. Agile can often fall down in this area, possibly due to its origins as a software development process, practiced mostly by developers. Back there, most participants were from the same discipline background, understood each other’s language, and were knowledgeable enough to critique and improve one another’s work. In contrast, our agile teams were staffed with developers, content people, information architects, designers and business advisors. With repeated forays into agile we improved our working relationships, but our first attempts resulted in some wheel-spinning. Not only were there too many cooks, the egalitarian atmosphere led to lots of unproductive discussion.

Promote cooperation, challenge ideas and critique peers, but don’t let the pendulum swing from the old command/control paradigm into the Wild West where there are no experts and everything gets decided collectively. Do you want team members collaborating effectively, challenging each other and using their skills to assemble a great product? Absolutely. Do you want five developers taking valuable meeting time dissecting and debating your copywriter’s verbiage choices on every button and banner? No, you do not. You assign specialists and experts to your project for a reason. Make sure the team dynamics allow them to apply their strengths and contribute value. If not, your product will start to display the unwanted hairy hump and leathery lips of the committee camel.

3. Don’t throw the baby out with the bath water
Passionate agile advocates can get adamant and dogmatic in their opposition to waterfall approaches. Believe me, I get it: reading a project requirements brief that runs 100+ pages is a painful purgatory, second only to the experience of the poor soul who was tasked with writing it. Again, the promises of agile sound winsome: Excessive documentation and process is bad! Just dive in and build something! Embrace flexible requirements! Working software is the primary measure of progress! Fail fast, learn faster! But while software companies have enjoyed success with these principles, to what extent will they work in other fields?

I recall a telling conversation with an agile coach where I suggested we pause to get some technical feasibility input from an external stakeholder. Wouldn’t it be smarter, I said, to find out now what the limitations are around the content management system we hope to build? “No,” he replied, reemphasizing the need for the team to simply crank out working software, the primary measure of progress. Limitations and obstacles would be figured out later. I pressed him further: What if our agile team spends weeks inventing a clever product that can never work on the current system limitations? He appeared nonplussed by the question, gave a vague response, then returned to his same mantras.

The most successful content strategists I know apply conventional, non-agile methods to deliver extraordinary digital experiences. There’s a reason we tackle projects this way: it works. We act quickly, we’re flexible and certainly not bureaucratic, but we like to invest time before production in planning and strategic thinking, which produces insights and approaches that ultimately drive the creation of great products. There is a lot to like about agile development, and since it’s not going away any time soon, we need to get better at harnessing its strengths. That doesn’t mean turning away from other tried-and-true practices that will continue to serve us well in the future. We’re still on the journey of discovering how to best work with agile, as part of our commitment to pursuing quality work and better ways of doing it. If you are also on the journey, learn from our experience: Whatever form of implementation agile takes at your organization, make sure there is time and space allocated for some up-front content strategy work, before the sprints begin.