How the Agile Modeling Practices Fit Together

The Core Practices

Let’s examine the four categories containing the core practices:

1. Teamwork. There are four practices – Active Stakeholder Participation, Model With Others, Display Models Publicly, and Collective Ownership – in the Teamwork category. The practice Active Stakeholder Participation is critical to your success because it is your stakeholders that you are building your system for, it is these people whose requirements you need to understand and fulfill. In other words you need to work closely with your stakeholders something that is supported by the practice Model With Others – your stakeholders are included in this “others” category. When there are several people involved in a modeling effort, at least one of which should be a stakeholder and another a developer, you are in a position where you can work together synergistically by benefiting from each others strengths and counteracting each others weaknesses. An agile modeler whose expertise is in business process modeling and business rule definitions may miss information that someone with a focus on structural modeling techniques such as UML class diagrams or data models would pick up on. Similarly a direct user of your system would provide different information to your team than would senior management. The point to be made is that not only do you want to actively work with your stakeholders you want to do so in a team environment so that multiple points of view and expertise are taken into account. The practice Collective Ownership enhances teamwork because when a single person “owns” a model they quickly become a bottleneck for your modeling efforts, whereas when anyone is allowed to work on a model you can easily work on them together as a team. The practice Display Models Publicly makes it easy for people to look back and forth between the models, considering the information that the models convey all at once, and hence enhance collaborative efforts between them. This of course assumes that the models are within sight of each other, or at least the ones that you are currently working on are close to one another, a topic that I cover in greater detail in Organizing an Agile Modeling Room.
2. Iterative and Incremental. This category of AM practices includes Apply The Right Artifact(s) , Create Several Models in Parallel, Iterate To Another Artifact , and Model in Small Increments. Each artifact, no matter what it is, has its own strengths and weaknesses and no single model is sufficient to describe major aspects of your initiative such as its requirements or its architecture. For example, in Agile Requirements Modeling you will see that you often need a combination of use cases, business rule definitions, and technical requirement definitions to explore the requirements for your system. It is very unlikely that your stakeholders will tell all of their usage requirements all at once for your use cases, then switch gears to tell you about all of their business policies to be captured as business rules, then switch gears again to tell you about all of their non-functional needs that should be captured as technical requirements. Instead they’ll tell you their requirements, as they come to their minds, and will often double back on what they said earlier to provide greater details or even to change their minds. Your requirements identification efforts can often be very dynamic, and similarly so are your analysis, architecture, and design efforts. I believe the dynamism is the result of the way that people think, our brains seem to connect information in an apparently chaotic manner, the end result being that ideas seem to “pop out of thin air” or we have an “a-ha! experience”. Agile modelers recognize that people think in this dynamic manner, particularly collaborative groups of people, and act accordingly. They Create Several Models in Parallel to collect the wide range of information they are gathering. This practice is clearly supported by the practice Apply The Right Artifact(s) as well as Iterate To Another Artifact – you may be capturing information about a usage requirement in a use case when your stakeholder(s) begin discussing their needs for an editing screen, something better specified by an essential/abstract user interface (UI) prototype or traditional UI prototype. Iterating back and forth between artifacts, one of which may very well be program source code, is enabled by the practice Model in Small Increments – you will typically work on a little bit of one artifact, then another, then another, and so on.
3. Simplicity. This category contains the core practices of Create Simple Content, Depict Models Simply, Single Source Information, and Use the Simplest Tools. The two practices Create Simple Content and Depict Models Simply focus on model simplicity, and often going hand-in-hand during modeling – by focusing on how to depict something simply modelers often discover how to make whatever it is that they are modeling simpler. For example I have been involved in the development of several persistence layers, software conceptually similar to an Enterprise JavaBean (EJB) persistence container that encapsulates persistent storage from your domain objects, and as a result have been involved in some very complex architecture and design efforts. During one of them we were trying to figure out how to create a simple diagram that we could provide to application developers to help explain how to work with the persistence layer and in the process discovered a refactoring to make our design easier to understand. The practice Single Source Information suggests that you try to store information once and once only, preferably in the most appropriate place possible. This simplifies your documentation efforts as well as traceability. Simplicity of process is enhanced by the practice Use the Simplest Tools. The simpler a tool is the easier it is to work with, this decreases the barriers to entry for working on your models and thereby increases the chance that other people will in fact do so, including your stakeholders. By using simple tools you increase the chance that you will depict those models simply. Furthermore, when you use simple/low-fidelity tools such as index cards, Post-It notes, and whiteboards you put yourself into a situation where you actively experience the effectiveness of simple tools – subconsciously reinforcing the concept that the simplest solution can in fact work very well, a mindset that will hopefully reveal itself in a simpler design for the system that you are building.
4. Validation. This category consists of the core practice Prove it With Code. By actively seeking to prove a model with code as soon as possible I quickly show that my system works.

The Supplementary Practices

There are two categories of supplementary practices:

1. Documentation. This category consists of three supplementary practices: Discard Temporary Models , Formalize Contract Models , and Update Only When It Hurts . Your requirements, your understanding of those requirements, and potentially even your understanding of your solution are changing throughout your initiative (remember the principle Embrace Change). Many of your artifacts, including models and documents, will need to evolve to reflect these changes. As you’ll see with the discussion of agile documentation one of the best ways to ensure that you are taking an agile approach to your models and documents is to update them only when it hurts. When following this practice if you find that a model isn’t being updated it is an indication the model may not provide your team with much value – if the model doesn’t provide value then it should be considered temporary and hence discarded. However, remember that contract models, models that define an interface between your system and another, are unlikely to change much over time but because of their importance are not candidates for disposal. In short, if a non-contract model isn’t being updated over time it is a good indication that you don’t need that model.
2. Productivity. This category is comprised of the practices Apply Modeling Standards and Apply Patterns Gently. Agilists follow standards and guidelines, even when modeling, because it promotes consistency within your work. Yes, you write your own set of guidelines, and sometimes you do need to because of some unusual factor within your environment, but with a little bit of searching on the Internet you can quickly turn up development guidelines such as the ones for Java.

How the Categories Relate

Consider the practices of the Teamwork category. Active Stakeholder Participation is supported by the practices of the Simplicity category because simplicity lowers any barriers to participation. Participation is also enabled by the Iterative and Incremental practices, particularly Create Several Models in Parallel because it open up more opportunities for stakeholders to get involved. The practices Collective Ownership and Model With Others are supported by the Simplicity practices because they lower barriers to participation. Display Models Publicly is enhanced by the Productivity practices, following standards and applying patterns increases consistency and readability, and reuse of existing resources such as common architectural models provides a familiar base from which people can start with your models. Collective Ownership is supported by the Iterative and Incremental practices, in particular Create Several Models In Parallel and Iterate to Another Artifact seem to promote several people working together on whatever models are appropriate at the time.

The practices of the Simplicity category are supported by those of several other categories. The practice Depict Models Simply is enhanced by Apply Modeling Standards and Apply Patterns Gently because both of these practices support modeling in a common language (your chosen standards and hopefully well-understood patterns). Simplicity practices are enhanced by the Documentation practices – when you Update Only When It Hurts you are more likely to Depict Simply Models and Create Simple Content because you aren’t needlessly adding information to your models.

Now consider the Iterative and Incremental practices. The Teamwork practices clearly support these practice, with several people involved there is a greater chance that someone will know what the right artifact is to apply to your situation enabling you to iterate to it as needed. The Validation practices give you the courage to take an incremental approach, particularly when you Prove It With Code, and by keeping testability in the back of your mind you are more likely to want to work on several models at once, and iterate between them, because testing issues will likely need to be captured in a variety of views. The Documentation practices also promote an incremental approach, particularly Update Only When It Hurts, although Formalize Contract Models often goes against the incremental grain because you want to baseline interfaces with other systems as early as possible. Iterate to Another Artifact and Discard Temporary Models are complementary because you often want to work on a model and then move one once it has served its purpose. The Simplicity practices are also important to this category. When you Use the Simplest Tools it makes it easier to iterate back and forth between artifacts, you minimal time starting the tool, and a focus on simple content and simple depiction ensures that you have a minimal learning curve remembering what the model communicates. Finally, you typically require several views to communicate or understand the complexities of a system, and you will need to iterate back and forth between appropriate artifacts to do so effectively.

The Validation practices are supported by the Simplicity practices – when you Create Simple Content and Depict Models Simply you make it much easier to Prove it With Code. The Iterative and Incremental practices also promote validation. For example, when you Iterate to Another Artifact a likely candidate to iterate to is source code so that you can show that your model actually works.

The Productivity practices are enhanced by the Simplicity practices: It is easier to Apply Patterns Gently with you are working with simple models; it is easier to Apply Modeling Standards to when you Depict Models Simply.

The Documentation practices are supported by both the Simplicity and the Iterative and Incremental practices. The simpler your documentation is the easier it is to work with – if your documentation is easy to understand it gives you the courage to Update Only When It Hurts because you know that you will be able to do so easily, documentation that is harder to understand is a greater risk because you can’t be as sure that you can update it as required. The practices Update Only When It Hurts and Discard Temporary Models clearly only work in environments promoted by practices such as Iterate To Another Artifact and Model in Small Increments.