Yes, I have specifically incorporated some AGILE methodologies into my writing process. As mentioned in wetcircuit's answer, AGILE is meant in the context of a team so not everything applies. However there are valuable principles to be applied.

Important question to ask yourself: in writing literature, who's the client? That question is much trickier in writing than in software. At first the primary client is yourself, but ultimately, assuming you want to successfully publish, your clients will be your readers, and your agent and editors. But the first client starts off being yourself, quickly followed by beta readers. Those will be your clients until you have written a really really polished draft. You don't want to show something to an agent unless you've already done everything you can do with it first.

The main AGILE concept I incorporated was the concept of quick iterations ("sprints") to get feedback from beta readers regularly.

I also took the concept that I learned in my software engineering class in college that, based on extensive research, it's been shown that the earlier in the process that a large "bug" (read: large change to the plot or characters) is found in the process, then the better. The later in the process that it's found, it becomes exponentially more work to fix it, because of all the cascading changes resulting in that change. So as we're doing our iterations, we want to be building the most important things (that impact everything else) first, and then the less important things (that are relatively isolated "features") later.

I combined these concepts with the Snowflake Method (a general writing method, not related to AGILE).

The way I combined these concepts looks like this:

First I write the story in one sentence. I iterate on that sentence repeatedly until I think it's just right.
Then I write the story in three sentences. Then five sentences, three paragraphs, seven paragraphs, several paragraphs. At each of these stages I iterate several times. During these stages the "client" is just myself.
Then I write my first draft. At this stage I have an outline (created in steps 1-2) that tells me what most important things need to happen in each scene, so I ensure that at least the skeleton of my story is there in the first draft. At this stage onward, I have an ongoing "backlog" of editing tasks that I keep adding to. But I don't do hardly any of these tasks yet.
Now I can give my first draft to beta readers for feedback. I do a really quick editing pass over it just for anything that's really unclear, but I try not to do very much editing. Why? The goal is to get a functioning ("MVP" if you will) story to readers as soon as possible so you can start getting feedback and figure out what major things don't work. Note that it's important to tell your readers what kind of feedback you're looking for at each stage. At this stage, you're not looking for spelling and grammar or little details; you want to know if the main plot works and the character arcs work and the basic premise works and the pacing works. Again, I'm adding to the backlog more editing tasks, now based on other people's feedback.
Now I group my editing tasks by priority, and I only do top bunch of high priority tasks. Higher priority means the tasks affect a lot of other things, like changing the plot or a character arc or something else really big.
After that, I get feedback again, from a couple of different readers and from reading it myself again. Again I add to the editing tasks.
Now I do the highest priority editing tasks again. Hopefully there's less of the big things and I'm now working on tasks that have a moderate level of impact on other tasks.
Repeat process until I get down to the nitty gritty tasks and then I'm finished! At least, finished with a draft that is hopefully ready to be sent to an editor/agent, and of course at that point there may be more iterations.

Note that along the way it's a good idea to regularly review your list of tasks and consider whether you should still do them or not. I keep a column called "MIGHT NOT DO" and a column of "WON'T DO". (I don't just delete them because of my fear of "what if" I change my mind...I pretty much never change my mind but it's psychologically easier to put them in that column rather than delete them).

Feedback welcome:

I put this process together myself over the course of a couple years and I'm still working on the process to be honest. But it has completely changed the way I write and I have made way more progress this way.

I hope it works for you and I would welcome any feedback you (or anyone else reading this) has on it.

The different hats in SCRUM:

Edit: I just want to add that in writing a book, you essentially are your own project manager and scrum master and developer...all three hats that are normally separated out in SCRUM. Each role has conflicting goals. I think this is the reason that so many people fail to get somewhere with writing a book; by default we will tend towards one role or another.

The scrum master wants to ensure the work committed to each
iteration is not unduly influenced, that interruptions are prevented
as much as possible, etc.
The developer just wants to work. Part of his work is often research so that he has the skills/information to do the work.
But the project manager needs to make sure the right work is being done
and measure the progress towards external deadlines/goals.

It takes conscious effort to switch hats regularly. I don't have an easy answer for how to do these on your own. All I can say is that by being aware of that problem and trying to mentally switch hats regularly, I have done better than before, when I didn't even recognize the problem.

Example: I'm spending too long researching or worldbuilding because I'm wearing the developer hat. I need to put on my scrum master hat and say hey, we only gave you a timeboxed 5-pt ticket for research on that this sprint. We don't need more research on that topic at this time; we're still working on the skeleton of the plot.

---

(0)

Login to post a comment!