One of the other main values in software development using Agile Methodology is choosing a working software over a complete documentation. Reading Scott Ambler on Agile Modeling:
Like it or not, the primary goal is not to produce extraneous documentation, extraneous management artifacts, or even to produce models. Creating extraneous documentation can be comforting because you can fool yourself into believing that you are making progress when in fact you’re not. Instead, you’re actually avoiding a difficult task, likely writing and testing code that may show that your chosen approach isn’t working as well as you thought it would. Writing status reports, trumpeting your successes to everyone, or even worse, covering up your failures, may make you feel good, but it isn’t getting you any closer to your end goal. Have the courage to focus on what is important, the creation of a system for your users. We’re not documentation developers, or even model developers; we’re software developers.
The main goal of software development is to produce a high-quality system that meets customer’s expectations in a timely manner. Any work that is not contributing to this goal should be avoided, according to Ambler. Documentation is a heated topic at almost every place i’ve worked and I’ve been part of the projects in the past that have no documentation whatsoever. It took me weeks to figure out once what the code written by someone else was all about. As the other extreme, I agree with Ambler that it is popular to end up with a pile of useless and outdated documentation that nobody even reads. This seems to be just a waste of resources and time that could have been used on something else. From my experience this is usually the case for large and established businesses where deadlines are flexible and financing is not an issue.
Agile development recognizes that no stack of requirements, analysis, architecture, or design documentation has value if it does not help to deliver an operational system on time. Working software should be the first measure by which a project is evaluated. This can be hard to believe but excessive documentation too early in the development process can at the very least be a waste of time, if it is neglected after it is written and at the very worst can kill a project when updating documentation becomes more important than writing code.
Ambler takes it even further and argues that system documentation is a business decision and not technical, thus it should be left for the customer and business analyst to decide on how much documentation is wanted. He makes you recognize that every time you decide to keep a model or document, you are making a serious trade-off – you are forgoing new functionality in order to write documentation.
When you stop and think about it, this is a trade-off that is a business decision, not a technical one. You are trading business functionality for the potential risk-reduction benefits of having permanent artifacts that describe your system. Therefore, you should go to your project stakeholders and ask their permission to invest their resources in this manner, presenting the advantages and disadvantages of doing so.I think this is a fair approach giving the customer a choice to decide what they want. In some situations they can choose to have a couple of extra features, and in other situations they can choose to accept the risks of not having a full set of features and instead have a better documented system.