Scott Ambler

Position Statement

I am the Thought Leader of the Agile Modeling (AM) methodology. AM is a chaordic, practice-based methodology for effective modeling of software-based systems. The AM methodology is a collection of practices – guided by principles and values – that are meant to be applied by software professionals on a day-to-day basis. AM is not a prescriptive process, in other words it does not define detailed procedures for how to create a given type of model, instead it provides advice for how to be effective as a modeler. AM is “touchy-feely” in that it is not hard and fast – think of AM as an art, not a science.

An important concept to understand about AM is that it is not a complete software process. AM’s focus is on effective modeling and documentation. That’s it. It doesn’t include programming activities, although it will tell you to prove your models with code. It doesn’t include testing activities, although it will tell you to consider testability as you model. It doesn’t cover project management, system deployment, system operations, system support, or a myriad of other issues. Because AM’s focus in on a portion of the overall software process you need to use it with another, full-fledged process such as eXtreme Programming (XP), DSDM, SCRUM, or the Unified Process (UP). You start with a base process, such as XP or UP or perhaps even your own existing process, and then tailor it with AM (hopefully adopting all of AM) as well as other techniques as appropriate to form your own process that reflects your unique needs. Alternatively, you may decide to pick the best features from a collection of existing software processes to form your own process. For XP projects, AM explicitly describes how to improve productivity through addition of modeling activities whereas with for UP projects it describes how to streamline modeling and documentation efforts to improve productivity.

As a result, I would argue that how AM addresses the three issues listed above rely on how the underlying process addresses them. For example, with respect to architecture an XP/AM team would identify a metaphor for their system to help guide their design efforts, building architectural spikes where necessary. A RUP/AM team would focus on architectural issues during the Elaboration phase, modeling and building an architectural prototype as needed.