I generally write a story using a process similar to Randy Ingermanson’s “Snowflake” method, but I don’t think of my process as resembling anything like a snowflake. Randy is a physicist, as I understand, so maybe that explains his choice of metaphor. I, on the other hand, come from the sordid world of software development. So from the world of software, I call my method “Agile Storytelling.”

When you’re designing a piece of custom software, in theory, your client tells you what he wants, and then you go and tell the computer how to give it to him. In reality, your client will never tell you what he actually wants, usually because he himself doesn’t actually know. But that’s okay, because he will most assuredly change his mind anyhow, as soon as you figure out how to do what you thought he asked for in the first place.

In other words, you’re trying to write something that you really don’t understand and that keeps changing from under your feet… kind of like writing a novel.

Now, some software developers try to deal with the volatility of their profession by conducting long, protracted negotiations with clients and marketing people, the result of which negotiations is a treaty document—called “the spec”—which each party will sign in blood. This process can take months, or even years. But after “the spec” has been signed, any requests for further changes can be considered an act of war, thereby guaranteeing that the developer will design software that is completely useless to solve any real-world problem (unless the project gets canceled first).

I am not one of those software developers.

Other developers just dive in and write software without any planning whatsoever. They reason that the client doesn’t know what he wants anyhow, and so he can probably be convinced to accept whatever it is you end up writing for him. If not, you can always fix it all after the fact, even if that means rewriting large swaths of your manuscript— er, I mean, software program.

I am also not one of those software developers.

I subscribe to a philosophy called “Agile Software Development.” In Agile Software Development, you start by accepting that change happens— Deal with it! You deal with it by building your software in tiny pieces, the most valuable parts first. At each step, you have something that you can show the client. That way the client can help you correct your mistakes, piece by piece.

Now, when you’re writing a novel, your “client” is actually a part of you yourself, it’s the “editor” or “critic” part of you. When you write, you’re writing to satisfy your inner editor. When you edit, you’re correcting what your inner writer wrote. So why not do it in small steps, so that you can correct big problems early, quickly, cheaply?

That’s Agile Storytelling.

Here’s the process I use in brief:

1. Write brief character sketches for each of the main, viewpoint characters.

2. Describe each character arc and story thread, in a sentence each.

3. Expand these to scenes, a sentence or two per scene. (You can do this using plot cards, if you’re more comfortable working with them.)

4. Write each scene in 100-300 words. This is “draft zero.” By the end of this, you should be able to see your story having taken form. You should be able to see whether it works, and whether it will be about the right size to hit your word goals. You will also have enough detail planned so that you can track word targets and target dates in writing your first draft.

5. Rewrite the story, expanding each scene to its full length, producing a first draft. Where necessary, insert additional scenes, split scenes into multiples, combine scenes, rearrange scenes, and redefine scenes.

6. Revise the manuscript.

7. Final line editing.

At each step, you can review what you have so far and fix any problems. In particular, by doing a zero-draft, you can see the whole story, though abbreviated, in its entirety. This way, I find it’s easier to catch bigger problems earlier in the process. The first draft is almost like a revision of the zero-draft, even though it’s actually a rewrite, and most of the big plot problems get patched up in this phase, and events get put into their correct order. When I get to revising the manuscript, I’m patching up descriptions to make them more consistent, for example, but there are no plot holes and very few scenes that don’t fit or need to be rewritten—there were exactly two in From the Ashes of Courage.

-TimK