Glass Maze Every jumbled pile of person

The Agile Novel

The arrival of the Agile movement was kind of a watershed event in the history of software development, because it gave the notion of iterative development a face, and a manifesto. The industry had historically focused on an aggressively monolithic, sequential lifecycle that relied on completely finishing one stage of the process before moving on to the next, and never revisiting that stage. Requirements, Design, Development, Testing — all of these things happen in lockstep when you’re doing waterfall development.

There are lots of problems with waterfall, but the worst is its inflexibility. Because everything flows inexorably and exclusively from a previous stage — that you don’t ever go back to — a small mistake made in, say, the requirements phase might not be obvious until the very end, when you’re on the brink of release.

Agile tries to address this problem by essentially miniaturizing all of these phases, and then repeating them, over and over again, in one-month-or-so cycles, until you’re done. At the beginning of the month, you’d pick a bunch of requirements to implement, flesh them out, design exactly as much as you need to implement them, and then write and test the code. At the end of the month, you have a small, but complete, subset of the application — but, more importantly, you have an idea of how some of your initial assumptions/designs/requirements actually fared, and the opportunity to adjust your plans based on those findings.¹

What I’ve been wondering, lately, is whether it would be possible to apply some of the precepts of this movement to domains outside the manufacturing/software development worlds where it grew up. Specifically: I’m wondering whether you can write an agile novel.

There’s a giant piranha-cloud of caveats to get out of the way before we can even start talking about this. Many agile development concepts are focused around team dynamics, none of which really apply to the solitary act of novel-making. And the software development phases don’t really map naturally to the writing process. You could, I suppose, rechristen having an idea and researching it as the “requirements phase”, outlining the novel as the “design phase”, actually putting words down on paper as the “implementation phase”, and rewriting as the “QA phase”. But … yuck. My god yuck.

However — there is one aspect of agile development that’s intriguingly applicable: the notion of working in one-month “sprints”, at the end of each of which you’ll have something that’s both complete, and presentable.

I’ve encountered a lot of approaches to writing a novel, all of which sound valid to me: starting with an outline and then building a book on its bones; or plunging in and writing all the way through, and then going back and fixing the mess; or writing just enough to get the characters, the setting, the plot fixed in your head (about 100 pages in is the number I hear most commonly), and then going back and starting over.

If I were ever to embark on a novel, that last option would probably be the one for me: not because it’s better than the other two, but because I’m incapable of figuring out what I’m going to write about without actually writing about it.

But what if there was a middle ground? What if you just “designed” a month’s worth of narrative beforehand, and then spent a month writing it, so that, at the end, you had a complete, self-contained, measurable piece of the novel finished, and a clear path to the rest.

I see lots of advantages to this approach:

1. At the end of the sprint, you’ve actually finished something. The thing you’ve finished isn’t a novel, certainly, but it’s a definite unit of work, something you can show to someone — a workshop, say, or a writing group.
2. It gives you a manageable goal, and a timeline, which is a wonderful gift for writers who don’t work well outside of that kind of framework — ie, people who need plans and deadlines.
3. It provides a natural checkpoint. At the end of each sprint, you can look back on the novel-in-progress, decide what’s working and what isn’t, and, if necessary, change course.

I haven’t really given this a lot of thought², but it seems like it represents the best of both worlds — it gives this large scary endeavor a kind of loose structure, but still leaves you free to improvise and imagine in the large lacunae between its fixed checkpoints.

As with many things, I don’t really know what I’m talking about here. I’ve never seriously tried writing a novel. But what anecdotal evidence I’ve heard suggests that some writers, at least, follow more or less the same process: a lurching, episodic series of spurts, interspersed with many returns to older parts of the novel that subsequent work have rendered incorrect, or incomplete, or misplaced, or just plain obsolete. This has always seemed like an extremely painful process to me, one that I’m fairly sure I would fall victim to. I wonder if the agile novel is a way to dull that pain, somewhat. Or at least slot it into a framework that allows you to see the pain coming, and use it to your advantage.