Agile Documentation

A lot of agile practitioners misunderstood the focus on delivering tangible artifacts as "documentation is bad". Consider that often a deliverable is not code, but information. Especially n the Business Intelligence space, just delivering data without context does not add any value. If you are in an organizational culture where initial ambiguity stimulates fruitful conversations, more power to you. But more often than not, stake holders (solution developers & business customers) are not co-located geographically, or even time wise. So we have to consider a communication media that works asynchronously (non real-time), which amounts conceptually to the same as "documentation". 

My observation is that the aversion against documentation tends to be a developer/implementer driven phenomenon. That software developers and IT pros can afford to not like creating documentation will change once IT becomes a buyers' market. Much of this "real programmers don't comment their code" macho attitude stems from a time when IT/software development talent demand outstripped supply. But the inherent TCO (cost of ownership) of badly maintainable code (lack of documentation being a part of that) will drive pragmatic changes of attitude in business, which very well may find the business-ignorant "rockstar" developers on a dying branch of the IT tree.

Still, another impulse against documentation stems from the wisdom that outdated documentation is worse than none whatsoever. I would personally disagree with that generalized statement, by virtue of "it depends" reasoning. If there is clear life cycle meta data, like "last changed timestamp" on documentation, as the user I can gauge how reliable the content could possibly be. The problem is, that documentation is not supposed to replace common sense and critical thinking on the document consumer side.

It is also curious, how having worked in a couple of agile-inspired project environments with aversion towards documentation, impromptu diagrams drafted on white boards and subsequent snapshots with smart phone cameras (later posted on Wiki or emails). Now what was that, if not documentation? 

The stuff we deal with in business processes, rules, data models & relationships, data flows, process flows, is far too complex as to not use documentation artifacts to communicate them across people. Along the philosophy of a picture being worth a thousand words, a diagram, and info graphic, is a precious way to capture & communicate this complexity. That is documentation, not necessarily formal, but it is a form of documentation. 

Let's not view this so black & white: "documentation is so waterfall" vs. "without documentation I can't start my work"

The balance is in treating the documentation artifacts with the same agile spirit as our project tracking & software development. Iterate, increment, track status, review, improve, abandon if irrelevant (minimize work done).

This is as easy as maintaining "last modified timestamp" or "edited by" tagging, which Wikis already do for you. Then your organization can agree on what constitutes "stale content", and in how far "stale" implies "obsolete". 

Just don't simply delete what you deem obsolete. Put that content into an Archive folder (or take "obsolete" tagged content out of your operational views/filters), so you can go back when the need arises to understand how a system evolved. If you have version tracking activated in your Wiki, you can cover change control for audit purposes that way, with even less overhead.

Documentation? Be pragmatic, and it won't contradict the agile spirit!