views:

1205

answers:

16

What are the myths or misconceptions related to Agile?

There are lot of misconceptions related to Agile that an average new comer may fall into. What are the misconceptions in the Agile world and how do you justify that it is truly a misconception?


Update: Summary of Agile Myths

  • Agile doesn't allow documentation
  • Agile methods do not scale
  • Agile means no plan
  • TDD covers all the unit testing needs
  • Pair programming always results in better code
  • Agile is a silver bullet solution to software engineering problems (There is a silver bullet solution)
  • Agile doesn't need up front design
  • We're doing scrum so we don't need to do TDD, Refactoring Pair Programming, etc.
  • One can learn Agile from a book
  • Agile only works for trivial projects
  • Agile always uses "User Stories"

Read the following answers for more information about above myths and for more myths.

+13  A: 

"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...

IanR
+1 This is so very true, anyone who rushes into a project expecting that this is true is in for a nasty surprise.
Jay
Agile uses "User Stories" instead of documentation during the construction phase. For example QA can work with user stories very well as they define a testable feature. With that said, what agile says is that you shouldn't spend time to create documentation during the construction phase where they tend to change. Instead "Document as late as possible". It is perfectly OK with agile to create documents for maintenance and business perposes.
Varuna
It also means you *do* write design docs (of whatever sort), not just jump in willy-nilly.
Richard Levasseur
Myth: Agile (always) uses "User stories"!
Pascal Thivent
+9  A: 

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.

RickNZ
I knew there was a reason that I don't like agile, and you pegged it. Programming is at once both a team and isolated activity. You work as part of a team while you are by yourself.
Ken Lange
I do not think he means pair programming never works.In any case that would be wrong. With the right match pair programming works very well. Check the wikipedia article on the subject, it references proper studies, not just random opinions.Also pair programming is not really related to agile development.
Lillemanden
You're right, I don't mean that it never works. What I'm saying is that establishing it as a project-wide must-do policy tends to be a bad idea. Pair programming is definitely considered a standard agile development practice; even Wikipedia agrees on that.
RickNZ
+1, and I am a fan of both. The first one is especially important: lots of bad tests could arguably be considered worse than no test...
Mathias
@RickNZ - I stand corrected, apparently pair programming is considered a standard agile tool. Though you can still use it if you go waterfall.
Lillemanden
"Slightly anti-social"? Them's fightin' words! Come'ere so I can roundhouse kick you through a house.
Juliet
@Ken Lange - agile does not necessarily mean using pair programming - pair programming is normally more specifically associated with the XP flavour of agile
Cocowalla
+13  A: 

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

Jason Punyon
Myth: there is a silver bullet solution to software engineering problems.
Jeremy McGee
+1  A: 

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".

S.Lott
You have to do enough... What is enough, well that depends on your projects and teams. The discussions in your retrospectives should give you a clue as to whether you aren't doing enough (problems/challenges/inefficiencies) or too little (goes fine, but lots of hours in planning). Continuously adjust.
Jim Rush
+3  A: 

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.

Wade Williams
How does an extreme waterfall project fail on budget or time? Do you mean fail before a line of code is written?
Lillemanden
I think Wade means that if you spend too long designing an application it can fail because you spend all your resources planning rather than coding. Also, if you've spent too long specifying every possible part of the application, where an application will undoubtedly change from specification during development, you may not have time to find solutions to the problems which do not present themselves in the design stage. This is only in extreme cases as Wade mentioned above.
Jay
+3  A: 

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.

Jay
"thought out properly" Same goes for /all/ of Agile, it works best with good, open-minded developers who think about and refine what they do.
Jeremy McGee
+5  A: 

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

Chris Simmons
So you are saying 'design as you go' is just as good?
leppie
@leppie: Are you saying that "only think about your design once" is just as good? I don't know about you, but on every project I've worked on, I've known more about the space at the end of it than the beginning...
kyoryu
I'm saying that in most of the cases, design as you go is better. The key is not making too many irreversible decisions before you have enough data. If you don't know whether or not you need to go with SQL Lite or Oracle, and you won't know until 3 months into the project, abstract out the database.
Chris Simmons
+7  A: 
  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

cartoonfox
LOL at the #1! Never heard about this one (except in the mouth of anti Scrum guys).
Pascal Thivent
As far as #5, I like to call that the difference between little-a agile and big-A Agile.
kyoryu
I don't understand this "big/little" agile thing. It's never had a specific meaning, just a set of things we prefer over other things.
cartoonfox
+1  A: 

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.

Pavel Minaev
A: 

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.

julian_t
A: 

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.

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

Tim
+6  A: 

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+

Pascal Thivent
Do you have some references for the cases you mentioned that Scrum have been used? It would improve this thread!
GmonC
This is taken from the CSM course and is mentioned in Mike Cohn's Intro to Scrum too (see http://www.mountaingoatsoftware.com/presentations/30-an-overview-of-scrum-january---in).
Pascal Thivent
You beat me to the no discipline/more discipline point!
kyoryu
Do you have examples of large projects where Agile worked well?
Jess
A: 

Myth: Agile means XP and Scrum

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

Varuna
have you tried OpenUP? in my opinion it's a document heavy beast with some iteration stuff thrown in to it and then labeled agile so that people can continue to use there old way of working but call it agile.
Carl Hörberg
+1  A: 

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.

M1EK
A: 

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.

Carl Hörberg
This is related to the myth "Agile doesn't need up front design". Agile don't prohibit analyzing/designing just enough to know the scope to give customer a fixed price.
Varuna
A: 

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.

AviD