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.
Big up-front design has little place in agile. All too often these designs delay the start of coding and fail to deliver the promised benefits. Agile should instead embrace an emergent design principle that appears most clearly in the refactoring process, where developers improve the design of working code. Design is omnipresent in agile, and it's not just relegated to the beginning of the project.

4. Agile means no planning.
Again, this myth is another “no.” Agile probably requires more planning on part of a team. Again, planning is spread throughout the whole development exercise rather than at the front, and it involves the work of everybody rather than one or two anointed individuals.

As with design—which is itself a form of planning—agile teams don't need big up-front planning. In my experience such plans are hostages to fortune as they become quickly dated and require updating. But customers, sponsors, and other stakeholders hold plans against teams. For example, a plan might require that X needs to be delivered on a particular date; any deviation from this plan may be seen by stakeholders, governance committees, and project management officers as a failure on the part the team, not a failure of the plan itself.

Nor does lacking a big up-front plan mean you don’t need long-term planning. Most agile teams get proficient at doing just enough design during the two-week sprint/iteration planning stages. These collective plans are produced by the development team in co-operation with other stakeholders.

In my experience, many teams struggle to plan for the future. I like to see a rough sketch from the product owner, business analyst, or product manager of what he hopes to ask the team for over the next quarter, typically six iterations but no further. Often called "release plans," these plans are probably better termed as "quarter plans" or "product plans." Such plans can utilise rough estimates and velocity calculations but do not represent firm commitments.

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

I have two rules for a user story or any other kind of development story: First, it should be small enough to be delivered sometime soon, i.e. it will not take months and months; Second, it has business value in its own right, i.e. someone somewhere can say why it is valuable, and, ideally, they can write a dollar amount on it.

These two rules often serve to drive the story size in different directions. This only serves to highlight the important role the requirements people have in finding truly valuable work.

The size of a story is often a function of the experience and knowledge of a development team. When team members lack domain knowledge, they request more and more detail. While this may increase the number of words on a story card, it often serves to make the functionality of the item under development smaller.

Conversely, team members with experience and knowledge in the domain don’t tend to need too many words of explanation—on the card, in a conversation, or as acceptance criteria—and can deliver large chunks of work.

6. Work must fit in a sprint.
If you are doing hardcore Scrum then yes, each story should start and end inside the same sprint. But not all teams practice hardcore Scrum. Many teams allow stories to overlap or break the stories down in some way. Personally, I advise teams to break business-focussed stories down to development tasks.
If you are playing agile the way I do (which I call Xanpan), I encourage sprint-spanning stories in order to improve flow. I allow for stories that span sprints but I won’t let them continue forever (Three sprints and you’re out!). Additionally, my teams try and break sprints down into smaller pieces of work.

All that said, small stories are far better than large stories, but you need to get good at writing small stories that fit within two-week sprints. The "complete-within-the-sprint" rule can be an effective way of forcing teams to get away from stories that are too large. While this rule is fine to aspire to, it is something that requires practice and learning on your part. It isn't something you can do on your first day of agile or even after a few days spent on an agile course .

7. Developers get to do what they like.
No, developers do not get to do what they like. If this is true for you then you are doing it wrong. Agile needs well-disciplined teams. What gets done should be lead from a specific role, usually designated the customer or product owner. If developers are doing what they like then there is a good chance something is wrong with that role, the person playing it, or the authority vested in it.

It seems to me that the business-side sometimes feel as if developers get to do what they like because they fail to grasp the nature of agile, which is a collaborative process they involves discussion and negotiation between those who are building the system and those who requested the system.

8. Scrum and Kanban are sworn enemies.
Some individuals get a lot of eyeballs by saying that Scrum and kanban are sworn enemies. A cynic might even say the marketing efforts behind both methods might view the image of competition as a useful publicity tool.

In my experience, many teams are combining ideas from the iterative methods (Scrum and XP) with ideas from kanban. One combination, ScrumBan, was described by Corey Ladas four years ago and I continue to evolve my own Xanpan method. (In case you haven't guest it, Xanpan is a fusion of XP and Kanban.)

9. Agile doesn’t work for fixed deadline projects.
Agile works best in fixed-deadline project environments. When team members use agile, particularly the Scrum and XP versions, they receive much of their power from the harnessing deadline effects: sizing work to the deadline, individual motivation and willingness to renegotiate just what is being built to meet a date.

A corollary to this is that agile methods are also very good for fixed-price work since costs are overwhelmingly wages multiplied by time.

10. Agile doesn’t work on Brownfield projects.
Agile works best in environments where something already exists, so-called Brownfield work. On a Greenfield effort—one with no existing codebase—first base is a walking skeleton, a bare-bones system that works end to end. Brownfield projects start with a working system in place.

Granted it's harder to retrofit automated tests to a existing system than creating tests for a new system, but it is far from insurmountable.

11. Agile doesn’t work on Greenfield projects.
While it’s a myth that agile doesn’t work on Greenfield projects, remember that your first objective is to get yourself to a steady state where you can think like you are operating on a Brownfield project.

Believe it or not, for every two people I meet who tell me "I can see how agile will work for Greenfield projects, but we have an existing system," I meet someone who holds the reverse point of view.

Automated testing in a Greenfield environment is easier, but the fact that no codebase or working product currently exists to begin with presents its own challenge. There is often an "all-or-nothing" mentality among developers and managers that needs to be overcome. Additionally, many developers are concerned with the need to design and architect. It can be hard to accept evolving, emergent design until one has experienced it.
12. Now is not the right time.
I am regularly told excuses like "We like the sound of agile, but we are in the middle of___. When we get finished, we will___"; "Agile will not work for us because ___"; and "Agile is a good idea but___.“

You can always talk yourself out of agile or find a good reason for not doing it today. I believe the time to change is as soon as you decide it genuinely is better to do so. In my mind, the ideal project to start an agile initiative with is a Brownfield system with a fixed deadline in about three to six months when development has started but requirements are still unclear.

There you go, These are the twelve myths I keep encountering. Maybe you've seen some of them or maybe you've seen some of your own. Hopefully now that I've debunked them publically, I—and others—should not have to spend quite so much time debunking them in private.