The season of the jolly speedwriter!

Bokomslag Skriv och sälj! (e-bok)


I've been speedwriting again! This time about how to write and publish a book very fast:  Skriv och sälj!: Skriv och sälj en bok på 14 dagar (Write and Sell!: Write and sell a book in 14 days) is out on Adlibris, Bokus, Dito, and Bokon.

Actually, speedwriting is a misnomer. I am, have always been, and always will be, a slow writer. The idea with Write and sell! is to reduce queue and wait times in a book production process, the same way we can reduce it in software development processes (Agile), in product development (Lean Product Development), and in manufacturing (Lean, TOC).

I am digging down to the queueing theory with this one, and going with it all the way to what to do, and how to do it.

Writing and publishing the book took only nine days. I had planned to do it in 14 days, but the gods of time buffering were on my side this time around.
Writing and publishing the book took only nine days. The reason why the lead time was so short, is that I utilized Little's Law:

t = I/T

where

t is the lead time
T is the production rate
I is the average number of items in queue

I managed to stir up a bit of controversy in two writer's communities on Facebook when I published the book.

People are assuming that I worked my butt off to produce faster, i.e. increase T in the equation, and that they would have to kill themselves trying to achieve the same productivity.

Of course, I am much lazier than that! I chose to reduce I instead.

How did I do that? Well, one way is to write shorter books, but as it turns out, you do not have to. You can use load balancing instead!

That is right, the magic stems from applying heijunka to the authoring/publishing process. Heijunka has been around since at least 1948. All I did was to apply it in a new context.

I did a bit more than that. I took three other equations from queueing theory, network science, and TOC (specifically from Throughput Accounting), and worked out how to apply them too. If you are interested, well, it's in the book. (Badger me if you are really, really interested in an English translation. The main reason I am not translating the book is sales. Right now it is easier for me to build book sales in Sweden. Sigh!...That's in the book too.)

Now, instead of trying to push people to learn, I intend to work with those who are curious and willing to try something new, and with those who are interested because they already know. Part of that tactic was to create a Facebook group for those interested in reduce writing and publishing lead time.

We'll see what comes of it. There is certainly more "speedwriting" ahead.

I haven't figured out what to call it yet, since it is not really about speed. I am pretty sure the original, Japanese terminology will not fly with writers. No, I need something else...

 Smartwriting, anyone?

Comments

Post a Comment

Popular posts from this blog

Waterfall vs. Agile: Battle of the Dunces or A Race to the Bottom?

Image
The major software methodology wars since the mid 1950’s. Someone was wrong on the Internet, so here we go… In a recent HBR article, It’s Time to End the Battle Between Waterfall and Agile , the author sets up a false premise: There is a war between Waterfall methodology and Agile. The war must end. And finally, you can combine the approaches to get the best of both worlds. This sounds good, but the article is based on a misunderstanding of both Waterfall and Agile. Also, there is no war between Waterfall methodology and Agile. There can’t be, because Waterfall methodology does not exist! Waterfall is a name for large projects that failed in the 1960’s. Waterfall was never a methodology, but a failure to apply the methodologies that existed back then. As I will show towards the end of this article, at least one of the “successful” Waterfall projects mentioned in the HBR article was neither successful, nor a Waterfall project. I got invaluable help from Alistair Cockburn. He fact che...
Read more

Performance Evaluations, Business Strategy, and Agile Methodologies

Image
It is performance evaluation time in many companies. This can be stressful, both to the people being evaluated, and the people doing the evaluation. In companies adopting agile software development methods, the tension can be extraordinary. Individual performance evaluations run counter to agile philosophy, which emphasizes team performance over individual performance. However, managers and corporate leaders need to take a few steps back, and consider the impact performance evaluations have on the organization as a whole. Especially now, in the midst of a recession, it is important to look at a companies current policies to see if they can be improved, or if they are actually holding the company back. So, how can a manager evaluate policy? Performance evaluation policies can serve as an excellent example. I'll confine myself to discussing the so-called ‘rank and yank’ methods. These are performance reviews were employees are ranked using a forced ranking system. It usually looks so...
Read more

Agile Requirements Structures, Part 1

Image
If you have worked in large Agile projects or programs, you may have noticed that there is often quite a bit of confusion about requirements, what the requirement types are, their purpose, how to write them, how to use them, and above all, what not to do with them. There are many causes for this confusion. Here are some of the more common I have seen: Nobody in the organization has read up on the requirements model it is using, so everyone makes their own interpretation. The organization deviates from a standard requirements model, but nobody knows which standard model the organization is deviating from, and/or there is no agreement about how they deviate from it. The organization has not documented its own requirements model very well. The organization mixes two or more different requirements models, often without realizing it. The organization has documented its requirements model, but finding the documentation is an epic project in itself, on par with when Henry Sta...
Read more