Top Twelve Myths of Agile Development

[article]
Summary:
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.

Pages

User Comments

3 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

About the author

Allan Kelly's picture Allan Kelly

Allan Kelly has held just about every job in the software world, from system admin to development manager by way of programmer and product manager.  Today he works helping teams adopt and deepen Agile practices, and writing far too much.  He specialises in working with software product companies and aligning products and processes with company strategy.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!