Agility of a question mark
Let’s talk about how agile relates to writing and content strategy. I’m not going to discuss sprints, scrums, velocity, stories, backlog, or any of those other jargony terms.
A bit of history
I’ve spent more time working for engineering companies — developing hardware and software — than web design companies. I’m a little spoiled that way, because I’m used to owning my work after it launches.
As a content strategist, it’s my job to help my client communicate with their customers. What that means is that I come in, ask a lot of questions, research user needs, define the problem, make recommendations, write copy, and encourage my client to manage their content. That’s what we do: manage change, while we quietly change how management works.
Epic waterfail
Waterfall provides structure and protects everyone, especially clients with a limited budget. You set up a schedule based on a budget and take one phase at a time. However, waterfall assumes you know everything about every project ever.
Somewhere between The Agreement, The Plan, The Handoff, and The Final Invoice, something starts feeling strange — at least for me. I don’t feel right telling my client, “Here’s your website. We agreed to this six months ago. Hope it works out!” You can add post-launch checkins to a statement of work, but projects often last longer than a year and don’t fit nicely into squares on a desk calendar. Frankly, it’s hard to schedule organizational change.
Agile liver development
In comes agile, or as I like to call it, an excuse to have a delightful cocktail. Because the solution to not having ongoing communication with a client is getting everybody on an engineering schedule. Right? No! Yes! Ouch, my brain hurts.
Honestly, my job duties don’t change that much with agile. I still come in, ask a lot of questions, research user needs, define the problem, make recommendations, write copy, and encourage my client to manage their content. The biggest difference is that I revisit my work and evolve it over time.
A is for ambiguity
Let’s go back to my tiny history lesson. Before consulting, I worked at Apple, which is an engineering-led company. You don’t hear about “agile” at Apple. But you might hear a story about how Boeing builds planes while they’re in flight. Sources and details of the story are sketchy, but the premise is true. Apple doesn’t wait until something’s specced out to get started—or even launch publicly. I’ve said this before: Have a plan. Move quickly. Be ready to adjust.
Apple works in waves; Apple develops. Apple’s never released anything perfect, especially on day one. But they don’t try to. They focus on the 80/20 rule, keep track of edge cases and bugs, staff up their call center during product launches, and change things over time. And that’s why they ship profitable products: they accept ambiguity and go with it.
Smart peeps
- R. S. Gracey talks sense on waterfall/agile: Scrummy Content in an Agile World
- Dorian Taylor takes on the building metaphor: Why Build Software When You Can Define It?