Agile Book Writing

Let me tell you how writing a book (at least in my case) is simply another agile project:

I have a high-level feature list that contains a large number of things I want to write about. It covers everything from complex adaptive systems to software engineering, from methodologies to software process improvement, from ant hills to economies, and from molecular biology to sex. Yes, I know the scope is way too big. But I don't care, because I will not waste my time on any up-front low-level specifications. I am applying a timebox, which means that the least important stuff will simply fall off at the end (except for the sex, of course). My guess is that writing a book is as joyful and painful as producing two babies. I have two kids myself, therefore I consider myself an expert estimator in this case. So I've given myself 18 months to write it. The book should be finished before the summer of 2009.

I write the book in increments, in the form of individual articles. I have completed four articles since january. Three of those are being reviewed by different magazines, and I published the fourth myself last Friday (see my previous blog entry). I also usually send my articles to a number of experts who've published their own papers and books on the same subjects. I think it is essential to have people (both experts and blog readers) read and comment on my ideas before anything is solidified on paper! This form of incremental delivery ensures that whatever I publish next year will have survived the scrutiny of many readers. Now, let me tell you honestly: I think streaking a supermarket on a busy Saturday afternoon is less scary than sending your own writing to some of the greatest minds in the industry. After I sent my messages this Friday, I immediately switched off my computer and I did not dare to read my email for two days. But I'm glad to say I survived! I got some very positive feedback from Alistair Cockburn, Mary Poppendieck, Brad Appleton and several others. Sure, the feedback included some pointers for improvement. But as I wrote in my latest article: we increment to adapt.

I write my articles iteratively, meaning that I thoroughly write and edit (and rewrite and re-edit) every part of the text until I'm happy with every single word of it. I will tell you some more about this gruesome process some other day, if you're interested. The process actually consists of seven or eight steps (with one of the last steps being: "Read it out to yourself, in a loud voice!", and the next step being: "Do that again, louder!"). Most of those steps are simply intended to improve the writing, by going over it again and again. As I wrote in my latest article: we iterate to improve.

I select the stuff I write about based on my own business value. I act as my own customer. There are problems I need to solve in my daytime job, which makes me want to learn about theory and practice from the experts in our field. And when I've learned enough I can just as well turn that knowledge into a new article, or blog entry. Sure, not all of my daily problems lend themselves for being a subject. I have yet to figure out how three dead olive trees and an exploding coffee machine are going to fit into my book. Still, I'm trying my best to have my writing be driven by the problems that I actually need to have solved.

I measure progress of my book by the number of pages actually delivered. I don't count work-in-progress (like blog entries). Work-in-progress has no value until it is delivered in the form of a finished paper. Since January I've written four articles of 55 pages in total. This means that my velocity is 5 pages per week. By extrapolation, I should have around 350 pages before the summer of 2009. Yes, I'm sorry, you will all have to wait a while. But look at it this way: just keep reading this blog, and you will have read most of my book before anyone else!

  • Iterations and Increments Recycled
  • Traditional Risk Management Doesn't Work
Related Posts
free book
“How to Change the World”
beylikdüzü escort