: Is the Agile planning methodology useful for the writing process of a fictional book? I've been wanting to write a book in my spare time for a long time now, and while I've tried to start

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)

Agile is for corporate sub-groups who suffer from a lack of creative flexibility, blamed on a top-down project-management style (while avoiding pointing the finger directly at upper management). The 'problem' Agile solves is a metaphorical waterfall where projects flow from top to bottom, but can't be paused or pushed back up the waterfall should any creative innovation occur at a later stage.

The goal is to spark creative communication within the sub-group, and develop a common language around practical problem solving. By iterating through short-term projects, the team will hopefully build skills that include finishing projects faster while incorporating more creative ideas. Agile attempts to avoid corporate-style 'meetings' where managers dominate the conversation –– ego-driven, rather than results driven.

The flaw in adopting this methodology in your creative writing is that you are not a team. If there is a lack of creativity in your writing, it's presumably not a problem of stifled communication. You can make an analogy to the 'waterfall' problem that Agile is meant to solve, but compartmentalizing yourself into sub-groups for creative flexibility, and hands-off project managers, will only take you so far. There is no 'group intelligence' that emerges. You are not actually broadening your creative input, and you are not circumventing the ego-driven manager.

The elements in particular I'm interested in using:


Dividing my book into small pieces of work that I can feasibly do in
a single sitting, like writing a chapter outline or doing some world
building;
Planning the pieces I'll be working on in weekly sections
that if necessary can be finished later on;
Turning blockers into
new pieces of work that I can plan to do after finishing the current
tasks instead of getting stuck on them;
Being able to delay more
detailed pieces of work to later drafts without losing track of
them.

To simplify, 1 and 2 are the same; 3 and 4 are the same.

Setting writing goals for yourself sounds like a no-brainer, whether it's goal-oriented (worldbuild the small village in Chapter 2) or task-oriented (write 500 words each day). You will have off days because you do not have a team to pick up the slack, but just being in the habit of writing will help with writing.

However, by pushing problematic scenes and creative blocks to a later session, you are essentially re-creating the waterfall problem. You are kicking the can down the road. Inevitably, some of your creative blocks will solve themselves, but many will require retcon on the story and characters. This is a normal part of writing, but it's where your Agile method stops being useful.

I could see a situation where creative writing suffers from corporate management: for instance the various Star Wars properties would probably benefit from Agile method, with sub-groups allowed more creative freedom and less stuck with what came before waterfall. This is not your situation.

You don't ask for an alternative, but my advice would be Scrivener and a pomodoro timer. Scrivener will help capture all your ideas as they occur, and allow you to write longer work in piecemeal sections as they transition from outlines and short treatments to final scenes and chapters – it's very easy to create a placeholder of notes and goals that will eventually develop into full story beats. The Pomodoro technique seems closest to your time-management goals but is designed for one person.

---

(0)