Can you write a book while you are a full-time employee and your job is the only income source? I have been searching for the answer to this question for ten years.
I wanted to write a book for a long time. But I didn’t know how to combine writing with a quite stressful job and multiple hobbies. Also, for some reason, I was convinced that to start writing I had to fully immerse in this process, literally lock myself at the home office and invest at least a couple of months of continuous creative endeavours. This meant, I had two options: the first one - to quit my job and break up well-established career for an ephemeral perspective of becoming a writer; and the second one - to postpone my dream for better times.
For years I chose the latter. Meanwhile, my internal voice, demanding at least to give it a try, grew louder until it turned into an incessant scream.
The universe was favorable to give me a chance. A ten-year-long procrastination from writing was interrupted by an article on Medium which I came across by accident. It was a jackpot! The author was sharing her experience on how she managed to write and publish a book while working full-time at her primary job. Her approach was to write several hundred words every day in the morning before commuting to work. It was so obvious! But this article made a true revolution for me because it ruined my fears and showed that combining two occupations was possible. No need to choose one. I only required to invent my own coordinate system, e.g. how to gradually move forward showing some progress and how to ensure both occupations don’t interfere.
Experiment
Inspiration came from my IT background. Back then, I worked as a Product Manager. In IT projects I was engaged in, we usually applied Agile framework to build a product from scratch. Agile allowed developing it iteratively in small chunks. And so, I thought, why shouldn’t I try to apply Agile along with all its ceremonies and tools to writing my book?
Thus, the experiment was born. The major aim was to help me systemize the book writing process and guarantee continuous progress. But it was not the only reason. I was extremely curious whether Agile, normally used in IT projects, can be an effective means for writer’s activities. The results amazed me.
Setup
In the circumstances of a limited amount of time, it is critical to keep discipline and set clear goals. The approach described by the author of that magic article wouldn’t work for me, as most of the mornings and evenings have been already reserved for other regular activities. On top of that, I could hardly believe that occasional writing when you have 5 free minutes here and there will be an efficient way to get a book done.
Thus, I decided that it could be more functioning approach for me to define a certain amount of work per unit of time. That’s why I chose to work in weekly sprints [one-week duration cycles] for which I would plan a certain number of tasks. The complexity of each task should be approximately estimated in advance. Each sprint needs to have its goal, for example, “to complete the chapter about Carla”. It doesn’t matter when and how I will perform those tasks, even at night or during weekends, but at the end of the week the planned amount of work has to be completed.
In order to plan activities and track progress, I purchased JIRA subscription (JIRA is a professional software for managing a development process). At the moment of my experiment (it was the end of 2018), a few free task management tools already existed on the market, but JIRA was the most convenient for me due to the possibility to fill in the estimation of the task complexity, to set the sprint goal and have different analytical reports (performance charts etc.). There was some psychological trick as well. I believed that subscription expenses will motivate me to keep discipline.
Have you ever been interested, what is the real amount of time you spend on a specific task? I mean pure time without coffee breaks, scrolling Instagram feed so on. I might seem a nerd, but I was eager to know how much time exactly I would spend writing a book. So, I installed a mobile application Timesheet with a timer function.
On top of that, for my “book project” I have bought an electrostatic whiteboard, colorful sticky notes and markers. And the last element – I prepared a dedicated notebook for writing down my observations and conclusions on the experiment. Thanks to those notes, now I can easily restore much useful information.
Great, now the setup to start writing was ready: the framework was chosen, I would follow Scrum [one of Agile methods] with weekly sprints; I would manage my project in JIRA; I would track time spent in Timesheet; I would use a whiteboard for creative thinking.
Preparation. Workshop
The next stage was to create a list of tasks [backlog] to further add them to JIRA. In fact, this list is a plan of the book where each task is an episode or even an entire chapter (e.g. intro or epilogue).
But to create the backlog you need to decompose a book’s idea into smaller parts. At that moment I had only a high-level storyline and the idea of the epilogue. All that could fit in a couple of sentences. There were no more details thought out yet, it was not clear how many characters would exist and what would be their path throughout the novel.
“Book plan creation is a repeated decomposition and assembling of ideas”.
To achieve the necessary level of detailing firstly I ran the workshop, something similar to Design Sprint by Google. For one week I brainstormed and put my insights on the whiteboard.
At the end of the exercise, I had a detailed vision of a book [in IT that outcome could be equated to a product vision]. All main characters were defined, as well as their traits and mission were thought out [personas]. Also, I defined an approximate path along the plot for each of them [user journey]. While working on those tasks, the concept of the book was enriched by specific details, and the plot was crystalized end to end [service blueprint]. This eventually turned into an extended synopsis. When you have a synopsis, you have a good basis for further decomposition.
You might wonder, why I overcomplicated that much? Well, a long time ago my first attempt to write spontaneously, defining the plot on the go, failed. Back then, I realized that I am the type of author who starts writing from the end of the story. Basically, before approaching writing whatever I should clearly understand what is the final point I am aiming to reach and how exactly. Perhaps this is a professional deformation because this is how a Product Manager usually performs. All in all, for me it was the only receipt to succeed.
"I belong to those authors who start writing from the end of the story."
Going back to the decomposition topic. As long as I had a synopsis ready, I broke it down into book parts (like, the prologue, exposition, dilemma, climax, resolution, epilogue). Those bigger parts were subsequently divided into chapters. The book parts became epics [‘epic’ is a type of task in JIRA], and each chapter was split into several stories [‘story’ is another type of task in JIRA]. Certainly, each story was defined using INVEST principle :).
Brilliant, now I had the entire plot of the novel decomposed into smaller chunks. From this list of tasks, it has become clear which topics I need to research deeper before starting to write a chapter. Thus, additional research tasks were identified [‘task’ is another type of task in JIRA].
In such a way stories and tasks formed a backlog. As the plot chronology was already known, it was easy to range tasks and stories in the priority order. I did a preliminary work breakdown in Excel and then transferred the final version to the JIRA project.
Finally, the preparatory works were completed. It was time to start a true Scrum game.
Planning
My work on the book consisted of thinking out of the episodes, researching some topics or facts, writing, and finally noting my observations, conclusions, and new ideas. Some activities require more time than others. For instance, research can take a lot of time. That’s why I tried to split it in such a way, that I have enough time during the sprint for both - writing the episode and research.
So, the first important step in Scrum is sprint planning. For this purpose, I need to go through the tasks from the top of backlog, estimate them, and try to guess how many of them I can complete in one week.
As I was a solo worker in this project (there might be other people involved in a book writing process: a second author, an illustrator, or a beta-reader as a tester etc.), so I had to estimate all tasks myself relying on gut feeling. How did I do that?
I achieved it through relative estimation. Imagine investigating the topic of the molecular structure of plastic to figure out whether a reverse chemical reaction to decompose it on the primary elements is possible... For a dummy like me in this area, it was an extremely complex task, so I estimate it in 13 points*. On the other side, the task of desk research on the history of the Colombian drug-trafficking organization FARC seemed to be relatively easy, so it could be estimated in 3 points. You got the idea.
* To estimate the task complexity in Scrum the most often Fibonacci sequence is applied – 1, 2, 3, 5, 8, 13 etc. where 1 – is the smallest size of the easiest task.
Following this approach, I estimated each activity, selected a few of them, set a goal for the upcoming week, started a sprint in JIRA (the magical moment when the countdown of the days begins), and actually, started working.
Project execution
After preparation and planning, the next phase is the project execution, or in other words - writing, including completing Scrum ceremonies.
It was quite natural to play with Scrum. The majority of ceremonies 'by the book' were applicable.
Refinement
While writing the book, oftentimes it appeared that some research was missing, or I decided to introduce a new character, or fundamentally change an episode. In such situations, I just added new tasks or stories in JIRA, updated existing ones, and changed the priorities of the backlog items. This immediate documenting allowed me not to lose or forget anything.
Sprint planning
At the end of each week, before starting a new cycle, I estimated the tasks and prepared the list of items for the next sprint. To see the detailed description, please refer to the previous chapter.
Retrospective
After completing the sprint, I analyzed the results. Did I manage to reach the sprint goal? How much of the planned work did I complete? How much of that plan was not finished and why? Does the Agile framework (Scrum specifically) applicable for book writing? Based on the conclusions from the above questions I adjusted the process.
Daily Scrum
Every day I reviewed the most recent written episode to keep coherent thought. I also checked tasks status in JIRA and what goes next in the plan.
Demo
Demo was the only ceremony I didn’t practice. In IT world it is an event of presenting the work completed throughout the sprint to the team. In my case, it could be a proofreading of the book fragment by a beta reader. I decided that the critics on the level of small text chunks may negatively impact my motivation and defined plan. I considered the option of proofreading when the whole chapter was ready, but I denied that idea for the same reason. So I delivered a demo to myself. I just read what I wrote during the week, tried to critically evaluate it, and made some corrections.
Playing Scrum might seem sophisticated, but in fact, performing all those Scrum ceremonies took me from 5 to 30 minutes per week. I know it precisely since it is tracked in Timesheet!
Experiment results
The main result – the book is written!
Scrum worked out! Following the methodology allowed me to make steady weekly progress, stay motivated, and keep the focus – not to “fly into space” and stay on track.
The overall efforts on the book project are equal to 492 hours. 263 hours were spent on writing, 66.5 hours on research, 152.5 hours on editing. It is an interesting insight I will use as a reference point for the next book. The figures also demonstrate that surprisingly, self-editing takes half of the writing efforts.
Below are key findings on how Scrum was useful:
After the first sprints, my 'internal critic' demanded to rewrite every single paragraph till the unattainable perfect state. But it interrupted the flow of thoughts. I was losing the track and the writing became harder. Fortunately, I was rescued by the Agile mindset. I switched to the more flexible mode: I decided to go with the flow and re-write, edit, improve etc. after the entire draft of the book was ready.
Sprints were pushing me to complete as much work as possible planned for the week. This is like competing with yourself; you dare yourself. At the end of the week, you do whatever it takes, but to make some progress. Very similar to what happens in IT projects.
Week-long sprint with 2-4 tasks was a good choice. You can quickly see some progress. Smaller number of tasks in a sprint makes its completion achievable. These facts positively affect motivation.
Playing Scrum was so curious that helped to defeat procrastination. You get engaged in the result-oriented process with a clear and measurable goal.
When I had to travel for business or leisure, and it happened quite often, I put my project on pause. After return from the trip, it was easy to get up-to-speed as JIRA reflected a clear plan of what to do next.
It backed better balancing of the work: creative part (writing) and routine tasks (research).
It helped to avoid chaos and well organize the writing process. As in a typical Scrum team, at the stage of backlog creation, I could not take into account all the details. Later on, I added dozens of new backlog items which could be easily ranged according to their priorities. Or when I underestimated some tasks and they moved to the next sprint, items were easy to arrange. I never had a question on where I am, and what to do next.
Conclusion
Sometimes, in order to cheat your internal procrastinator, you have to invent different tricky methods. I turned the book writing into a game, where I could play Agile. This was the experiment that motivated me to do more, perform faster, and reach specific results.
I am an experimentalist by spirit. I like to combine my experience from different fields. That’s why the hook I threw for myself - “Let’s check if Agile might be useful for a writer?” - fully worked for me. Now I can certainly confirm that the methodology is relevant for non-IT projects such as writing a book.
Would I use this approach in my future writing endeavours? In some simplified form, but absolutely yes!