Why Agile development methods are a terrible way to write a book

Agile is a popular philosophy for application development. It focuses on iterative development, customer focus, collaboration, adaptability, and continuous improvement.

It’s also a horrible way to write a book.

The positives of Agile don’t apply to books

Agile is appropriate where a world where the needs of the customers and the available technical improvements are constantly shifting. Pre-planned development methodologies with distinct stages (typically known as “waterfall”) often struggle amid the shifting requirements in software projects.

But a nonfiction book is not designed for a rapidly shifting set of requirements. Iterative development (revising chapters over and over) is wasteful. The customer’s needs aren’t typically shifting significantly over the course of the project. There is typically one primary writer, so it’s easier to manage collaboration according to a designed plan with regular check-ins. And there is a clear endpoint — the publication date — rather than an endless process that demands continuous improvement.

So there’s no imperative for Agile methods.

Applying Agile methods to a book generates terrible results

I’ve worked with clients and colleagues who were seduced by Agile ideas. Applying this method to a book means creating a “minimum viable” manuscript, then making updates and improvements as they occur to the team. This is extremely counterproductive:

• When no chapter is ever “done,” there’s a temptation to leave fixes for later. So it’s hard to evaluate if they chapter is any good, since it has obvious and distracting flaws.
• Reviewers and editors become fatigued reviewing the chapters over and over. Their reviews become less and less effective, because they lose perspective. Their naïvieté — their impressions upon first reading — is lost, so they can’t remember what it was like to read this content for the first time, as an actual reader would.
• A chapter tweaked over and over again to make constant iterative improvements becomes an elaborate Christmas tree of baubles, bells, and whistles. This undermines its structural integrity and storytelling quality.
• Multiple chapters tweaked in this way don’t hang together. Elements become redundant across chapters, and it becomes harder to connect them in a systematic way.

Simply put, your writing process for chapters should converge. If you’re constantly tweaking them, they won’t. Agile is not a convergent process.

Is there an exception for books about rapidly-moving trends?

Suppose you are writing about a topic like AI, which is rapidly changing. Should you write your book in an Agile way?

Before you consider that question, think about what will happen after your book is published. It’s going to become obsolete quickly. A book is the wrong format in which to write about a rapidly changing topic. (That’s why I think anyone writing an AI book right now is in trouble.)

If you must write a book in this type of environment, I still recommend a convergent process: write first drafts, make notes where you think changes will be required, and then come back and rewrite the whole thing based on the latest knowledge. And focus on the parts of your topic that are changing less rapidly, like strategy. That’s not an Agile method, but it’s far more likely to get you a coherent and relevant result.

Do you disagree?

Are you writing a book using Agile methods?

How are you and your collaborators making sure your process is efficient, and the result is coherent?

If you’ve found a way to make this work, I’d love to hear about it. Until then, I’ll maintain my belief that it’s a terrible way to write a book.