Top Twelve Myths of Agile Development

When it comes to agile development, Allan Kelly has noticed a lot of misinformation is being passed off as fact. In this article, Allan takes a closer look at twelve of the most common agile myths he has encountered while training new agile teams.

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.


User Comments

Ravi BR's picture

I fully agree with you.

I used Agile methodology scrum in both development and maintenance projects. Also we did a design and documentation where ever it is required.

March 26, 2014 - 8:06am
Dave Maschek's picture

Myth #13: Agile is faster. Actually, Agile is BETTER, but not necessarily faster. Properly done, iteration planning, story writing, backlog grooming, retrospectives and standups can take considerable time. I think that this results in an improved product over the course of a number of iterations. It may be faster or slower than another development method. But our goal is creating good software, not meeting a deadline.  

April 24, 2014 - 5:15pm
Richard Paul's picture

@Dave Maschek

Agile is faster.  If it is not, then something is going wrong with how it is being done.  We had a 320% increase in productivity by our 2nd Sprint of implementation (compared to the previous method), so it was much faster.  Perhaps TDD is not happening or meetings are not as efficient as they need to be or codework is not shown to the QA role soon enough and often enough.  Cannot diagnose why without being there, but something is off.

March 30, 2016 - 2:04pm

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.