Top Twelve Myths of Agile Development


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.

User Comments

Ravi BR's picture

I fully agree with you.

I used Agile methodology scrum in both development and maintenance projects. Also we did a design and documentation where ever it is required.

March 26, 2014 - 8:06am
Dave Maschek's picture

Myth #13: Agile is faster. Actually, Agile is BETTER, but not necessarily faster. Properly done, iteration planning, story writing, backlog grooming, retrospectives and standups can take considerable time. I think that this results in an improved product over the course of a number of iterations. It may be faster or slower than another development method. But our goal is creating good software, not meeting a deadline.  

April 24, 2014 - 5:15pm
Richard Paul's picture

@Dave Maschek

Agile is faster.  If it is not, then something is going wrong with how it is being done.  We had a 320% increase in productivity by our 2nd Sprint of implementation (compared to the previous method), so it was much faster.  Perhaps TDD is not happening or meetings are not as efficient as they need to be or codework is not shown to the QA role soon enough and often enough.  Cannot diagnose why without being there, but something is off.

March 30, 2016 - 2:04pm

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.