When documentation is against the religion

Last week’s KM Australia congress in Sydney had a different vibe to last year. (Here’s the storify.) There were quite a few different faces from 2012, a few of the same ones, the weather was better. The room configuration was different, and maybe that’s all it was, but a small part of me thinks it was because one of the presenters was a chief technology officer. At last! A knowledge management case study from an IT executive.

James King started by explaining the nature of his organisation and the DevOps environment that his team works within. Of course, the Agile Manifesto says developers value “working software over comprehensive documentation”, and that’s where James got the first objection to his plan for better documentation to avoid rework. His response was that the Agile Manifesto is a piece of documentation in itself, so clearly, some documentation has value.

And so, the story continued with the introduction of Agile tools, like storyboarding, to the product support and knowledge management process. Instead of documentation being engineered along with releases, it was produced on demand through the normal support transactions. Without mentioning the words Knowledge Centred Support, James was in fact describing a simplified implementation of KCS, which I confirmed with him afterwards.

Just this morning, I saw a tweet that reminded me of James’ presentation.

You see, the great thing about KCS is that it accepts knowledge has an imperfect nature. It has built-in mechanisms for improving knowledge on the fly. Indeed, why spend hours over-engineering documentation for software that frequently changes and may never be read in full?