Let us ask a simple question  then: should we write Documentation ?

The Manifesto for Agile Software Development promotes the value of "Working software over comprehensive documentation". But I think this sentence is often misunderstood : it just means that the best documentation in the world is no excuse if the project fails to deliver a working software.

But Travelling light does not mean discarding documentation:

- First of all, there are a lot of situations in which basic agile documentation based on user stories alone may come up short : For example, many business-critical projects, such as commerce applications or portals, are now adopting agile practices on their projects. In these projects, it's common to have an outside agile development shop creating the application, that then will be handed over either to the hiring company itself or to another third party vendor for ongoing maintenance. In this case you obviously need documentation to make available critical information such as Design Rationale so that maintenance can be performed.

- Being Agile does not mean being short-sighted : although it is true that a lot of information exchanged by the team are only important on the spur of the moment, and hence does not need to be kept, all information that will be relevant a couple of months or years later cannot be captured by verbal communication, and requires to be committed on paper. Remember that if your team's primary goal is indeed to develop software, the secondary goal is to Enable your next effort, 'preparing for the next game' as Cockburn would say.
Documents can preserve knowledge within a team, and prevent the team from re-inventing things when team members leave and new people join.
Documents can capture expertise gained in one project and make it available to future projects.

Knowledge that must be preserved for the future is worth documenting