I deliver a lot of agile training courses and I give a lot of talks about agile. It sometimes surprises me that there are still people out there who haven't heard of agile or who only vaguely understand what it is. I guess that just demonstrates the size of the software development world.
There are some questions that come up again and again that are the result of myths people have come to believe about agile. Consequently, I spend my time debunking these myths again and again.
I’ve been keeping a little list and there are a dozen reoccurring myths that seem to underlie various questions. I say "myths" because they all seem to come from either a partial understanding of agile or a complete misunderstanding of the methodology. Of course, if you've worked agile, knocked around the agile community for a while, or been to a conference or two some of these might come as a surprise. But these are the misunderstandings I hear again and again.
1. Agile is new.
No, agile is not new. The Agile Manifesto was published in 2001; the Scrum Pattern language was presented in 1995 during the Object Oriented Programming, Systems, and Languages (OOPSLA) conference; the Episodes pattern language (the forerunner of Extreme Programming—XP) was described in PLoP 1995, Tom Gilb’s Evo method dates back to 1976, and there are some who trace agile’s roots back further still.
In fact, a close look at the report from the 1968 NATO conference on software engineering reveals some familiar ideas. Professor Alan Perlis closed one debate saying:
"Through successive repetitions of this process of interlaced testing and design the model ultimately becomes the software system itself. I think that it is the key of the approach that has been suggested, that there is no such question as testing things after the fact"
That sounds like a pretty good description of much of agile to me, thirty-three years before the Agile Manifesto.
2. Agile means having no documentation.
While some people believe that being agile means one doesn’t need any documentation, that’s hardly the truth; you can have as much documentation as you like in agile. Documentation is just another deliverable; if it brings you value then schedule it and produce it like anything else.
This myth may have started with Kent Beck, the originator of Extreme Programming, who is reported to have said "Documentation may be only necessary before I die and can't explain it personally."
However, there is both unnecessary documentation and valuable documentation; the trick is to decide which is which.
Still, lets not hide it: Agile probably does mean less documentation. In his 2008 book, Applied Software Measurement, Capers Jones says "For large software projects, the cost of producing paper documents is more expensive than the code itself."
Unfortunately, documentation is not just a cost, it is sometimes a block to communication as people might hide behind documents when a conversation or an example might be much more informative.
If someone is willing to pay for a document, then it has value and should be scheduled and developed the same way code is.
3. Agile means “no design.”
No, being agile does not mean that there should be “no design.” I think for one to practice agile, one probably needs more design. Design is inherent all the way through development, at every planning meeting, and more. In regards to this myth, however, agile does mean that you don’t need a big up-front design that is invalidated five minutes after someone starts coding.