Myt #1: När man jobbar agilt struntar man i att dokumentera

One of the most common misconceptions I encounter when working with new teams or their managers is that agile "methods" are disorganised and chaotic. This could not be further from the truth, as a matter of fact many agile "methods" are very strict in their implementation. Scrum and Extreme Programming for instance come with very clear sets of practices, and if you are not doing them, then you are not actually doing that method you are just stealing the name.
One of the biggest causes of the chaotic misconception is a line from the Agile Manifesto:

"Working software over comprehensive documentation"
Which is commonly translated to:
"In Scrum we don't have documentation"

This is a mistranslation. The above line is simply saying that working software usually brings more value to our customers than documentation. It is not saying that documentation is never of value, it simply helps us make sure we focus on delivering value with our work, instead of doing things "just because the process mandates it".

This "mistranslation" is of course happening on purpose many times. Often team members use the transition to agile as a method to get rid of an activity they have always hated, documentation. At the other end of the spectrum, project managers who may be concerned about the transition use this "mistranslation" as a way of justifying why agile is a bad idea.

My view on this is very simple, I translate it to "We only create documents that add value to the product”. Often times we create massive amounts of documentation for a project, some bring value, but too often the motivation for this is simple, it's to "cover our butts". You know what these documents look like, they are really big, no one ever actually reads more than just the summary page and then everyone in charge signs the document saying they agree with it, and then it's put on the shelf to gather dust. Basically, these documents are created so when we run in to trouble later on someone can take this document and say "it's not my fault because you agreed to it". But, not being to blame does nothing to actually address the issue we encountered.
So, when I am considering creating a document I ask myself a few simple questions:

1) Is someone going to actually read this document?
2) If so, will what I am writing now save them time, energy and money when that happens?
3) If so, is a document the most effective way of accomplishing the desired goal?

If the answer to these questions is yes, then I consider that a document worth writing.
If not, it's time to examine why I thought a document was needed in the first place.

As with many things, the question is one of balance. One extreme or the other is not correct, both can cost more than the value they deliver. You need to constantly work to determine what the "correct" level of documentation is for your context.

I am calling this myth busted!

Informators new line-up of Agile courses is helping people to see through the myths!
Have a look at: http://informator.se/utbildningar/agila-metoder