What on Earth can marketers learn from programmers? At first glance, the answer might seem to be “nothing,” but my experience tells me otherwise.
My background is in software development. I spent more than a decade developing computer games, and now I run a content marketing agency and an online business application. So I have a foot in both camps: marketing and software.
Agile programming is a relatively new approach to software development. It turns something confrontational, risky, and unpredictable—software development—into a manageable, predictable, and collaborative process.
That is what we are trying to do with content marketing: Using agile programming as a model, we’re developing our own version of agile marketing.
1. Peer programming
Agile programming is done in pairs. Two programmers work on the same piece of code at the same time. It’s the opposite of the usual image of the heroic programmer burning the midnight oil, but it works. It improves code quality and productivity. At Articulate Marketing, we assign two people to each writing task. They do interviews together, and then one writes while the other edits. Often, we flip roles on the same assignment for different pieces of copy.
In agile programming, every change you make to the code is matched by an update to the automated testing software to make sure that changes don’t break what already works. In marketing, especially online marketing, almost everything is (and should be) testable. Does this page get more conversions than that one? Is this CTA better? And so on. But the idea of regression testing also means that what works today needs to be continuously tested to make sure it still works tomorrow. Marketing is not a matter of one and done.
3. No crunches, no burnout
Agile developers don’t do crunches. There are no caffeine- and pizza-fuelled all-nighters. Instead, they plan their work around a regular but intense 40-hour working week. Marketers should do the same, even if that means saying “no” to client rush jobs. As they say in Texas, “lack of planning on your part does not constitute an emergency on my part.” After all, rushed work is often sloppy work.
4. User stories, not specifications
Agile development doesn’t deal in formal methods, detailed specifications, or any of the other ways project managers try to insulate themselves from client caprice. (See The Devil’s Project Management Dictionary for more.) Instead, it asks the customer and the developer to collaborate in describing what the desired outcome is in simple, short “stories”—for example: “users can create a new account.” Marketers can take a similar approach, specifying outputs, such as the style or topic of an article, rather than inputs such as number of hours it will take to write it. (This is what we do. No time sheets here at Articulate!)
5. Quantify the difficulty, don’t estimate the duration
Take a look at Pivotal Tracker. It’s a project management tool for agile development that takes an approach different from that of more conventional tools. Instead of asking developers to specify how long a story will take, it asks how complex it is (on a scale of one to three) and how important it is relative to other tasks. Over time, it tracks how long you take to complete different types of tasks, and after a short while it can predict when you will finish different tasks. At Articulate, we tend to use word length as a proxy for complexity, but we work on a similar principle to do our traffic management.
6. ‘Stand up’ meetings
Instead of interminable status meetings and conference calls, agile developers have “stand up” meetings at the beginning of the week to share information. We do the same. And, as the name suggests, if people stand up, they tend not to talk so much!
7. Expect change, don’t fight or manage it
Most software projects involve detailed specifications that are set in stone once the development begins. The problem with such an approach is that circumstances change, and, often, the customer doesn’t know what works for them until they see it in code. Agile development encourages client involvement and assumes that the project will change over time. By breaking it down into short sprints (see next point) and small, well-defined bullets, an agile project is more flexible. Generally, we take this approach at Articulate, allowing and expecting clients to give feedback even through multiple revisions. Feedback and rewriting can be frustrating for writers. But expecting them, even embracing them, helps us to do a better job for our clients.
8. Sprints, not marathons
When I used to make computer games, some projects lasted 18 months, and we didn’t know whether we had a fun, playable game until perhaps three quarters of the work had been done. Agile development takes a different approach, aiming for a ‘”inimum viable product” early on, and small incremental improvements over time. Marketing projects should be the same: Your website is never really finished, your small business ad campaign never really ends, and your social media outreach is an ongoing project—not a one-off task for an intern.