I only write software recreationally, but I write documents as part of my professional work. This can be time-consuming—too much so—and I’ve often thought about “agile writing”. If such a thing existed perhaps it would help.

The essence of agile is “delivering value incrementally”. We want to get something useful (valuable) sooner rather than later, in part to cope with unexpected changes. Such changes might be a change of direction, or even foreshortened deadlines. We also want to get feedback early, which allows us to change direction as needed.

For software this means delivering something early that works, even if it’s only very limited. I sometimes talk about small pearls—small pieces that are polished enough to be largely bug-free, and that we can string together, but which are small, and at first are not the totality of what we want.

But I think business documents—an architecture document, a business case, etc—are different. A beautifully-polished 2-3 paragraphs describing the market opportunity, say, is not useful by itself. It may be a small pearl (2-3 small pearls, perhaps) but doesn’t provide much value.

Instead, I tend to find a general outline is most valuable at an early stage. Even without any words on a page you can talk to someone: “What I’m broadly proposing is…”. Instant verbal feedback will show what ideas people are going to warm to, what they’re likely to object to, some warnings about what (or who) to watch out for, and so on.

When it comes to writing I try to use this approach:

• First, if there are any facts or data to collect, make sure you know what they are and get what you can.
• Second, assemble all the ideas into a mind map. Potentially add more facts, data, observations to the mind map, as gaps emerge.
• Third, restructure the mind map to the shape of the narrative you want. This mind map becomes the structure of our document. I find it very difficult to restructure the document once there are many words on the page.
• Fourth, write the document against a timer. Each leaf of the mind map is a paragraph of the document, and the higher-level nodes are sections and subsection headings. Each leaf and gets, say, five minutes from me. I write what I can in that very limited time, and then the alarm beeps and I have to stop and move on. I find this requires enormous discipline (this is why I put try in italics above), but when I manage it it works well. The five minute figure is just an example calculation that goes along the lines of “I want to get through this in this much time, and there are this many items in my mind map, so that means I have spend no more than [whatever] on each one.” The end result is not a beautiful document, but it’s got pretty much everything in it.
• Steps five onwards are much like the last step repeated as much as necessary—five minutes (for example) revising each section, and then moving on.

Eventually we get for our document what we get for software: the law of diminishing returns kicks in, and “improving” gives way to “polishing” which gives way to “fiddling unnecessarily”.

But at any time have something which we might share with a (perhaps open-minded) colleague. And if the deadline suddenly does jump forward then we’ve probably got something that’s at least reasonable and does get the message across. At least we don’t have a beautiful three-quarters-finished document that just stops abruptly, or looks great until a rapid deterioration shows we ran out of time.

Of course, this probably doesn’t work for novels. There, if the value is winning a publishing contract, we probably first want a finely-crafted opening chapter—a small pearl. Mind you, if we want to pass an exam on a novel then a summary would be what we want—but that’s about reading the book, not writing it.

I’m not sure this is the best or final form of a pattern for “agile writing” (and it could probably do with a better name, too), but I do find it a very useful approach.

Photo by foam