Book development today is a long and drawn-out process, full of wasted time, energy, and opportunity.

In software development terms, books today follow “waterfall” process… tasks are completed in succession until the project is done. This sounds great in theory! But in reality, if one task is delayed, the entire project is disrupted.

Waterfall development is infamous for delivering projects late and over-budget. Worse of all, it often delivers a product that no one wants. How do we avoid that?

Agile development

Again, going back to the software world, agile was a philosophy developed to eliminate late, over-budget, and useless products. Its deeper mission was to eliminate wasted time and talent, because we all deserve to work on meaningful projects.

Damn Gravity has adopted agile development to deliver better books, faster, and to reach more people. Agile informs everything we do, from beginning to end.

Agile also makes us flexible. Books aren’t just written, they are discovered, and that discovery process often changes the scope or even the purpose of the book. By working in short sprints, we can change directions more quickly and incorporate new ideas—hence the name “agile.”

Our Agile Tools

So what does agile book development look like in practice? Let’s start with our primary tools:

Scrum

Scrum is a project management system that prioritizes speed, feedback and continuous improvement.

Most books are written in large chunks—authors or ghostwriters are asked to deliver a manuscript in 4-6 months (or longer), often resulting in months of procrastination followed by a furious few weeks of work.

Once the manuscript is done, a developmental editor will read through the entire thing, provide feedback, then hand it back to the writer to make revisions.

This process continues, draft-by-draft, for however long it takes to produce quality work—typically 12-18 months.

Meanwhile, the only people seeing the work-in-progress are the writer and editor. Feedback is not part of this process. In fact, feedback is typically reserved for when the book is completed and ready to print. This is a huge missed opportunity.

Scrum aims to kill two birds with one stone: Create a higher-quality book and to produce it more quickly.

Instead of large chunks, scrum works in 1-2 week sprints. In that time period, the team (editor, writer, and author) will decide exactly what will be completed in that time.

The key is to deliver finished work within each sprint, and to have a clear definition of what “Done” means.

For example, we may decide to write the first draft of Chapter 2 in an upcoming sprint. What is our definition of Done? In this example, Done means the draft Chapter is ready for feedback.

Feedback from whom? That brings us to our next Agile tool:

Beta Reader Community

The problem with waterfall development is that you don’t get feedback from end users until it’s too late or too expensive to make changes. That is how you end up with useless software and useless books.

Instead, DG’s agile development process incorporates real reader feedback from the first sprint.

On Day 1 of the book development process, the author will announce they are writing a book. But that’s not all—the author will also ask for Beta Readers to be part of the process.

At the end of each Sprint, we share our “Done” work with the Beta Reader Community and ask for their feedback. Depending on the depth of their feedback, we will either add a task to the next Sprint to incorporate it, or save it for the next round of edits.

The Beta Reader Community serves two key purposes:

1. Create a better book by getting feedback from real readers
2. Build an early audience of fans and promoters

That leads us to the third piece of the Agile Dev flywheel:

Day 1 Marketing

Creating an impactful book is harder today than ever. Not only are people reading fewer books, but there are more books in production than any time in history. How do you stand out when more books are all vying for a shrinking pool of attention?

One way to get a leg up on the competition is to start early—Start building your audience of readers while writing the book.  

The beta reader community is one way to start building your audience early. True fans love to see behind-the-scenes, and if given the opportunity, want to be involved in the process. They are the first line of promotion, sharing your book with their networks and supporting you at launch. They will be the first to leave reviews (because they were the first to read it). We will reward them with insider knowledge and one-of-a-kind gifts like signed books. If we make it worth their time, your beta readers will return the effort 10x.

But there are other ways to use the book development process to grow your audience. After each sprint, we will take excerpts from the draft and craft social media posts. Again, this act serves two purposes: to get feedback from readers and to build your audience.

Day 1 Marketing utilizes every part of the book development process to drive awareness and sales, from choosing a title to designing the book cover.

Now let’s look at how we use these tools:

The Scrum Process

There are five steps in the scrum process:

1. Sprint Planning
2. Sprint (i.e. doing the work)
3. Daily communication
4. Review + Feedback
5. Retrospective (i.e. improvements)

Let’s look at each:

1. Sprint Planning

The beginning of each work period (known as a Sprint) begins with planning.

• Prioritize
• Define “Done”
• Estimate time and effort

Every book project can be broken down into at least 100 tasks. That sounds like a lot, but it is easier than trying to tackle a book in massive chunks (like is common with waterfall). Each task is organized into an “Epic,” which is just a larger project such as “Positioning,” “Writing Manuscript,” or “Editing.” But the basic unit of work in Scrum is the Task.

Sprints are either one or two weeks—each team will decide on the cadence that works for them (although I prefer one week sprints)

Sprint planning will take place at the beginning of each sprint in a 60 minute meeting (we will also use this time to review and retro the past sprint)

‍

Prioritize

The first step in planning is to prioritize what needs to be done next. In Agile book development, we will be working on several epics at once, such as Writing the Manuscript and Marketing. But since we have limited bandwidth each sprint, we need to decide what must be done and save the rest for a future sprint.

Each week, we will look at the full Project Backlog (i.e., everything that must be done to complete the book) and pull tasks into our Scrum Board

‍

Defining Done

A critical element of Scrum is to have a clear definition of DONE. “Done” means that the task will never have to be revisited again… it is completely done, and we can move on.

This is important, because re-work is a primary killer of team momentum.

In each task, we will write a clear “Definition of Done.”

Estimating Work

Given each sprint is a finite amount of time, we need to estimate how much work we’ll be able to get done each sprint.

NOTE: We do not estimate work based on time. Humans are notoriously bad at estimating how long something takes.

Instead, we use points, which are a measure of effort relative to other tasks.

Our points system is based on the Fibonacci sequence, where the next number is the sum of the previous two numbers: 1, 1, 2, 3, 5, 8, 13

Why do we do this? Because for a large project, what is the difference in effort between 8 and 9? It’s difficult to tell. However, it is easier to visualize the difference between 8 and 13. We are just looking for an estimate.

Any project that is larger than 13 points should be broken up into smaller tasks.

Once the work is estimated, we decide as a team that the Sprint is planned.

Notes on Sprint Planning:

• IMPORTANT: Once the sprint is planned, we should avoid adding, removing, or changing tasks at all costs.
• Except for emergencies and other rare situations, we are locked into the work we promised to deliver. This is how we build momentum.
• Teams that finish early, accelerate faster. If done correctly, Scrum will allow us to accelerate as we make our way through the project. But in order to accelerate, we must finish the work in each sprint.
• Research on Scrum has shown that teams who finish early, accelerate faster. In other words, they don’t over-plan their sprint. They plan just enough, then over deliver.
• When we get done early, we will pull more tasks into the Sprint — This is the only regular time it is acceptable to adjust the Sprint Plan
• We will get better over time. Estimation may be difficult at first as we learn to work together and how long tasks actually take. This is completely normal, and why we do a Retrospective at the end of each Sprint.

With planning complete, we move on to the Sprint:

2. Sprint: Doing the Work

Some tasks will be assigned to certain members of the team to complete. Others will be up for grabs by anyone who is free and available to get the work done.

Then we will all work together to move all tasks from Left to Right on the Scrum Board.

Tip: Another major killer of team momentum (along with re-work) is Work-in-Progress (WiP)

‍

Too much Work-in-Progress slows us down by forcing us to context-switch often, which kills our ability to focus and deliver.

As a rule of thumb, always try to complete WiP in progress before pulling more tasks into In Progress.

We will not be working on the sprint in isolation. Key to our success will be daily communication:

3. Daily Stand Up

Sprints optimize for speed and quality. That requires a lot of communication between teammates.

On typical Agile teams, the entire team will meet for 15 minutes every day for a “Stand Up.” In this meeting, each teammate will say three things:

1. What you worked on/completed yesterday
2. What you are working on today
3. Roadblocks or questions

This ritual is not just to hold each other accountable, but to help each other get “unstuck” and move more quickly.

Since our book team is not in the same room together, we will use Slack and perform the Daily Stand Up asynchronously.

‍

Also, since no one on the team is working on the book Full Time, I only ask for two things:

• Provide your Stand Up update on the days you work
• Check the Slack channel daily to see if you can help anyone else get Unstuck

4. Sprint Review and Feedback

At the end of each sprint, we will review all the work that was marked DONE (not half done, DONE done).

This will likely take place in the same meeting where we plan our upcoming sprint.

During this Sprint review, we will do three things:

1. Give team feedback on the work
2. Review beta reader feedback on past work
3. Send out the next batch of completed work to Beta Reader Community

We will use Google Docs to collect feedback from Beta Readers. They can leave comments throughout the section and also respond via email.

Ideally, everyone on the team has had a chance to review the completed Work before the Sprint Review, so we can spend time providing feedback.

We will send out Work to the Beta Readers after the team has a chance to review. This is to ensure the Work meets a minimal viable quality that will garner useful feedback.

5. Sprint Retrospective

The last step of the Sprint is to review the process itself. As a team, we will answer three questions:

1. What went well in the last Sprint?
2. What didn’t go well?
3. What is at least ONE tangible way to improve the next sprint?

This is where the magic of Scrum happens. We will continuously improve the process, and therefore the product, each and every Sprint until the project is complete.

And then… we start again. After the retrospective we will update the product backlog and plan the next sprint.

Common Mistakes in Scrum

Scrum can start off slow as the team learns how to work with each other. This is normal. We will make mistakes early on. The most common mistakes are:

1. Not clearly defining Done
2. Over-planning the Sprint
3. Over or under-estimating work
4. Adding or removing work mid-sprint
5. Letting known problems slip by, unaddressed

The most important part is that we learn quickly and try to avoid making the same mistake twice.

What Success Looks Like

How do we know we are succeeding? There are a few telltale signs:

1. We are finishing work early and accelerating each Sprint. Scrum is known to provide 4x productivity for teams that run it well. We will track our velocity over time to see how well we are accelerating
2. The Work gets easier over time. It will start slow, but the Work should start to feel easier over time. This is because we are tackling problems when they arise, not waiting to fix them later. Each week we are improving and oiling the machine.
3. We are happy and fulfilled.  The founder of Scrum, JJ Sutherland, says that Scrum is a method of eliminating human agony. No one likes to waste time or create meanless work. Everyone likes the feeling of working on a team that is in sync. We will check in regularly to see how we are all feeling about the process.

Agile Book Development is the process through which we developer better books, faster, and that reach a wider audience. By using our agile tools of Scrum, Beta Readers, and Day 1 Marketing, we will move quickly and iterate based on real-life feedback. In my opinion, Agile isn’t just the best way to develop books today—it is the only way.

Next, we will dive deeper into the Beta Reader Community and Day 1 marketing.

‍