It is not an information dirt track, it is an information highway, or even superhighway. And a highway means fast-moving. I spent my childhood in a world where Watch with Mother with Andy Pandy or the Flowerpot Men were the stars of children TV. Watching it now is liable to make you comatose. Those were the (good) old days where time wasn’t at the premium it is today. Bill and ben just wouldn’t cut it with todays children – not enough action! Not fast enough!
I don’t want to start a discussion about what lifestyle is better, since whatever the outcome of such a debate, the truth is we live in the here and now. Or did, since we’ve just moved on a bit more as I write these lines.
And as the world moves on, ever faster and faster, driven to a large extent, by the superhighway that now permeates every facet of our lives we, as the ones charged with explaining what is what, must move ever faster as well.
As a rule, we don’t sit in the driving seat, but if really lucky in the front passenger seat. If just lucky, in a back seat but more often than not in one of the trailing battered trucks that follow the developer supercar as he whizzes along the highway. And he is whizzing faster and faster.
Much development done today is done using the Agile methodology. In essence this is a style of development that hopes to get a product that answers the needs of the consumer out to market more quickly and efficiently than using previous methodologies.
Just as in traditional projects, Agile projects start with basic requirements gathering. Knowing the goals of your end users and project stakeholders is the necessary first step to any successful project. However, instead of trying to nail down all of the details up front, your goal in an Agile project is to capture just enough information to have a conversation with the customer at a later date. You capture this information as short descriptions of the functionality in customer terms which you will flesh out shortly before development. Thus, you can avoid some of the overheads that are typical of projects where detailed requirements are gathered early, but often become invalid before the work begins.
During the development phase, there are short development cycles, between one and six weeks, with an end-product ready for release at the end of each cycle. The basic approach is to get-on and go. What is important is getting something out to the customer fast. If it only includes a subset of the customer requirements, this is OK – after all, it is better than nothing and in a few short weeks the customer will get another newer version with more features.
With this fast turnaround concept of development, including plenty of interaction between team members and between the teams and customers, there is little room for documentation. In fact the Agile manifesto states that the aim is to concentrate on working software rather than comprehensive documentation. Thus, face-to-face meetings and emails replace formal design documents and specs.
Since the product changes so rapidly, producing comprehensive user manuals, that becomes obsolete in the next cycle is a non-starter. Instead, the writer needs to concentrate on the bare necessities to ensure proper use of the product.
Minimalistic documentation has been around for years but now is its moment to shine!
Also, start thinking more and more out-of-the-box. For example, training materials can be merged with formal documentation or updates can be delivered via social media. The tweet “New folder feature in creation wizard: click Dir to specify folder.” becomes the latest documentation update. Nothing more is needed – no production, post-production, publishing, etc. A short tweet does the job!
Cut the verbiage. As George Orwell (of Animal Farm and 1984 fame, among others) stated in his treatise, Politics of the English language:
If it is possible to cut a word out, always cut it out.
Of course, that was OK for then. In the fast-moving agile world of today it should be written:
If it’s possible to cut a word, cut it.
The Write Way 