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
- 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 role.
- 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.
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. 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
You can always talk yourself out of it or find a good reason for not doing it today.
Reference: 11 Agile Myths and 2 Truths from our JCG partner Allan Kelly at the allan’s blog – Agile, Lean, Patterns blog.
Would you elaborate more on item 9? In which way it works best? How?
For startup projects agile is not good, also agile team members should be all seniors.
I did not find any reason for use agile, because of traditional team with team leader better
#2 Says who? If you work in IT Operations and don’t read documentation, you really should find some other line of work.. Most documentation is for reference: Since the specs don’t always say it all, especially those delivered from agile projects, where should you look up to find out how the system is supposed to behave, ie. when something fails or has changed without notice? Projects that don’t concern themselves with IT Operations are a burden on every company. #9 If you have a FIXED DEAD-line, the project is NOT flexible, thus results are not optimal according to business needs… Read more »