Scrum Implementation: What about documentation?


There appears to be a persistent myth that the Scrum framework dictates “no documentation.”

I am not exactly sure where this rumor came from, but I think it has to do with the Agile manifesto:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Somehow, people (mis)interpret this is as “Scrum says we should have no documentation and no plan.”  What this means is when we have conflict between an item on the left (working software) vs an item on the right (comprehensive documentation), we will always go to the item on the left.  After all, working software is far more valuable to your end users than comprehensive documentation.

But let’s take a deeper dive into this and talk more about documentation in the context of the Scrum framework.

What it really comes down to is value.  In most traditional software projects I have been involved with, the documentation effort starts out as a valiant one, but the documentation never seems to keep pace with the codebase.  So as a result, it gets stale and out of date.  When a new person comes into the project or the organization, and take a look at the documents, they soon find out the documents are useless and out of date.  So what do they do?  They go and talk to a person that has been involved in the project longer and get a brain dump.  Why?  Because it works better than trying to get information out of documents.

So over time, the VALUE in keeping the documents updated is diminished because they are out of date, and they are usually out of date because there are not enough people dedicated to the documentation effort.  There are usually not enough people dedicated to the documentation effort because people are expensive, and the documentation is “not that important anyway.”  So the judgement call has already been made in saying that the documentation is not valuable.  If it is not valuable, why are we working on it?  Especially when its faster to go talk to someone.

A caveat to this situation that I have seen is delivering DoD projects, where the documentation IS the deliverable and the code is an artifact of the documentation.  The paradigm is shifted, but the result is the same:  We always want to deliver something that has value to our customers, whether its documentation or working product.  The value proposition is the core principle that helps us to prioritize.

So the right question to ask is not, “What about documentation?”

The correct question to ask is, “Does what we’re doing have value to us internally or to our customers, and are we willing to invest to ensure we can create that value?”  At the end of the day companies show what they value by where they spend dollars.  They can say they value documentation but if money is not being spent to ensure the documentation is the best it can be, then there is a mismatch between the words and the actions.  Scrum helps us to uncover these mismatches and motivate the organization to align its mission, vision, principles, and actions.  In other words, put up or shut up!

There was an issue loading your timed LeadBox™. Please check plugin settings.

Leave a Reply