1. "We re doing Scrum - so we don t need to (pair | refactor | do TDD | ...)" Actually the Scrum founders - Ken and Jeff have been saying that all the high-productivity scrum teams implement the full range of Extreme Programming practices.

2. Test-driven development won t find all the bugs / isn t easy to apply to everything - so we re not going to try! - Learning TDD isn t an "all or nothing deal" and you get better at judging what to test and how to do it efficiently. I ve been doing it for ten years now and I m still finding better ways to do it and new things to consider.

3. I can learn all I need to apply agile methods from a book. - You need to learn by doing and that often means coaching and meeting other people that can help. Lots of things go wrong when people just try to learn it from a book.

4. Hysterical (and quite real) "The candidate must take direction from, and support the scrum master" (From a job spec I was sent last week...) - The scrum master isn t supposed to tell people what to do. He/She is there to facilitate - i.e. to help the team learn to sort things out themselves. It s a massive failure mode - having a scrum master that "commands" people!

5. Talking about "the agile methodology" - big cluelessness indicator. Firstly, talking about "agile" like it s a specific thing whereas it s a very vague umbrella terms for many different things. Secondly, use of "the" agile methodology - there are loads of them, and loads of different ways of doing many of them! Thirdly, a lot of people in the agile community got here in the backlash against the big, heavy UML-laden methods of the nineties. These people don t tend to use the word "methodology"...

6. You need especially talented people to develop software the agile way. Jeff Sutherland says that they considered using the "chief programmer team" model for managing teams in banks - but found they didn t have anything like enough "chiefs". Scrum is designed to get best productivity out of a lot of moderately able programmers. In fact removing one, disproportionately productive team member that doesn t want to help the others can "unblock" the mediocre team members and bring their combined productivity up to more than compensate for the super-productive former team member... That s what Jeff says anyway...

There are quite a few other XP-related ones that we came up with in an open space workshop that I led recently: http://xpday-london.editme.com/WhereHasXpGone

"Working software over comprehensive documentation" means you do not need a functional spec...

Wrong!!! It just means that you can iron out the wrinkles iteratively with the users - speaking as a vendor, you still need good documentation to assist with the QA and sign-off phases...

Myth: using Agile development practices is a silver bullet solution to software engineering problems.

Myth: Test-first development forces your project to have adequate unit testing.

Fact: Many developers get lazy, and the unit tests they write before their code are often weak and inadequate.

Myth: Pair programming always results in better code.

Fact: Programmers tend to be slightly anti-social and to have significantly different thought processes from one another. Having someone breathing down your neck as you code is very unpleasant, and the result is often a tense work atmosphere with a reduction in both code quality and quantity.

Myth: Agile means no documentation

Fact: Agile value working software more than comprehensive documentation but this doesn t mean no documentation at all. Documentation should be written just in time, and just enough. And no, Agile doesn t say one should always using user stories. Use them if, and only, if they are appropriate!

Myth: Agile means no plan

Fact: Agile does not support development without planning. Agile uses continuous planning and estimating to maximize the ROI. Actually, Agile is about scope management.

Myth: Agile means no discipline

Fact: Agile developers must be more disciplined for success.

Myth: Agile only works for trivial projects

Fact: Agile (actually Scrum here) has been used for

• FDA-approved, life-critical software for x-rays and MRIs,
• Financial payment applications,
• 24x7 with 99.99999% uptime requirements,
• Multi-terabyte database applications,
• etc

Myth: Agile doesn t scale

Fact: Sutherland used Scrum in groups of 500+, Cohn used Scrum in groups of 100+

Myth: "No Big Design Up Front" means no design.

Myth: Waterfall always fails.

Reality: Most of the software you re using on your agile project was developed with waterfall. Even BDUF waterfall, in many cases.

There s no real myths - but anything taken to an extreme will be wrong. An Agile project that does zero design in the hopes of "designing as it goes" will likely fail. A Waterfall project that designs everything down to the last semicolon will likely fail due to budget, time or changed user requirements.

It has been repeatedly said "Agile design methods do not scale" whereas Agile development will effectively scale to any size if implemented and thought out properly.

Myth: You need to carefully plan and schedule each sprint.

This leads you to do lots and lots of up-front planning so that you can fully plan each sprint.

This leads you to defeat agility and create a waterfall called "Agile".

The biggest myth I have seen is that people think it is better than other development processes.

It is the usual silver-bullet snake-oil that we have been seeing in this industry for years.

https://stackoverflow.com/questions/301993/is-agile-development-dead/302060#302060

Myth: Agile is always a better option when compared to other alternatives.

Fact: depending on project size, requirements (particularly flexibility of such), external schedule, and customer attitude, it may not always be more productive compared to orthodox methodology.

Myth: Agile means XP and Scrum

Fact: There are other practices like OpenUP, AMDD, etc.

It s easy to know what to charge your customer. This is alway the biggest problems for us, because we don t know the scope of the project we can t give the customer a fixed price, and most customers demands a fixed price.

Great thread. While I offer nothing new in my related blog post, I do illustrate the top two reasons why Agile fails when it does fail. 1) Lack of upfront requirements (taking the begin coding with incomplete requirements to an extreme) and 2) Lack of adequate unit tests (because CHANGE will happen - and unit tests are the quickest way of catching all the breaking points resulting from the CHANGE).

http://www.anujvarma.com/BlogEngine.net/post/2010/11/03/Agile-versus-Flat-Footed-development.aspx

You re completely right that there are a lot of myths around Agile, some coming from outside, and others from inside. Here are a few more I thought of to add to the list:

"You don t need project managers or business analysts any more"

Although we re not doing BDUF and teams are self-directing, as things scale up there is still a need for people whose job is coordinating what s going on. And if you have a very complex business scenario, you may well need someone to help you make sense of it. IME, a lot of the projects that really needed PMs and BAs still need them (and those that don t need them now, probably never needed them!). But, of course, the roles of the PMs and BAs tend to be different in the Agile world, and that can make people uneasy.

"Agile can t be used for fixed price projects"

It can, but it is quite a bit harder. Especially since we all know that "fixed price" really means "fixed price, scope and time"...

"We don t do BDUF, we do it all as we go along"

The only way to work is JEDUF (Just Enough Design Up Front). Sometimes you need more, sometimes you can get by with less, but you don t do more than you need at that point.

Myth: Agile is anti-thetical to security.

Fact: This is only true, if you try to force a full-blown waterfall-style SDL (security development lifecycle) onto supposedly Agile teams. In fact, I have designed and implemented Agile-SDL variants in numerous organizations, and I can say that putting the Agile into the Security, can actually afford a higher, more robust level of security. it just takes a change of security mindset - from control to visibility and guidance.

If you don t show real value with agile, it will fail. And fail miserably as in bankrupt a company miserably. Going to agile just because it is agile makes you look as silly as the CIO in this video:

http://www.youtube.com/watch?v=nvks70PD0Rs

John