Agile Zone is brought to you in partnership with:

Allan Kelly has held just about every job in the software world, from sys admin to development manager. Today he provides training and coaching to teams in the use of Agile and Lean techniques. He is the author of "Changing Software Development: Learning to become Agile" (2008) and "Business Patterns for Software Developers" (2012) and a frequent conference speaker. Allan is a DZone MVB and is not an employee of DZone and has posted 85 posts at DZone. You can read more from them at their website. View Full User Profile

11 Agile Myths and 2 Truths

  • submit to reddit

I deliver a lot of Agile training courses and I give a lot of talks about Agile (BCS Bristol tonight). There are some questions that come up again and again which 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 11 reoccurring myths. There are also two truths which are a bit more difficult for teams and companies to accept.

Agile Myths

  1. Agile is new: No, the Agile manifesto was published in 2001, the Scrum Pattern language was works hoped at PLoP 1998, the Episodes pattern language (the forerunner of XP) was workshopped at PLoP 1995, Tom Gilb’s Evo method dates back to 1976 and there are some who trace things back further.

  2. Agile means No Documentation: 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 product it like anything else. Please be aware: documentation is often unread, often fails to communicate, is used as a defensive tool and is typically the second most expensive think on a large software project (after rework).

  3. Agile means No Design: No, Agile probably means MORE DESIGN. Design is inherent all the way through development, at every planning meeting and more. Agile does mean the end to big-up-front design which is invalidated five minutes after someone starts coding.

  4. Agile means No Planning: No, again, Agile probably has more planning. Again planning is spread out through the whole development exercise rather than at the front and it is the work of everybody rather than one or two anointed individuals.

  5. Developers get to do what they like: No, if this is true for you then you are doing it wrong, please call me. Agile needs more discipline from the team and what gets done should be lead from a specific role usually designated the Customer or Product Owner and usually played by a Product Manager or Business Analyst. If developers are doing what they like then there is a failure of in this role.

  6. There is a right size for a User Story: There is no right size for a user story. Every team is different, get over it.

  7. Work must fit in a Sprint: If you are doing Hard Core Scrum then Yes. If you are playing Agile the way I do (which I now call Xanpan) then No. In fact I advise letting stories span sprints in order to improve flow. You can have stories spanning sprints but we won’t let them continue for ever and we will try and break them down into smaller pieces of work.

  8. Scrum and Kanban are sworn enemies: No but the marketing efforts behind each they can get a lot of eyeballs by playing it that way. Xanpan is a Kanban/XP hybrid, and XP isn’t that different to Scrum so there you go.

  9. Agile doesn’t work for fixed deadline projects: No, Agile works best in fixed deadline project environments.

  10. Agile doesn’t work on Brownfield projects: No, Agile works best in brownfield environments. Granted retrofitting automated unit tests is harder but it is far from insurmountable.

  11. Agile doesn’t work on Greenfield projects: No but your first objective is to get yourself to a steady state where you can think like a brownfield project.

To my mind the ideal project to start an Agile initiative with is a brownfield system with a fixed deadline in about 3 to 6 months where development has started but requirements are still unclear.

  1. Now two truths about Agile:
  1. Agile will not work for us because… (complete this sentence for yourself)
  2. Agile is a good idea but … we should wait until we have finished X, got Y to buy in, bought Z and the (new) Pope has given it his blessing
You can always talk yourself out of it or find a good reason for not doing it today.


Published at DZone with permission of Allan Kelly, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Senthil Balakrishnan replied on Wed, 2013/02/27 - 7:41pm

Nice article, I should admit the story point is still a gray area to me. 

  1. By definition story points are based on the value a feature adds to the business.
  2. Developers estimate it by implementation effort.
  3. Management uses it to forecast/budget projections.
Strange enough :).... 

Loren Kratzke replied on Fri, 2013/03/01 - 3:59pm

 This article (a good article) and a few linked articles that I read all tell me the same thing.

The biggest failure of agile/scrum/whatever is that its definitions are loose and sloppy except when somebody is speaking about them. Then the arguments must be prefaced with the definitions as accepted by the person speaking and the message is usually strict and based on the definitions of the speaker. The same sentences in a different conversation could have a totally different meaning.

In each myth above you can substitute the word "means" for "usually results in" and the paragraphs would read accurately while being 180 degrees out of phase with the original message.

The poor definitions and wide misconceptions (caused by poor definitions) allow anybody to claim that if you fail then you are not doing it right, or if you disagree then you don't understand something, or that your problem is that you are doing Scrum and not Scrum-Scrum which is totally different than Scrum, or you are doing agile vs Agile. It really is quite a mess in my opinion.

My advice is to ban the words "scrum" and "agile" from the English language and just start over from scratch. Pick different words that have non-nebulous and unmistakeably absolute meaning, or invent some new words paired with single rigid definitions.

Clayton Passos replied on Wed, 2013/03/06 - 12:33pm

The more important, Scrum is not methology, SCRUM IS A FRAMEWORK.

Matt Avery replied on Thu, 2013/03/07 - 1:28pm in response to: Loren Kratzke

Excellent comment.  The entire paradigm is designed to be loose and open enough for someone to build a career on being an "expert" in a field in which they get to define the word "expert".

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.