A Look Behind the Curtain: Debunking 12 Myths of Agile Development
By Allan Kelly

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.

Some of the questions that come up again and again are the result of myths people have come to believe about agile. Consequently, I spend a lot of my time debunking these myths.

I’ve made a list of a dozen of these recurring myths. I say "myths" because they all seem to come from either a partial understanding or a complete misunderstanding of agile. Of course, if you've worked in agile, knocked around the agile community for a while, or been to an agile conference or two, you might be surprised that some of these problems exist. Yet, these are the misunderstandings I hear frequently.

1. Agile is 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 Pattern Languages of Program Design 1995. [1] Tom Gilb’s Evo method [2] 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 [3] 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 has questioned the need for documentation in rather extreme language. (See Nico Josuttis's interview with Beck for an example. [4]) Over time, this myth seems to have grown to encompass all documentation in all cases.

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 writes, "For large software projects, the cost of producing paper documents is more expensive than the code itself." [5]
Unfortunately, sometimes documentation is not just a cost but also 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 that code is.

3. Agile means no design.
To practice agile, one probably needs more design. Design is inherent all the way through development, at every planning meeting and more. Regarding this myth, however, agile does mean that you don’t need a big, up-front design that will be 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.
Agile probably requires more planning on the part of a team, too. 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 quickly become 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. Stakeholders, governance committees, and project management officers may see any deviation from this plan as a failure on the part the team, not a failure of the plan itself.

Nor does lacking a big, up-front plan mean that you don’t need long-term planning. Most agile teams get proficient at doing just enough design during the two-week sprint- or iteration-planning stages. The development team produces these collective plans 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 showing 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 utilize rough estimates and velocity calculations but do not represent firm commitments.

5. There is a 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, can write a dollar amount on it.

These two rules often serve to drive the story size in different directions. This only highlights the important role that 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 decrease the functionality of the item under development.

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-focused stories down to development tasks.

In the way I play agile, which I call “Xanpan” (a fusion of XP and kanban), 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 to break down sprints 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 in an agile course.

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

It seems to me that people on the business side sometimes believe this myth because they fail to grasp the nature of agile, which is a collaborative process that involves discussion and negotiation between those who are building the system and those who requested it.

8. Scrum and kanban are sworn enemies.
Some individuals acquire a lot of eyeballs by saying that Scrum and kanban are sworn enemies. A cynic might even say that the marketing efforts behind both methods 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. Corey Ladas described one combination, ScrumBan, four years ago, and I continue to evolve my own Xanpan method.
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, because 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 barebones 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 to create 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 say, "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 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 regularly hear excuses like "We like the sound of agile, but we are in the middle of …"; "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 that 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 of about three to six months, when development has started but requirements are still unclear.

These are the twelve myths I keep encountering. Maybe you've seen some of them, or maybe you've seen some of your own. Now that I've debunked them publicly, hopefully we will not have to spend quite so much time debunking them in private.

Sticky Notes
References
1. http://wiki3.cosc.canterbury.ac.nz/index.php/PLoP_1995
2. http://www.gilb.com/Project-Management
3. http://en.wikipedia.org/wiki/Software_engineering
4. http://accu.org/index.php/journals/509
5. Jones, 2008, Applied Software Measurement, Third Edition, McGraw-Hill