There is a common misconception that a project using the Agile methodology requires no documentation, this is a fallacy and the truth about this myth will be explained below.
Agile is closely aligned with Lean and can be said to utilize a subset of Lean known as “Lean Product Development”. Lean Product Development in summary, is a Lean approach that helps improve cost, quality, and delivery of software/products or services. There are seven core concepts of Lean and Agile’s value of “Working Software over Comprehensive Documentation” is based on the Lean concepts of “eliminate waste” and “deliver fast”. In keeping with Lean, Agile postulates that devoting time to creating comprehensive documents that do not positively impact the quality of the software/product/service nor increase its business value, can be regarded as waste. So, being guided by Lean thinking, Agile does not encourage any form of waste.
In traditional project management, emphasis is placed on documentation such as requirements documents and design documents. In fact, documentation could be likened to the Holy Grail of traditional project management. This is one of the factors that informed the development of the Agile methodology; to better position project management to redirect focus to actual results rather than distractions.
The Agile manifesto’s second value is:
“Working Software over Comprehensive Documentation”
While the Agile Manifesto acknowledges that Comprehensive Documentation is a component of most projects, it recommends that more effort and attention should be given to Working Software. You would agree with me that in a software development project for instance, the whole purpose of the project is to develop working software, in line with that, the Manifesto, using Lean thinking and focused on business value, suggests that our focus should remain on the end goal and to limit our commitment to what would end as a distraction.
“Working Software over Comprehensive Documentation” places emphasis on the need to deliver. It is meant to remind us of a need to focus on the business value we are trying to deliver as against mere paperwork. If putting in a lot of effort or time into the paperwork would not improve the value of the product or service the project is delivering, why not limit this to the barest minimum? Limiting any distraction to the barest minimum saves time and resources that could and should be directed towards providing optimum value for the customer.
There are exceptions however; some industries are highly regulated and require extensive documentation, documentation then becomes a requirement though it does not contribute directly to improving the quality of the end product but could be required for safety reasons. In a case like this, abiding by the rules and providing the required documentation would save the team more time than having to deal with the consequences of non-compliance.
The Agile approach to documentation is “just enough, just in time – and sometimes, just because”. This phrase is meant to remind us of three critical concepts:
Agile documentation should be “barely sufficient” – just enough to cover the project needs. This helps to ensure that our focus remains on the software/product/service that is being developed.
Agile documentation is done “just in time” – this is also known as the “last responsible moment” – this ensures that we do not have to put in extra time to keep the documents updated as the requirements and designs change. This is to avoid unnecessary rework.
Finally, “just because”, this helps to remind us that sometimes when documentation is required, it’s smarter to just comply and produce it rather than have to deal with the possibly unpleasant consequences of failing to do so.
“Just because” does not imply that we give in to unnecessary documentation requests. We will have to learn to choose our battles. Bearing in mind the fact that projects are time-based, it is smart to decide where best to focus our efforts and what issues such as non-compliance we are ready to deal with in the future.
In summary, getting distracted by interim deliverables such as comprehensive documentation is not beneficial to the project. Though the complete absence of helpful documentation would be challenging and frustrates future support and maintenance, yet, comprehensive documentation without a product/service/software has no value. Documentation in and of itself, at the expense of a working system, is of no use.