Documentation is an important part of every system, regardless of the paradigm followed to develop that system. Although agilists are sometimes maligned for what is perceived to be their cavalier attitude towards documentation, the fact is that we take documentation very seriously. Agilists adhere to the philosophy that your team's primary goal is to develop software, a message that sometime drowns out its sister philosophy that a project team's secondary goal is to enable the next effort. Because the "next effort" typically involves running, supporting, operating, and maintaining the system, chances are incredibly good that you're going to need to write some documentation along the way. It's possible to do so in an agile manner, and this month, I explore strategies for doing exactly this.
For some reason, the agile community seems to struggle to describe how we approach documentation. There are several explanations for this. First, the majority of agile developers prefer to focus on technical practices (such as regression testing, refactoring, and continuous integration) instead of "softer" practices (such as modeling, documentation, and governance). Hence, we talk about those things a lot more. Second, because the agile community is growing quickly, we have large numbers of novices who are in the early stages of learning—in their exuberance, they are all too eager to share their misperceptions with others, and a common misperception is that agilists don't document. Third, modeling and documentation practices weren't explicit in most first-generation agile methodologies, unlike second generation agile methods such as Open Unified Process (OpenUP) and Microsoft Solutions Framework (MSF) for Agile.
