Through discussions on public mailing lists and newsgroups as well as working closely with my company’s clients, I have already met several people who held some disturbing misconceptions regarding AM. To be fair, my description of AM at the time often wasn’t complete and this book obviously wasn’t available yet. However, I’m still concerned enough to address these misconceptions here because I suspect they will continue to crop up. The misconceptions that I have observed include:

1. Misconception #1: Business analysts, architects, and other specialized modelers are disallowed. The reality is that AM does in fact prefer that developers are generalizing specialists but does not require it. Specialists such as business analysts can be quite effective when you need someone to work with stakeholders at a site distant from the development team and architecture experts can be useful at the beginning of an initiative to help you identify a candidate architecture.
2. Misconception #2: You can’t/don’t review agile models. There is no reason why you cannot review an agile model or document for that matter, although if you’re following the AM practices appropriately you may find that the reviews don’t offer much value. The reviewers need to set their expectations accordingly, remembering that Content Is More Important That Representation, and you want to organize the review meeting so that it is effective. For further discussion regarding review of agile models, read Validating Agile Models and Model Reviews: Best Practice or Process Smell?
3. Misconception #3: AM is carved in stone. The reality is that this is partially true because at a minimum you need to adopt AM’s core practices to claim an AM approach to development. However, there is significant leeway in the way that you follow these practices. For example AM suggests that you Apply The Right Artifact(s) but doesn’t tell you what the right artifacts are. Some suggestions are provided in the article Agile Modeling Artifacts.
4. Misconception #4: You don’t use CASE tools. Agile modelers follow the practice Use The Simplest Tools, and sometimes the simplest tool for the job is in fact a CASE tool. See the article Simple Tools or CASE Tools? and Comparing the Various Approaches to Modeling in Software Development.
5. Misconception #5: Agile modelers are highly skilled “super developers”. Having a wide range of modeling experience certainly helps, but it isn’t a requirement. It can be your first day on the job as a developer and you can still follow the principles and practices of AM. It’s far more important to be willing to work with others and to learn new skills–anyone willing to do so can become an agile modeler. Agile modelers are, however, usually generalizing specialists.