Agile Modeling Logo

The Practices of Agile Modeling (AM)

Agile Modeling (AM) defines a collection of core and supplementary practices, based on the principles of AM. Some of the practices have been adopted from extreme Programming (XP) and are well documented in Extreme Programming Explained. As with AM's Principles, the practices are presented with a focus on modeling efforts so material adopted from XP may be presented in a different light.

The AM practices are organized into two lists, core practices which you must adopt to be able to claim that you're truly taking an Agile Model Driven Development (AMDD) approach and supplementary practices which you should consider tailoring into your software process to meet the exact needs of your environment. There are also some really good ideas which you should consider adopting but which aren't part of AMDD. In January 2005 I added a third list, deprecated practices which I've decided to remove in the second release of the AMDD methodology in order to simplify it.


Core Practices Supplementary Practices


Core Practices:


Supplementary Practices:

  • Apply Modeling Standards. This practice is renamed from XP's Coding Standards, the basic idea is that developers should agree to and follow a common set of modeling standards on a software initiative. Just like there is value in following common coding conventions, clean code that follows your chosen coding guidelines is easier to understand and evolve than code that doesn't, there is similar value in following common modeling conventions. There is a wide variety of common modeling standards available to you, including the Object Management Group's Unified Modeling Language (UML) which defines the notation and semantics for common object-oriented models. The UML provides a good start but it isn't sufficient -- as you can see in Be Realistic About The UML not all possible modeling artifacts are encompassed by the UML. Furthermore, it says nothing about modeling style guidelines to create clean-looking diagrams. What is the difference between a style guideline and a standards. WRT to source code, a standard would be to name attributes in the format attributeName whereas a style guideline is to indent the code within a control structure (an if statement, a loop, ...) by one unit. WRT to models, a standard would be to use a square rectangle to model a class on a class diagram and a style guideline would be to have subclasses placed on diagrams to the south of their superclasses.
Elements of UML 2.0 Style
  • Apply Patterns Gently. Effective modelers learn and then appropriately apply common architectural, design and analysis patterns in their models. However, as Martin Fowler points out in Is Design Dead? developers should consider easing into the application of a pattern, to apply it gently. This reflects the value of simplicity. In other words, if you SUSPECT that a pattern applies you should model it in such a way as to implement the minimal amount you need today but that makes it easy to refactor it later when it is clear that applying the full-fledged pattern is in fact the simplest approach possible. In other words, don't over model. For example, you may recognize a good spot in your design to apply the GoF's Strategy pattern, but at the current moment you only have two algorithms to implement. The simplest approach might be to encapsulate each strategy in its own class and build an operation that chooses them appropriately and passes them the appropriate input. This is a partial implementation of Strategy that leaves you in a position to refactor your design if more algorithms need to be implemented, yet does not require you to build all the scaffolding that Strategy requires -- an approach that enables you to ease into application of the pattern.
Refactoring to Patterns
  • Discard Temporary Models. The vast majority of the models that you create are temporary/working models -- design sketches, low fidelity prototypes, index cards, potential architecture/design alternatives, and so on -- models that have fulfilled their purpose but no longer add value now that they have done so. Models quickly become out of sync with the code, and there is nothing wrong with that. You must then make the decision to synchronize the models if doing so adds value to your team or to simply discard them because the investment to update the models won't be recouped by the value of having done so (there's negative payback). This practice is particularly important for agile documentation.
Agile Documentation
  • Formalize Contract Models. Contract models are often required when an external group controls an information resource that your system requires, such as a database, legacy application or information service. A contract model is something that both parties should mutually agree to and mutually change over time if required. Examples of contract models include the detailed documentation of an application programming interface (API), a file layout description, an XML DTD or a physical data model describing a shared database. As with a legal contract, a contract model often requires you to invest significant resources to develop and maintain the contract to ensure that it's accurate and sufficiently detailed. Your goal is to minimize the number of contract models for your system to conform to the XP principle of traveling light. Note that you will almost always use an electronic tool to develop a contract model because the model must be maintained over time.
Converation and Community
  • Update Only When It Hurts. You should update a model only when you absolutely need to, when not having the model updated is more painful than the effort of updating it. With this approach you discover that you update a smaller number of models than you would have in the past because the reality is that your models don't have to be perfect to provide value. The street map that I have to my town is over five years old, I know this because my own street doesn't appear on it and it's been in place for a little over five years, yet the map is still useful to me. Yes, I could purchase an updated map, one comes out every year, but why bother? Missing a few streets isn't painful enough to warrant this investment, it simply doesn't make sense to spend the money to purchase a new map every year when the one that I have is good enough. Too much time and money is wasted trying to keep models and documents in sync with source code, an impossible task to begin with, time and money that could be better spent developing new software. This practice is particularly important for agile documentation.
KANBAN

Really Good Ideas:

The following practices are complementary to AM but are not explicitly included as a part of it:

Practices Deprecated From Agile Modeling Version 1

To simplify AM, I chose to remove several practices in January of 2005. Although these are still valid ideas which are not going away, they won't be considered "first order practices" anymore. I found over the years that as I training and mentored people in AMDD that I didn't need to discuss them very much for people to understand the approach. The practices which I removed are:

v1 Practice Description Reason for Removal
Consider Testability When you are modeling you should be constantly asking yourself "How are we going to test this?" because if you can't test the software that you are building you shouldn't be building it. Modern software processes include testing and quality assurance activities throughout the entire lifecycle, and some even promote the concept of writing tests first before writing software (this is an XP practice). Although this is a great idea but when you're taking a TDD approach, which most agilists do, along with an AMDD approach you find that this practice becomes moot.
Model To Communicate One reason to model is to communicate with people external to your team or to create a contract model. Because the customers for some models are outside your team, you may need to invest the time to make your model(s) look "pretty" by using electronic tools such as word processors, drawing packages or even sophisticated CASE tools. This is a great motivator for modeling, but not really a practice, therefore I deprecated it.
Model To Understand The most important application of modeling is to explore the problem space, to identify and analyze the requirements for the system, or to compare and contrast potential design alternatives to identify the potentially most simple solution that meets the requirements. Following this practice you often develop small, simple diagrams that focuses on one aspect of your software, such as the lifecycle of a class or the flow between screens, diagrams that you often throwaway once you are finished with them. I removed this for the same reasons that I removed modeling to communicate.
Reuse Existing Resources There is a wealth of information that agile modelers can take advantage from. For example, perhaps some analysis or design patterns are appropriate for you to apply gently to your system. Or perhaps you can take advantage of an existing enterprise requirements model, business process models, physical data models or even models of how systems are currently deployed within your user community. It's true that these models either don't exist or are out of date in many organizations, although you're often likely to uncover reasonably accurate models with a bit of research. This is a great idea which all developers should practice, but it's a general concept which goes beyond modeling and documentation.


Translations