There is no value in documentation.

I am sure that if you know me personally, or if you are at least tangentially aware of what I do and how I view the world, you are rolling your eyes right now and writing off my statement as being naive. My ask is that you go along with my thought process for a minute to understand what I am really saying.

One of the four values in the Agile Manifesto is “Working Software over Comprehensive Documentation.” Many people inherently interpret this as meaning that those of us who resonate with the manifesto believe that we should never document. This is patently untrue. In fact, if you look at the statement under the four values it explicitly says that “while there is value in the items on the right, we value the items on the left more.” Agile enthusiasts do not advocate for the abolition of documentation.

What we want is documentation that is valuable, and for documentation to be valuable it must be useful. The people it was written for must be able to find it. They must be able to understand it.  The documents must be relevant to the current environment.

Having a document repository that nobody uses is wasteful. Putting effort into populating such a repository is wasteful. Using physical and/or virtual space to store documentation that is never referenced is wasteful.

One of the reasons why I am so critical of “traditional” project management practices is because of the amount of documentation that is considered a requirement for projects to be completed, and the main reason I feel that way is because I see most of them being designed as cover for the Project Manager. Often, I see situations in which a Project Manager has all the responsibility for ensuring project success but none of the authority to make it happen, so they make sure that they document everything that they do to be able to say they have done their job when a project fails or is delayed. I cannot tell you the number of times I have seen this happen personally. I have, in fact, watched a Project Manager bring up said documentation and force people to look at it to prove exactly this.[i]

I do not claim to have the right answer for what is the proper amount of documentation in any given situation. Like most things in the Agile world, it really depends. As a developer, I was a huge fan of self-documenting code (using variables with long, descriptive names to describe what the code was supposed to do), so I did not spend a lot of time adding comments to my code. I also contend that if your organization does not have individuals dedicated to the creation and curation of knowledge most of your documentation efforts are going to end up being wasted (largely because doing so is a full-time job). If your end users search for a document on your intranet and cannot find it, it might as well not exist.

Even more controversial is the notion that your systems/processes/products should be designed in a way that does not require documentation in the first place. Documenting complexity does not generate value for your users but eliminating that complexity does.

Creating documentation is a process, and like any process you should constantly evaluate it to determine whether it is generating value. If it is? Think of ways to make it more valuable! Maybe teach others how to do what you are doing or find ways to make your documentation more accessible to your end users.[ii] But if, as if often the case, your documents are essentially locked in a disused lavatory behind a sign that says “Beware the Leopard” your time could be better invested.

[i] In the specific example I am thinking of, the PM in question asserted that it was not their fault if the people in the meeting were unaware of a situation because the PM had followed the communication plan. My contention is that if you followed the communication plan and your message still did not get across the fault is in your communication plan, not the people.

[ii] If, for example, a user says they searched for your document on your company intranet and could not find it ask them to show you what they did and give that feedback to the people who manage the intranet.