I attended a presentation on Scrum last week, and afterwards my boss made a telling observation that none of the artifacts of Scrum (the Product Backlog, the Sprint Backlog, and the Burndown Chart) are of any use after the product is developed. Agile’s preference for working code over documentation makes it an easy target in the government world, where the objection is that we need both. One of the smartest and most productive developers I ever worked with rarely sent emails or wrote anything down – he used the whiteboard a lot though, and you could always drop in on him and he’d be happy to show you what he was working on. Customers, however, almost always want the documentation since it gives them the sense of security that they could, if they wanted, hand the product to another developer. Since customers define value, not developers, who are we to tell the customer that they are mistaken?

That’s not to say that there isn’t a lot of effort put into developing documentation that will never be used, either because it’s not needed or because it’s poorly produced. Bad documentation sends a message to the reader that his (or her) time is not valued. On the other hand, good documentation, printed on paper, can convey ideas in ways that other modes of communication can’t. You can skip ahead if the current topic is already clear, you can page back to see where a topic was introduced, you can annotate it, and you can take it on the plane with you and not have to turn it off for take-off and landing. Creating documentation (not just writing – I include modeling in this category) can also help you think through difficult topics. The brain works differently when you are putting things down on paper or on the computer screen.

One of the causes for the proliferation of useless documentation results from folks not collocated with the team, assuming that documentation is the main mode for how the team communicates. It’s not. Team members do a good deal of their thinking, communicating, and learning by talking, listening, and challenging each other. Team members typically work with short time horizons. When they’re done with a problem it’s time to move on to the next. Notes and whiteboards and remembered conversations work well for developers. Customers work with longer time horizons, and want a longer lifetime for the ideas that they’ve paid for. For ideas to persist they have to be recorded in some permanent and reproducible medium. In this respect, writing code and writing documentation are not that different