My journey of using agile to write and publish a book
When I was first approached by Pearson, writing a book sounded a lot like the way we used manage tech projects, create products and write software, you’d get a proposal eventually approved by the client (publisher) then you disappear for 6–12 months lock yourself away in a cupboard, write your masterpiece and deliver it, only to have the client rip it to pieces and expect you to rework the whole thing by the end of the month, sound familiar? Oh, and no one ever meets the deadlines (I learnt that bit afterwards!)
Writing a book is traditionally a linear process, fixed stages of production, you write a proposal, it gets reworked a few times by the publisher then they approve it, give you a contract and a date to deliver a 40,000 word manuscript, at which point they will feedback and you rewrite and rework the book. Then you submit a final manuscript, which is edited, proofed and referenced, design the cover, page set the contents and finally it goes to the printers and you’re out the other end book in hand. Except this approach wasnt viable for me, the book had to be created in an agile way, with feedback and change incorporated, fixing everything at the start and locking myself in a cupboard wasnt going to work for me!
When I set out to write ‘being agile in business’, I was approached by Pearson, and they were brilliantly flexible in how we set about approaching the project. Generally authors approach publishers with ideas already manifested, manuscripts written, I had my thoughts, and none of them knew what writing a book entailed. What I did know was that I would need to take an agile approach to write it and maintain my momentum and sanity! I wanted to write the right book, and write the book right!
Write the right book, write the book right
I wanted to get the book published in 9 months, down from 12–18 months, and since the rest of the process was 6 months I could only reduce my time to write the book. To hit a June 2015 release the final Manuscript would have to be finished by the end of 2014, it was September 2014, giving me 16 weeks to write the book. I also had a full time job so writing would be limited to evenings and weekends so I would need to batch work rather than work on it continuously.
With my brilliant editor Eloise onboard and keen to experience agile herself we talked through the idea of agile writing and I was confident with a regular feedback loop in place we could achieve our goal and have the manuscript written by the end of the year.
We agreed I would start writing and send her my work in progress every 2–3 weeks for feedback, she would review quickly and send back comments through tracked changes and suggestions, I would then write again for 2–3 weeks, reworking as needed and adding new content. The deadline allowed for 6–8 sprints of writing. The work in progress was sent as is, as I was writing one chapter other ideas would form for other chapters which I would bullet point out content for and create images drafted with smart art. Each sprint there would be completed chapters, works in progress and starting points to feedback on. At points the feedback started to guide the book itself as clarifying questions about the method were raised so I knew what to improve and write next!
Initial feedback was detailed, suggestions on tone, picking up my Cornish grammar, formatting, structure, and information on how the book would be laid out and presented. This early feedback was incredibly valuable in helping me to write and gain momentum, the feedback helped me identify what to do more of, less of and what to do better. As time passed the feedback became more about what to write next rather than what to change.
As well as feedback from the publisher I also staggered this with feedback from a group of friends and colleagues that would be from its target market, again reviewing my work in progress and feeding back on which bits they liked and which bits they didn’t get, or were hard to read, again enabling me to build this into my work. They also started to adopt the method themselves so this really helped as they were feeding back as an adopter as well as a reader.
3 interesting things happened through the process
1 The amount of feedback decreased very quickly after the first 2 sprints to short comments and very little rework. By addressing the formatting and tone early in the process I was able to adapt my style quickly and so new chapters produced didn’t require re-working, looking back if I had had to rework the whole manuscript to the level I did the first few chapters, it would have been substantial and tedious work. Early on we focused on writing the book right. Once the tone and structure had been set feedback became more about content, what to write more of and what direction to take.
2 I didn’t write chapter 1 first or write them one by one. I took an agile approach and put each topic onto cards and estimated their difficulty, size and importance, and I picked the quick, easy and important ones first so i could build a bit of traction and momentum. I also parked a few that bought on the dreaded writers block, and saved a few of the potential topics I was still undecided on for later on.
I wrote each chapter in stages, idea bullets developed into paragraphs, paragraphs into sections, sections into chapters, and those chapters into parts. I always had a few chapters in progress at various stages, I limited how many I had in active progress to avoid starting too many threads of writing. Each chapter also represented a learning point which helped to write it in bite sized chucks that wasnt reliant on other chapters, each linked with other parts of the book but in the main could stand alone rather like a series of blog posts, or the concept of micro-services.
3 The book ended before I ran out of content. The original list of topics that I had scoped for the book weren’t all included in the book. About two thirds of the way through the project with about 30,000 words in the bank, I realised that I had too much content for the 40,000 minimum viable word target.
Revised estimations and work already completed meant I had up to 100,000 words worth of content which would take far longer to write than was available. I was then able to use Pareto and realistic estimations to select the key remaining topics that would complete the ‘minimum viable book’ and could be easily produced in the time remaining. The Minimum viable book was completed slightly early, which released a couple more weeks to refine and add some additional topics and graphics to create what I was comfortable to call my Optimum viable book at 50,000 words a few days before the final deadline.
We took an agile approach in other aspects of the book too, and still are, we took the same approach with the initial proposal, creating a minimum viable proposal and then refining it and sharing work in progress for feedback and improvement we were both satisfied we were ‘writing the right book’. The goal of the book would be to provide any business professional a practical guide to the ‘agile’ mind set and methods used in the tech sector.
The original proposal for the book was created using an agile approach too, it was great as a pilot for working on the actual book as it was an opportunity to introduce the method and approach to the Pearson team. Literally the first proposal sent to eloise was a photograph of post it notes. The approach built a good proposal that was fit for purpose through iterative improvement, building a collaborative relationship, a shared vision and buy in that ensured that we were in tune with our message and goal when it went to committee for approval.
We’re also now taking an agile approach to marketing, and the PR company have even adopted their own agile dashboard. Matt says its changed the way they work!
It’s interesting how agile has that viral effect, and we can be agile even when locked into a fixed linear process. With an agile mind set and by taking a micro agile approach within the system we can still work in an agile way.
I loved writing the book, I feel the method worked really, we reached our target on time and with a smile on our faces. The experience has been brilliant.
For anyone thinking about writing a book, I highly recommend taking an agile approach, map your ideas out and share them, get feedback, find what people like and write more of that, build relationships and put your work out there to get the feedback you need to write a book that tells a story that others want to read, and accept the fact it’s not going to be quite what you think they want and should read!
I hope that when readers open the book they find something of value to them that will help them to apply agile in a way that gives them an easier and more enjoyable way to achieve their goals.
If you would like to hear more please contact me about speaker events, training and coaching support available email@example.com
Being Agile in Business provides simple, jargon-free advice that is designed to be read in an agile way — in short bursts that can then be put into action in the real world. The book walks the reader through agile, explaining how the strategies and tools can enable organisations and individuals to work faster and smarter and navigate the uncertainty that all businesses face every day. As well as tactics, tools, templates and other practical guides, Being Agile in Business provides real life case studies to illustrate just how agile can enable leaders to find their own way to thrive in any situation. Buy your copy on amazon