I am a firm believer that when you are describing the scope of something, be it a system or in the case of AM a methodology, that you should describe both what it is and what it isn’t. The following points describe the scope of AM:
AM is an attitude, not a prescriptive process. AM comprises a collection of values that agile modelers adhere to, principles that agile modelers believe in, and practices that agile modelers apply. AM describes a style of modeling, when used properly in agile environments, that results in better quality software and faster development while avoiding over-simplification and unrealistic expectations. AM is not cookbook approach to development – if you’re looking for detailed instructions for creating Unified Modeling Language (UML) sequence diagrams or drawing user interface flow diagrams then you need to pick up one of the many modeling books listed in the article Modeling Artifacts. In particular I highly suggest my own bookThe Object Primer 3/e (although naturally I’m biased).
AM is a supplement to existing methods, it is not a complete methodology. The primary focus of AM is on modeling and its secondary focus is on documentation. That’s it. AM techniques should be used to enhance modeling efforts of teams following agile methodologies such as XP, Disciplined Agile Delivery (DAD), and Feature Driven Development (FDD). AM can also be used with prescriptive processes although will not be as successful the less agile the process is.
3. AM is a way to work together effectively to meet the needs of stakeholders. Agile developers work as a team with their stakeholders, who in turn take a direct and active role in the development of the system.
4. AM is effective and is about being effective. As you read more about AM one of the things that should become poignant to you is AM’s ruthless focus on being effective. AM tells you to maximize the investment of your stakeholders, to create a model or document when you have a clear purpose and understand the needs of its audience, to apply the right artifacts to address the situation at hand, and to create simple models whenever you can.
5. AM is something that works in practice, it isn’t an academic theory. The goal of AM is to describe techniques for modeling systems in an effective manner, one that is both efficient and sufficient for the task at hand. These techniques have been examined and discussed by several thousand modeling practitioners.
6. AM is not a silver bullet. Agile modeling is an effective technique for improving the software development efforts of many professionals. That’s it, nothing more. It isn’t magic snake oil that will solve all of your development problems. If you work hard; if you stay focused; if you take AM’s values, principles, and practices to heart; then you will likely improve your effectiveness as a developer.
7. AM is for the average developer, but is not a replacement for competent people. AM’s values, principles, and practices are straightforward, many of which you have likely been following or wish you had been following for years. You don’t have to walk on water to be able to apply AM’s techniques, but you do need to have basic software development skills. The hardest thing about AM is that it prods you to learn a wide range of modeling techniques, a long and continuing activity. Learning to model can seem difficult at first, and it is, but you can do it you choose to learn a technique at a time. Having said that, the best developers are generalizing specialists.
8. AM is not an attack on documentation. Agile modelers create documentation that maximizes their investment in its creation and maintenance. Agile documentation is as simple as possible, as minimal as possible, has a distinct purpose that is directly related to the system being developed, and has a defined audience whose needs are understood.
9. AM is not an attack on CASE tools. Agile modelers use tools that provide positive value by helping to make then more effective as a developer. Furthermore, they always strive to use the simplest tool that gets the job done, and sometimes that’s a sophisticated CASE tool.
10. AM is not for everyone. More on this in When Does(n’t) Agile Modeling Make Sense?.