Is Your Writing Agile?

I’m not a disciplined writer, I know that much about myself. I write when the mood takes me, and I write about the thing that is in my head when I am in the mood. I don’t know why it happens that way. It may just be a particular confluence of chemicals in my brain. The reality is that I write when I’m ready to write, and I write about whatever I’m thinking about at that time.

The challenge for me, for many years, has been how to convert that spontaneity into something with a structure and direction so that it can be a coherent piece of work when it is eventually completed.

Writing is the simplest thing in the world to do, at least on paper (boom, tish). In practice, in order for it to be more than merely stringing together a series of words, it needs an approach by the writer that converts it into a whole that is enjoyable to read. Consciously or not, every writer worth a sprinkle of salt is applying a technique that converts their thoughts, experience, dreams and ideas into a written sequence that can be converted back into emotions, feelings, thoughts and ideas in the head and heart of the reader.

In recent years I’ve found a useful framework for the way in which I write. This framework is used in software development. I should point out before I go any further that I’m not a software developer by any stretch of the imagination, but I’ve played a number of roles in custom software development, including project management. The framework I’m talking about is Agile software development.

It’s a rich topic but I’m only going to go into as much detail as is relevant to writing, since much of it is focused on how teams collaborate and produce working software. It’s also an evolving field in which views differ on what constitutes an Agile approach. It does have some organizational techniques and concepts that can be applied to writing, though, and I plan to discuss those I’ve adopted to help me turn my writing into coherent stories.

The first concepts I’m going to explore are those of incremental and iterative development. I’m going to use some gross simplifications here, so if you are a software developer, kindly grit your teeth.

In Agile software development, the broad outlines of the project are known, along with the goals and objectives. The detail and the pieces that are built at any given time, however, are done as the project moves along. This allows for flexibility in design and is intended to help deliver high quality working software without the limitations posed by traditional “waterfall” development in which the entire project is scoped before you start.

You might use both an incremental and an iterative approach within the framework of Agile development. Here’s how they differ:

  • In the incremental approach you build what you want a detailed piece at a time, connecting the completed pieces together.
  • In the iterative approach you know the general outline of what you want to do and you sort out and adapt the detail as you go. You start out expecting to make changes.

A good analogy, put together by Jeff Patton in his Agile Product Design Blog, is to think about painting the Mona Lisa.

If you were going to paint the Mona Lisa incrementally you’d complete detailed sections of the painting, adding blocks of completed work as you went along. To do this you’d have to know what you wanted to do in each increment, including what detail was going into the painting and how the blocks were going to fit together (I’m pretty sure this wasn’t how Leonardo da Vinci worked, but bear with me for the sake of the illustration).

If you were going to paint her iteratively you’d start out painting an outline of a Renaissance woman in a summer landscape, bare hands in the foreground. You’d put the details together along the way, and you’d figure out as you went if they were working or not. If you decided later that you wanted to set the painting in winter you could start roughing in the snow and put gloves on her hands.

In the incremental approach you would already have completed part of the painting as a summer scene and it would take much more work to redo. You might even have to start over. Or you could just go nuts with frustration and scribble over her hands like the Monty Python spoof in the Papperbok (or was it the Big Red Book?).

Anyway, it’s not a perfect analogy but an iterative approach to writing allows for the plot details and other elements to evolve as you go. A carefully scripted and meticulously planned story that is written incrementally is, in my view, more difficult to change later.

My current case in point – a near-future London crime story called Dark Streets that I’m finishing up – started life several years ago as a series of short stories. My original template was Michael G. Coney’s Friends Come In Boxes, a book of interconnected short stories written in the 70’s. Coney’s book is a thought-provoking collection that uses the short story form to take a look at an idea from various different angles.

As I wrote the characters and the individual stories for Dark Streets I saw a way that they could be combined into one novel-length narrative. My approach to writing – jumping from one story to another as the mood took me – meant that I hadn’t worked out all the details of each story ahead of time. It allowed me to rework them into connected chapters as part of  a longer tale with multiple threads.

I found it liberating to work with the expectation that I’d have to make changes later. Now I was making mistakes on purpose! It didn’t have to be fully thought through or perfectly done the first time around. If I had the framework and the characters and the rough plot, that was enough.

Now, it is more effort, and if you write in a carefully thought out and structured way you might find appalling the idea of the additional rework. The bottom line is that it works for me, and finding a conceptual framework that fits my natural style makes me at least feel more organized, even if the reality may be that I’m just as undisciplined as ever.