The Craft
Comments 3

The Importance of Checking Boxes

(Or: How I start a novel, Agile-style.)

So as I am hitting the ‘send’ button on sending two manuscripts off to my agent, I am naturally planning my next book. As one does. And I thought it might be interesting, if not helpful, to go over what I do and why.

Because at heart, I will always be a project manager.

I have to do this because I have ADHD. However, long before I was diagnosed with such, I’d learned coping mechanisms that allow me to function to varying degrees of success. (My closets are still filled with craft projects I have thrown myself into with obsessive gusto and then abandoned several weeks later, but at least I know why that happens now.)

One of the best methods (for me) is the satisfying feeling of accomplishment that comes from checking a box as ‘done.’ (Similarly, moving a task from column A to column B.) If I can break it down into a small task and put it on a list, there is a much, much better chance I might actually do it. Not perfect, but better.

If it’s a big task though, I’ll put it off.

And put it off.

And put it off.

Very often, it will be put off indefinitely until A) I’m slammed against a deadline and Must Get It Done, B) the matter is moot for various reasons, or C) it’s shoved into a closet and forgotten.

Now you may have noticed that books are a big, very big, enormous task. So much so that my family and friends and oh, just about everyone who’d ever known me were shocked beyond measure when I began finishing books. But the way I approach writing books is fundamentally different to the way I approach, say, illuminated calligraphy.

Books are giant elephants, so huge that to finish one, I found myself resorting to the methods I used to organize other unspeakably ‘big’ projects like computer programs or video games—Agile.

Let’s break here to cover a few buzz words. “Agile” is a project management philosophy that became hugely popular in the beginning of the 21st century, primarily in software development groups (for which it was created). It is typically compared to “Waterfall”-style management systems, in which the emphasis is finishing each step to completion before moving on to the next step in a chain that will, hopefully, one day end with a finished product. Agile, on the other hand, asks for a ‘complete’ program/feature/story as quickly as possible. A ‘finished’ product is developed early, but at a crude level of quality, and must be subsequently refined over various iterations/revisions.

In the world of writing novels, Waterfall translates beautifully to a ‘one pass’ approach, in which the author writes, edits, and polishes each scene/chapter before moving on to the next. Agile, in contrast, is the ‘you can’t edit a blank page’ style of book writing, where the important thing is to get something down on paper, no matter how sloppy, so you can fix it during revisions.

(There are plenty of places where Waterfall is objectively the better way to do things, by the way. Can you imagine blodging together a house and then trying to go back and iteratively improve the foundations? Yikes. Any job that requires careful precision and lacks the ability to correct mistakes without literally starting over is not a good candidate for an Agile workflow.)

Even in the world of books, however, I’m not saying that one is better than the other. I am saying that I’ve never managed to finish a manuscript using a Waterfall-style method, and have finished eleven manuscripts using something more Agile. (I know people who successfully use a Waterfall-style method when they write, and their books are beautiful works of art that make me grind my teeth with envy, so this is very much a case of doing what’s best for you.)

It’s my opinion that one of the main benefits of Agile is that it addresses Parkinson’s Law: work expands to fill the time available for its completion. The more time you give yourself to finish a project, the more time it will take to finish that project, regardless of how much time it should have taken. There are multiple reasons Waterfall is a bad system for me when it comes to writing, but possibly the biggest is this. Lacking a definite deadline, it’s extremely easy to be distracted by all manner of things. Life. Research. Twitter. Everyone wants a piece of a writer’s time. Suddenly that deadline is looming and I find myself contemplating a Dashiell Hammett-style weekend writing marathon.

Because Waterfall’s method emphasizes ‘finish each step before I continue to the next’ it’s very easy to find myself locked into a spiral of endless noodling too, where I never get beyond Chapter 1 because that first page isn’t perfect yet. Or reach the three-fourths mark of the book and realize I goofed about something major in chapter 2 and now must rewrite it all. Additionally, because even a chapter can come off as ‘something too big to do today,’ finding another excuse to procrastinate. And if a writer hasn’t done a good job of establishing deadlines, it’s all too easy to get caught in a writing loop where the answer to ‘when will X be finished?’ is…never.

So, Agile is all about tricking the brain. No, I do not have ten months or one year or as long as I want to finish a book. I have two weeks to finish the plot, character development, and create a basic outline for my novel, as well as answer some fundamental questions about style, goals, needs, etc. I use a project management program (sadly, not one I can recommend, as it’s no longer available for free). Each of these needs is broken down into tasks and if any task looks like it will take more than a day, I try to break it down into smaller tasks.

And then I check off boxes. (Or move a task from Column A to Column B, but you get the idea.) There is no elephant. There’s just this small, two-week project that is absolutely attainable. Does it have to be perfect? No. Can quite a lot of it be blatant placeholders? Yes.

Which brings me to one of the other advantages of Agile: failing early.

That may not seem like an advantage, but one of the gutting things about being a writer is the fact that it’s entirely possible to spend months, if not years, of your life writing a piece that doesn’t work. Often, the reason it doesn’t work is because of a flaw in the initial premise, something so intrinsic that no amount of copy edits will fix the problem. But part of the goal with Agile is to put you in a position to see a top-down view of your work as fast as humanly possible in order to fix any problems as fast as humanly possible. Before you’ve lost years of your life creating something you won’t use. Failing early is much better than failing late. So the earlier I can put together a summary, an outline, something that roughs out the basic story so I can show it to my husband, to friends, to other writers, the earlier I can act on that feedback.

It all starts with the basic plot and summary. So that’s what I’m doing today—creating that list of the work I will need to do in the next two weeks. I should add here that I already have a novel concept and idea in mind. Had that not been the case, that would’ve come before this step, but as it happens, I have a rather long list of ‘what next’ projects I’ve been thinking about for years.

Coming up, I’ll cover what happens next and why that outline I’m going to create in Step 1 is both vitally important and also doesn’t mean a damn thing.

3 Comments

  1. Maybe I should learn a thing or two from your methods. I can totally relate to a year-long project going down the dump because of one tiny premise that breaks it—which I hadn’t thought about earlier. Anyway, thanks for sharing your process!

  2. DangerGlitz says

    I love this idea for writing. It makes it seem reasonable, which is something I’ve boggled over when it comes to the beautiful works with epic scopes of world-building such as your Chorus of Dragons series.

Leave a comment