Home > Articles > Software Development & Management > Agile

Agile Modeling

Modeling and design skills still have a part to play in the XP world. The difference is that tools and models become simpler and more dynamic. Learn how to use your modeling skills in an Agile way.

See all Sams Teach Yourself on InformIT Programming Tutorials.

This chapter is from the book

Extreme Programming is part of a growing number of Agile technologies and methods. A recent addition to this family of Agile methodologies is Agile Modeling (AM). This is an exciting approach that involves combining industry standard or best practice modeling with Agile thinking. You'll learn the following this hour:

  • What Agile Modeling is

  • How Agile Modeling shares basic values with XP

  • What the values, principles, and practices of Agile Modeling are

  • How Agile Modeling compares to XP

  • How Agile Modeling can be used in an XP project

Taking a Tour Through Agile Modeling

There are a lot of street rumors and urban myths when it comes to XP; opinions abound about what it is and isn't. One of these mistaken perceptions is that XP has no documentation or modeling at all; programmers just get on with program-ming. There's a world of difference between light documentation or enough documentation and none at all. At one end is the hacker and at the other, the Agile developer who knows when to use techniques or tools at her disposal.


In a software engineering sense, modeling refers to the use of diagrams to describe a process, solution, or problem. These diagrams can be supported by documentation.

What is Agile Modeling? Don't worry; it has nothing to do with acrobatics and clay! Briefly, it is a practice-based methodology founded on values, principles with a goal to support and enable software development by the effective use of modeling tools and techniques. It isn't an explicit list of steps or procedures. The beauty of AM is that it allows each user to modify the approach to his local setting. There is much to compare between XP and AM.

AM was primarily developed by Scott Ambler. His Agile Modeling site (http://www.agilemodeling.com/) has a wealth of information on the subject.


This hour is based in part on Ambler's book Agile Modeling: Effective Practices for Extreme Programming and the Unified Process (Wiley, 2002). This is a must read for any XP developer who wants to use his or her modeling skills with Extreme Programming.

So, AM is doing "just enough" modeling but do we need modeling at all? Modeling is an important way to communicate between team members at all stages of the software development lifecycle. We begin the iteration with a collection of user stories and tasks; invariably questions arise from these high-level requirements. Questions like, "what should the screen look like?" or "So, what is the exact process of taking an order?" Soon you're at the whiteboard sketching and modeling to close the comprehension gap. Developers might use class diagrams or the like as they express lower-level understandings to each other. With AM, these models, whether on paper or whiteboard are typically thrown away after they outlive their usefulness. However, these models may be kept if they provide some value.

Before we investigate how we might use AM techniques on an XP project, we'll take a few minutes to get an overview of AM.

Agile Modeling Values

A methodology based on values—sound familiar? Scott Ambler makes no bones about being inspired by Kent Beck to take this approach from XP when he came to forming AM. AM values have added one extra value to our core XP values: humility. Developers can get possessive when it comes to "their" models and will resist and attempt to change or adjust. Some developers are also unwilling to work with others, particularly nontechnical people, because they don't have the humility to accept that others can also provide significant input into the overall effort. The truth is, often the model isn't wrong, but it simply fails to communicate. We could add humility as a value to XP but for now we'll leave that for XP version 2!

Table 23.1 lists the AM values and explains their relevance.

Table 23.1 Agile Modeling Values




Choosing AM requires courage; you're forced to rely more on your own judgment and experience, rather than blind adherence to the "book." It takes courage to admit that your model is weak or wrong and accept new direction.


Models exist for the purpose of communicating between people, including both stakeholders and developers. If a modeling approach fails to communicate, change it for one that does.


Get feedback on your models early and often. Build the model as a team or group, letting it evolve in a shared space. Validate the model with your customer to ensure it is accurate and effectively explanatory.


Agile modelers hold their models loosely and will lay them down if required. They have the self-confidence to let others criticize or question. Sometimes your model is perfect but the customer just doesn't get it! It takes humility to discard your perfectly formed UML and let the customer doodle her thoughts.


Keep models and approaches as simple as possible and change tomorrow if you need to. Assume that the simple approach will work before you attempt the more complex.


UML (Unified Modeling Language) has become the industry standard for modeling over the last few years. At the time of writing it is still not the complete answer to all your modeling needs. It has no database or user interface modeling support and so you should expect to supplement it with other notations for these. The Web home of UML is at http://www.uml.org/.

Agile Modeling Core Principles

The core principles of AM give concrete definition; they are a less abstract guide than the five values. Developers who claim to be Agile Modelers must adhere to the principles listed in Table 23.2.

Table 23.2 Agile Modeling Core Principles



Assume Simplicity

Keep your models as simple as possible and assume that the simplest solution is best. Only model what you need today and trust that you can remodel if needed.

Embrace Change

Change will happen on your project as understanding grows. Rather than fight changes to your models or views, accept them and have the courage to rebuild.

Enabling the Next Effort Is Your Secondary Goal

Development does not happen in a vacuum; others might need to extend or improve your project after you leave. Leave just enough documentation and models to enable the next team to win.

Incremental Change

Your models don't have to be perfect the first time; they will change over time as the project develops. Make small changes to models as required.

Maximize Stakeholder Investment

The team is producing software to maximize return for the customer. Does the model or documentation you're creating add to this value? There comes a point where some models exist for their own sake!

Model with a Purpose

Create models with an end in mind, not as exercises or because "that's the way you do it." Be clear in your own mind why you're creating the model; who is it for and what are you trying to communicate?

Multiple Models

There are many ways of modeling solutions; choose those that fit your situation. For example, data models for a database team. Remember that the UML is a good start, but that it isn't the complete solution.

Quality Work

Just enough modeling isn't a license for carelessness; strive to model in ways that accurately communicate.

Rapid Feedback

Getting quick feedback on your model will close the loop of understanding. Model a little, show, and then model again. This ensures your model is accurate while increasing your own knowledge.

Software Is Your Primary Goal

Models are but a means to the end; the end is to build software for your customer. Documentation and modeling must directly support the goal of software development.

Travel Light

Traveling light means you have just enough documentation for your journey. Too little and the team will lose its way; too much and we've forgotten our primary goal is writing software not documents.


A great quote from Ambler: "System documentation is a business decision." This means that whether you write documentation or save project artifacts, it is a cost-risk trade-off for the customer. As software developers we often assume that the customer must have system documentation for maintenance or support purposes. If they choose to forgo or reduce this, they risk that maybe they'll be exposed in the future.

Agile Modeling Secondary Principles

The principles covered in the previous section are necessary for Agile Modeling but a number of secondary principles can further enhance your modeling effectiveness. You might choose to add your own principles based on your own or the team's collective experience. Table 23.3 lists and describes the secondary principles.

Table 23.3 Agile Modeling Secondary Principles



Content Is More Important than Representation

What is being conveyed is more important than the way you choosing to convey it. Don't get lost in inane arguments over CASE tools versus paper-based methods.

Everyone Can Learn from Everyone Else

Learning and education don't come from books alone; expect to learn while you work with others. Technology changes at such a pace that no one person can claim to know it all.

Know Your Models

As an Agile Modeler, you'll select different modeling techniques based on the situation. You can't do this if you lack clarity on the relative strengths and weaknesses of each.

Know Your Tools

Similar to Know Your Models, select the appropriate software tool based on your knowledge of the package rather than lack of experience with it. More often than not you'll choose paper over computer but there will still be times when you'll select a CASE tool or similar. Be prepared for this!

Local Adaptation

Keep in mind that AM is not a dogmatic approach to modeling; adapt and modify based on your own requirements and skills. There may be cases where your customer insists on certain modeling tools or standards. AM allows you the flexibility to accept and work with this.

Open and Honest Communication

Using a non-prescriptive approach like AM requires those on the team to express ideas, feelings, frustrations, and viewpoints. The team will make better more informed decisions by cultivating an open and honest workplace.

Work with People's Instincts

The customer gets that glazed look or begins to nod mechanically; this is a sign that you're not connecting. It's time to put aside your model and work through why communication has broken down. We're getting into the "touchy-feely" or EQ (Emotional Quotient) zone here but the reality is that you're talking to people not computers. Agile modelers will go with their instinct even when communication seems to be going well.

Agile Modeling Core Practices

AM's core practices are where the rubber meets the road, where the real work of modeling gets done. These practices are guided and framed by AM's values and principles. Table 23.4 lists the core practices of AM.

Table 23.4 Agile Modeling Core Practices



Active Stakeholder Participation

AM works in part because it relies on customers to become actively engaged in the modeling process. This in turns requires that developers exhibit flexibility with modeling notation and approach.

Apply the Right Artifacts

Agile Modelers choose the right tool for the job. There are so many artifacts you could select: UML state diagram, data flow diagram, or conceptual data model. Apply the artifact that fits your situation—for example a physical data model when displaying database relationships.

Collective Ownership

The team owns the models; this is encouraged by the use of collaborative tools like whiteboards that exist in shared space. Rather than allow a single developer to assume the role of "model guru," Agile Modelers spread the task to the wider team. This becomes even more important when the team comes to explaining "their" model to the customer.

Consider Testability

As you develop your model, consider how and if it can be tested.

Create Several Models in Parallel

In the search for understanding you might need to use more than one modeling notation. You might sometimes switch back and forth. Later in this hour I'll demonstrate this as I explain how to derive user stories.

Create Simple Content

In line with the AM value of simplicity, your model should contain the fewest possible elements required to communicate and fulfill its purpose.

Depict Models Simply

When you model, use a subset of your base-modeling notation. Avoid large, complex diagrams that obscure meaning. Remember that as XPers, we are not looking for detail in our models and that they are primarily temporary aids to communication.

Display Models Publicly

Displaying models in public emphasizes the shared nature of AM and also gives the customer a definite sense of direction. It may help capture metaphor and vision for the whole team; they have something to hang their hat on.

Iterate to Another Artifact

When you come to an impasse with the model you're using, either because of limitations inherent in the model or because it's inappropriate, you might find you need to iterate to another model type. Sometimes the act of changing notations is all that is required to free up communication. This practice is connected with the practice of creating several models in parallel.

Model in Small Increments

Modeling in Small Increments fits within the context of iterative software development: model, communicate, refine, and remodel. Modeling in this way opens up the possibility to change models mid-stream if needed.

Model with Others

XP and AM are team efforts where the synergy of the group amplifies the effectiveness of the team. This is loosely related to the XP practice of Pair Programming.

Prove It with Code

Sometimes the best way to validate your model is with the code itself; after all that is the point of the model! We could compare this to the use of a spike in XP to validate technical assumptions or deal with issues.

Use the Simplest Tools

Developers tend to model on paper or whiteboard and then transcribe back to a formal design tool, like Microsoft Visio. Agile Modelers aren't afraid to leave the sketch as is and either file it or scan it so it forms part of the documentation. The falling price of digital cameras simplifies the chore of transcribing from flip charts or whiteboards. Agile Modelers will use a more complicated CASE tool, such as TogetherSoft's ControlCenter (http://www.togethersoft.com/products/controlcenter), when it makes sense to do so—they use the simplest tools, not just simple tools.

Agile Modeling Secondary Practices

Once your team has adopted and is comfortable with the core AM practices, they should also integrate the secondary practices into their daily modeling routine. These practices help achieve better productivity, motivation, and a clearer understanding of the place documentation holds in AM. Table 23.5 lists the secondary practices of AM.

Table 23.5 Agile Modeling Secondary Practices



Apply Modeling Standards

AM modeling standards fit the "just enough" bracket of guidelines and standards. As a group, decide on certain standards and tools; having these standards in place stops some of the meaningless arguments about style or preference. As with Coding Standards in XP you can evolve these in a "just in time" approach, storing your standards in the project Wiki Web site. Visit http://www.modelingstyle.info for UML modeling guidelines.

Apply Patterns Gently

Modelers are used to applying architectural patterns when solving problems and creating models. In AM the practice is apply them where it makes sense, in a minimal or gentle sense. With XP, code is developed with the expectation that future refactoring may occur and you should keep this in view while you model.

Discard Temporary Models

Models exist mainly for communication and understanding; discard these once they have served their purpose.

Formalize Contract Models

If your system interfaces with third parties, you should adopt the AM practice of formalizing your contract models. These models usually indicate protocols and the interface to the system, such as an API to a function library, an XML schema for an XML file transfer, or a physical data model for a legacy database.

Model to Communicate

Depending on your audience you'll need to model using varying approaches. Senior management might expect a slide presentation, demonstrating a high-level solution map; on the other hand, developers may find a DFD useful.

Model to Understand

You might model your problem or issue to explore and understand it. Working with customer or developers to clear your understanding before the team attempts to offer a solution.

Reuse Existing Resources

With the aim to maximize shareholder investment, look to reuse any existing models or resources. In XP, you're more likely to reuse the approaches you've learned rather than an actual deliverable.

Update Only When It Hurts

If you wait long enough, your model will become out of date, as source code develops or requirements change. Should you go back and update your model? The AM answer to this question is that only if you absolutely need to for reasons of comprehension. An example could be where a section of the system is undergoing large refactorings and the team needs to step back before they start; an up-to-date model could help here.


For an example of UML style guidelines see http://www.modelingstyle.org/.

Comparing XP with Agile Modeling

In case you forgot: This book is about XP, not Agile Modeling. Still as XP developers we are very interested to see how AM and XP are aligned. Clearly, there is a synergy at values and principles levels, but how do the practices relate? Before I walk you through a sample modeling session, I'll review how XP and AM cross-reference. Table 23.6 lists each AM practice and compares it to XP.


This table is based on Ambler's essay "Agile Modeling and Extreme Programming (XP)" from http://www.agilemodeling.com/essays/agileModelingXP.htm.

Table 23.6 Cross-referencing AM and XP Practices

AM Practice

XP Practice

Active Stakeholder Participation

This practice equates to the XP practice of On-Site Customer.

Apply Modeling Standards

This is the AM version of XP's Coding Standards practice.

Apply Patterns Gently

This practice is in conformance to XP's practice of Simple Design.

Apply the Right Artifact(s)

This does not directly relate to any XP practice.

Collective Ownership

AM has adopted XP's Collective Ownership practice.

Consider Testability

This relates to the XP practice of testing.

Create Several Models in Parallel

This does not directly relate to any XP practice.

Create Simple Content

This is complementary to XP's Simple Design practice that advises to keep your models as simple as possible.

Depict Models Simply

This is complementary with XP's Simple Design practice that suggests that your models do not need to be fancy to be effective, perfect examples of which are user stories.

Discard Temporary Models

This practice reflects XP's Travel Light principle.

Display Models Publicly

This practice reflects XP's value of Communication and principle of Open & Honest Communication and relates to its practice of Collective Ownership.

Formalize Contract Models

This does not directly relate to any XP practice.

Iterate to Another Artifact

This does not directly relate to any XP practice. It does reflect the way that XPers will iterate back and forth between working with user stories, tasks, CRC cards, code, and tests.

Model in Small Increments

This practice supports XP's iterative and increment approach to development. Both XP and AM prefer an emergent approach to development and not a big design up front (BDUF) approach.

Model to Communicate

This practice is modeling-specific, describing one reason why you would want to model, a practice that reflects XP's and AM's principle of Open and Honest Communication.

Model to Understand

This practice is modeling-specific, describing the primary reason why you would want to model. This practice is consistent with XP's existing use of CRC cards to explore design issues.

Model with Others

This is the AM version of XP's Pair Programming practice.

Prove It with Code

This is the AM version of XP's Concrete Experiments principle.

Reuse Existing Resources

This does not directly related to any XP practice.

Update Only When It Hurts

This practice reflects AM and XP's Travel Light principle, advising that you should update an artifact only when you desperately need to.

Use the Simplest Tools

This practice reflects AM and XP's Assume Simplicity principle and is consistent with XP's preference for low-tech tools such as index cards for modeling.

Looks like we have a good value, principle, and practice alignment between AM and XP! The next section looks at how we apply AM principles and practices, during a typical design session.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020