When I think of agile documentation, I cringe.
Back when I went to school, we studied Computer Science as that was the only major offered on the curriculum in the IT domain. Then, someone realized that we needed Software Engineering, because developing software successfully meant more than implementing a binary sort or some other algorithm with some lines of code and shipping it to customers. We had to “elicit requirements” and what not. This took place in the mid-80’s when the Software Engineering Institute (SEI) was established and began to develop CMM, now called CMMI — the process-oriented standard mostly targeted toward government procurements, but also implemented widely in the commercial domain. One of the goals of the CMM was to document processes and product attributes so that the purchaser, or customer (Federal government at that point in time) could take delivery of the software, understand what the software did, and be able to fix it if things went wrong. These were long-haul IT projects with projected life-spans of 5-10 years.
Since that time, software engineering has blossomed as a field of its own and we have the methodology called Agile that sprung to life in the mid-90’s and was written down via the Agile Manifesto in 2001. One of the hot buttons in the industry lately is agile documentation. How much is needed if at all? I can certainly see where the “no documentation” viewpoint comes from. Documentation slows us down, and if it brings no direct value to the end user, then don’t do it (one of the guiding principles of Agile). In this light, we should limit or have no test cases and no written defects. We should either write stuff down on yellow sticky pads to remember it or keep it in our heads.
For all those who claim Agile requires no documentation or even limited and sparse documentation, this is where I take a stand. Agile absolutely requires documentation — just less than the SEI-CMM days. We aren’t trying to get certified for some government procurement, but we need to be practical and have documentation. Here’s why:
We forget. AND we quit and move on to other jobs and want to leave the next person enough information to get started, whether it is requirements, test cases, comments in code, defects, etc.
“Enough information to get started” is up to you and your organization.