Trickle vs Traditional

The following is taken from current experience, fitting a Publications team into an agile (XP) development methodology. It’s very much a work in progress…

~

In a more traditional development environment, there is likely to be specifications and design documents on which you can rely. This is not the case in an agile development environment, with requirements focussed around user acceptance, and a heavy reliance on word of mouth (through pair programming) and shared knowledge. It may sound chaotic, it is not. Each piece of functionality is assessed and if there is not a direct requirement for a piece of functionality it doesn’t get done, similarly each piece of functionality is stated as a story, and will have an index card created which can be used to track the story through various stages.

To match the pace of software development, the Publications team needs to adopt a similar approach. Rather than waiting on information to come to us, we need to be involved, engaged and pro-active in learning and understanding what we are documenting, and breaking out of the old authoring model.

Previously large chunks of documentation were written by the same person, often at one sitting. You’d outline a chapter and start bashing in the words, investing a lot of time and effort into your ‘baby’. That concept is no longer applicable.

The trickle method relies on the ability of the technical author to retain a “big picture” view whilst working on multiple chunks of information at any one time. The information will not come in a set order, nor from a definitive source, instead it will trickle in from various parts of the development team, testing, and so on. Your job is to monitor the flows of information, position yourself within a stream (or two) and divert the information you need into the documentation.

As such, the technical authors will be sat within development teams and are expected to attend all designing and planning meetings. Understanding as much of the work as possible, as early as possible, will benefit the documentation, and having a technical author in place at the beginning of the development process will benefit the product. Be the user advocate, keep the tasks they will be performing in mind and strive to contribute as and when you can.

This way of working is different, and does mean you need to adjust your mindset somewhat.

You will not:

  • Be able to write entire sections in one go.
  • “Own” the document you are working on.
  • Always finish what you started (but only if it’s planned that way!!).

Hopefully this new approach will make us much more involved in the day-to-day development of the product, and by bringing additional benefits to the development team, will increase our standing with them.

Written By

Long time blogger, Father of Jack, geek of many things, random photographer and writer of nonsense.

Doing my best to find a balance.

More From Author

Becca and Jack on the shore on a windy day

Becca

An image representing writing and blogging

Where will we go?

Jack is Three

You May Also Like

Photo of me and quote from the article

Some more about me

1 year at Allied

Reasons to work

3 comments

[…] how to integrate an authoring team into an Extreme Programming (Agile) development group. The post Trickle vs Traditional outlined a basic way of building up the required content throughout the various stages of an XP […]

Interesting reading, thanks for the tip! This is one more confirmation to what people were saying in a seminar that had several agile presentations. Things like modular documentation, reuse, and writing features (instead of products or books) are very well suited for an agile environment.

[…] eschew traditional writing processes and aim to grab and pillage information from wherever you can, trickling into what will become the final […]

Comments are closed.