My journey to the heart of agile development, and how it revolutionised my writing process.
I started writing more often recently, while at the same time studying agile software development methodologies, and product development methods in general.
I’ve been working on getting to the heart of the agile development method without all of the particular structures, processes and framework that might be found in a particular implementation.
There has been some success, which I’d like to share here. I’ll start with how it helped revolutionise my writing process.
A New Approach to Writing
Over the years, I developed a writing process that was dysfunctional. It would achieve results at times, but it got in the way. It was hit and miss. Mostly miss.
Once I saw this, and applied some agility to transform it, things got better.
The process went something like this…
Sit down with an idea and begin writing. Start from the top of a blank piece of paper (screen) and begin. Keep going back to the top and reading through it, making changes as you go through. Move sections around, edit as necessary, and eventually reach the point of having something that was ready to publish. Publish it.
It didn’t work. Bits of it did. The problem was that I would often find myself in a situation where an idea I had begun presenting in the article did not develop in the way that I had thought it would. Sound familiar? I would need to go back and reweave the idea in different ways throughout the article.
Because I would start from the top, away from the main body of what was being said, I would often end up in kind of loop, where I would get to the real meat of what I was saying, and it would not be coming out as I had imagined it would, and I would need to go back through reweaving things.
But with so much writing already invested in how I thought it was, this was often impossible to do well. The only solution would have been to throw it away and start over. So, a half done, failed project. There were many of those. Sometimes it would be worth publishing. Sometimes it was even pretty good.
The articles tended to be good when the idea was fully formed before starting, and came through clearly on the first attempt. The process was designed for that. A process was needed that could achieve results with every article, without the need for having the idea fully formed before starting out.
The problem was in the process. It was sequential. It didn’t take account of the fact that not everything was known up front. It approached the project as if everything was known, and planned and approached the development from that point of view.
It had accommodations for change. But they came too late in the process. They weren’t adaptable enough. The damage was already done. The process was broken, and produced broken writing. Writing that was broken in the same way as the process.
How did an agile approach turn things around?
Agile is all about inspection and adaption. About empiricism. About responding to change. There was inspection and adaption built in to the writing process, but it came too late, at the end of the process.
A process that is built on empiricism will ask, how can I approach developing this in a way that will defer as many important decisions as possible, to as late in the process as they can possibly be made. To gather the most information that can be known to help make those decisions.
How can that be applied here?
I applied this to my writing process by deferring the decisions on what should be in the introduction and earlier parts of the article, until the main body of the article had been worked out.
That way, they can be decided upon based on what the main body of the article actually says, and not need to undergo rewrites that make them unfeasible to use at all.
In fact, I applied this type of approach to every part of the writing process.
Development of Ideas
The ideas that made up the threads of the article were not fully formed at the start of the process. They would often need to be changed and developed as they were written.
Due to the writing process, this would not be smooth, as every time they were written, they would need to be in a format that lent itself to being a completed article, since that was the process.
This hindered their development. It was not natural to the process of forming an idea. It worked against it, trying to make it fully formed and perfect as it was coming in to being.
The solution was to sketch out the threads, be it a paragraph, a sentence, or the entire article. Just write sentences, lists of words, phrases, section headings (in the case of the entire article). Whatever works to get the particular idea down, and as much of it as is needed.
Then… refine. Use some of that, write it over again, delete what now doesn’t seem right or can be better. Distill it down, until it’s complete and presents the idea. This is agile; inspect and adapt. Trying things. Being empirical. Iterating.
The development of ideas is moved to the start of the process, as the primary objective. The rest builds out from there.
This is so much easier to see in personal projects than it is when implementing it in a team. Most teams take months or years to have any kind of mature implementation.
Not so for personal projects. I have used an agile development approach to improve my personal task management, personal software projects and of course my writing process as detailed above.
I hope the above story has given you some insights in to what agile development is about, and how you might start getting to know it better by using it in your personal projects.
For some background on this topic, see my article on how knowledge work and business can be brought together harmoniously.