Agile Manifesto value #2 — Working Software over Comprehensive Documentation

Misperceptions about Agile persist despite the decade and a half since the creation of the Agile Manifesto for Software Development. These stubborn myths sometimes block serious consideration of Agile as a legitimate approach to product development. Just this week, I had yet another student express frustration that the general opinion at his workplace was that Agile would never work for them because there’s no documentation. Where, you might ask, did the idea that Agile means no documentation come from?

Often, these misunderstandings are born of a misreading of the Manifesto. The most common misreading is to substitute the words “instead of” in place of “over” in each of the value statements. Can you imagine sustainable product development in an environment where there was no process? Interactions between individuals would be anarchy. Central to Agile is the idea that process and tools exist to serve individuals and interactions, not the other way around. Nowhere does the Manifesto state that we should dispense with process and tools. Likewise, a misreading of the second value to mean no documentation would likely quickly lead to the software not working.

The first 2 values illustrate what makes Agile so difficult to implement. Agile doesn’t tell you what process or tools to use. Nor does it tell you what documentation you need to ensure that your software works at deployment and years hence. A quick glance at the Agile Manifesto reveals that it lists no practices at all. This lack of prescription can lead someone unfamiliar with Agile to conclude that Agile means no process, no documentation.

Ultimately, your Agile teams need to determine their own process — one that works for them and is best suited to accomplish the needs of your customers and your organization. The same is true for documentation. Creating the right documentation requires asking of those who will use the documentation what they need to make the product work, documenting to that standard, and testing the documentation to ensure it makes the product work.

Agile doesn’t provide the answers to the questions “What process?” or “What documentation?”, it asks the questions. It’s up to you and your teams to figure out the answers that are the right ones for you.