The work of the agile business analyst is never done is one of the conclusions reached in my first agile article for online journal InfoQ User Stories Are Placeholders for Requirements. At 3500 words plus five key take-away points, and with editorial and peer-review by the wonderful agile writer and educator Ben Linders, this was by far the longest agile article I've written in many years and it took several attempts to reach the high standards of authorship required.
At first, I found myself writing 'blog-style', writing a main point in about 300-400 words. But that just yielded ten different 'stream of consciousness' points that made about as much sense as a reference to James Joyce in a post about writing agile articles. Nonetheless, it gave me some options for the main points and I was able to concentrate on those.
An agile article is not a blog post
Having become used to writing and reading 400-600 word blog posts, a full agile article requires far more commitment from the reader. Not just in getting through the quantity of words, but maintaining the thread of the argument and evaluating it too. This is something I realise I have become unused to doing. It even feels like work.
When I'm facilitating a workshop, I tell stories that demonstrate a point. Well, sometimes they are just for fun, but mostly the intention is to provide a mental hook from which to hang an idea or a principle. Yesterday, for instance, I told my Agile In a Day group a story about Mum who will only go into town if she knows where she is going to park! It's a reminder that we shouldn't let be limited by the unknown, and that making decisions as late as possible increases flexibility.
Since I was writing for a 'proper' publication, I thought it best to avoid telling stories at all, but Ben advised me that the house style at InfoQ is to include experience reports. To describe 'what happened when you tried this', and to share the pitfalls so others could avoid them too.
Each draft was a little better than the previous, and eventually it was good enough for publication. I'm proud of the result and besides, it always feels like an honour to have your work published.
Read the full agile article on InfoQ.
