11 Agile Myths and 2 Truths
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 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.
- 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).
- 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.
- 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.
- 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
- 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.
- 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.
- 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.
- Agile doesn’t work for fixed deadline projects: No, Agile works best in fixed deadline project environments.
- 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.
- 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.
- Now two truths about Agile:
- Agile will not work for us because… (complete this sentence for yourself)
- 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
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)