The Goals of Agile Modeling

AM has three goals:

• To define and show how to put into practice a collection of values, principles, and practices for effective, lightweight modeling.

• To address the issue of how to apply modeling techniques to software projects taking an agile approach, such as eXtreme Programming (XP) (Beck 2000) or Feature-Driven Development (FDD) (Palmer and Felsing 2002).

• To address how you can improve your modeling activities following a "near-agile" approach to software development, and in particular project teams that have adopted an instantiation of the Unified Process (UP), such as the Rational Unified Process (RUP) (Kruchten 2000) or the Enterprise Unified Process (EUP) (see Chapter 6).

It is critical to recognize that AM is independent of other processes, such as XP and the UP, that it is used only to enhance those processes. This is because AM is not a complete software process. AM's focus is on effective modeling and documentation; AM doesn't address programming, testing, project management, system deployment, system operations, system support, or a myriad of other issues. As Figure 8-1 depicts, you need to use AM with another, full-fledged process such as XP, Dynamic System Development Methodology (DSDM) (Stapleton 2003), FDD, or the UP. You start out with a base process and then tailor it with AM and other techniques to define a process that reflects your unique needs.

Figure 8-1. AM enhances other software processes.

Let's explore the values, principles, and practices of AM in detail.

Values

In the book Extreme Programming Explained (Beck 2000), one of the most poignant aspects of XP was how Beck first defined a foundation for his methodology. He did this by describing four values: communication, simplicity, feedback, and courage. He had found a way to describe some of the fundamental factors that lead to success in the software development game, and he managed to do it in such a way as to personalize it for individual developers. Agile Modeling adopts all four of XP's values and adds a fifth: humility. Agile software developers are humble enough to recognize that they can't do it alone but instead must work with others, including business stakeholders. Furthermore, they realize that they don't know everything, that they will never know everything, and as a result that they always must be looking for opportunities to learn. Table 8-1 discusses each AM value in detail.

Table 8-1. The values of agile modeling.

Value	Description
Communication	Communication is a two-way street: You both provide and gain information as the result of communication. Good communication among everyone involved in your project, including developers and project stakeholders is a requisite for software development success. Modeling helps you to communicate your ideas, to understand the ideas of others, to mutually explore those ideas, and to eventually reach a common understanding.
Courage	Agile methodologies ask you to do much that requires great courage, particularly much that you've never attempted before. You need to work closely with other people, to trust them and to trust yourself. You should do the simplest thing that you can, to trust that you can solve tomorrow's problem tomorrow. You should create documentation only when you absolutely need it and when stakeholders are willing to invest in it, not just when it feels comfortable to do so. You must let businesspeople make business decisions, such as prioritization of requirements, and technical people make technical decisions, such as how the software will fulfill individual requirements. You must trust your coworkers, to trust that programmers can make design decisions and, therefore, that you do not need to provide them with as much detail.
Feedback	The only way you can determine whether your work is correct is to obtain feedback, and that includes feedback regarding your models. You can obtain feedback by developing the model as a team instead of by yourself, by reviewing models with the target audience (better yet, get them involved early on with modeling), by implementing the model, and through acceptance testing of the actual system.
Humility	The best developers have the humility to recognize that they don't know everything. Agile modelers understand that their fellow developers and their project stakeholders have their own areas of expertise and, therefore, have value to add to a project. Agile modelers have the humility to respect the people they are working with, realizing that others likely have different priorities and experiences than they do and will, therefore, have different viewpoints.
Simplicity	Keep your models as simple as possible. Model today to meet today's needs, and worry tomorrow about tomorrow's modeling needs. Follow the KISS (Keep It Simple, Stupid) rule and not the KICK (Keep It Complex, Kamikaze) rule. In other words, don't overmodel.

The Principles of Agile Modeling

Agile Modeling's values, in combination with the values and principles of the Agile Alliance (2001a, 2001b), are used as the foundation of AM's principles. When applied to a software development project, these principles set the stage for a collection of modeling practices. Some of the principles have been adopted from XP, which in turn adopted them from common software engineering techniques. For the most part, the principles are presented with a focus on their implications to modeling efforts. As a result, material adopted from XP may be presented in a different light.

Table 8-1 describes AM's core principles, which you must adopt in full to be truly able to claim that you are agile modeling. Table 8-2 describes AM's supplementary principles, which you may optionally tailor into your software process to increase its effectiveness. Why distinguish between core and supplementary principles? AM strives to avoid a problem that XP suffers from: people who claim to do XP, but who really don't, who then blame XP for their failure. Like XP, the principles and practices of AM are synergistic, and if you remove some, the synergy is lost. By failing to adopt one of the core principles or practices of AM, you reduce the method's effectiveness. You should feel free to adopt whatever aspects of AM you see fit to use, just don't claim that you're doing AM when you've only adopted it partially.

Table 8-2. The core principles of agile modeling.

Principle	Description
Assume Simplicity	As you develop you should assume that the simplest solution is the best solution.
Embrace Change	Agile modelers accept the fact that change happens. Your requirements change, as does your understanding of them. The technology you are working with changes over time, as does your strategy for using it.
Enabling the Next Effort Is Your Secondary Goal	Your project can be considered a failure even when your team delivers a working system to your users. Part of fulfilling the needs of your project stakeholders is ensuring that your system is robust enough to be extended over time. As Alistair Cockburn (2002) likes to say, when you are playing the software development game your secondary goal is to set up to play the next game.
Incremental Change	To embrace change, you need to take an incremental approach to your own development efforts, to change your system a small portion at a time instead of trying to get everything accomplished in one big release. You can make a big change as a series of small, incremental changes.
Maximize Stakeholder Investment	Your project stakeholders are investing resources time, money, facilities, and so on to have software developed that meets their needs. Stakeholders deserve to invest their resources the best way possible and to not have them frittered away by your team. Furthermore, stakeholders deserve to have the final say in how those resources are invested or not invested. If it were your money, would you want it any other way?
Model with a Purpose	If you cannot identify why and for whom you are creating a model, why are you bothering to work on it at all?
Multiple Models	You have a wide range of modeling artifacts available to you. These artifacts include but are not limited to the diagrams of the Unified Modeling Language (UML), structured development artifacts such as the physical data model which depicts a portion of Canaxia's database schema in Figure 8-2, and low-tech artifacts such as essential user interface models (Ambler 2001a; Constantine and Lockwood 1999). Visit www.agilemodeling.com/essays/modelingTechniques.htm for a list of potential modeling artifacts (it's interesting to note how many non-UML artifacts there are) and www.agiledata.org/essays/umlDataModelingProfile.html for a description of the notation used in Figure 8-2).
Quality Work	Agile developers understand that they should invest the effort to make permanent artifacts, such as source code, user documentation, and technical system documentation, of sufficient quality.
Rapid Feedback	Feedback is one of the five values of AM, and because the time between an action and the feedback on that action is critical, agile modelers prefer rapid feedback over delayed feedback whenever possible.
Software Is Your Primary Goal	The primary goal of software development is to produce high-quality software that meets the needs of your project stakeholders in an effective manner.
Travel Light	Traveling light means that you create just enough models and documentation to get by. No more, no less.

Figure 8-2. A physical data model.

Table 8-3. The supplementary principles of agile modeling.

Principle	Description
Content Is More Important Than Representation	Any given model could have several ways to represent it. For example, a UI specification could be created using Post-It™ notes on a large sheet of paper (an essential or low-fidelity prototype), as a sketch on paper or whiteboard, as a traditional prototype built using a prototyping tool or programming language, or as a formal document including both a visual representation and a textual description of the user interface. For example, Figure 8-3 depicts a high-level business model for customer contact at Canaxia. Although it uses some UML notation, in particular the stick figure representing an actor, the rest of the diagram is clearly free-form. Although it doesn't conform to an official notation, this diagram still provides values to its users.
Everyone Can Learn from Everyone Else	Agile modelers have the humility to recognize that they can never truly master something and that there is always opportunity to learn more and to extend their knowledge. They take the opportunity to work with and learn from others, to try new ways of doing things, to reflect on what seems to work and what doesn't.
Know Your Models	You need to know the strengths and weaknesses of each type of model, know when to create each one, and how to create each one effectively.
Know Your Tools	Software, such as diagramming tools or modeling tools, has a variety of features. If you are going to use a modeling tool, you should understand its features, knowing when and when not to use it.
Local Adaptation	AM is designed so you can tailor it to reflect your environment, including the nature of your organization, your coworkers, your project stakeholders, and your project itself.
Open and Honest Communication	People need to be free to offer suggestions. Open and honest communication enables people to make better decisions because the quality of the information they are basing them on is more accurate.
Work with People's Instincts	As you gain experience at developing software, your instincts become sharper, and what your instincts are telling you subconsciously can often be an important input into your modeling efforts.

Figure 8-3. A high-level business model for customer contact at Canaxia.

The Practices of Agile Modeling

The heart of AM is its practices. It is those practices that you apply to your projects, those practices that are guided by AM's values and principles. They are organized into core practices (Table 8-4) that you must adopt and optional supplementary practices (Table 8-5) that you may adopt. You must adopt all AM's core practices to be able to claim that you are "doing AM." However, you may still benefit if you only adopt some of the practices, perhaps because that is all that your organization's culture will allow.

Table 8-4. The core practices of agile modeling.

Practice	Description
Active Stakeholder Participation	Project success often requires a significant level of involvement by project stakeholders. Senior management needs to publicly and privately support your project, operations and support staff must actively work with your project team toward making your production environment ready to accept your system, other system teams must work with yours to support integration efforts, and maintenance developers must work to become adept at the technologies and techniques used by your system.
Apply the Right Artifact(s)	This is AM's equivalent of the adage "Use the right tool for the job." In this case, you want to create the right model(s) to get the job done. Each artifact such as a UML state chart, an essential use case, source code, or data flow diagram (DFD) has its own specific strengths and weaknesses, and therefore is appropriate for some situations but not others.
Collective Ownership	Everyone can work on any model, and ideally any artifact on the project, if they so need.
Consider Testability	When you are modeling, you should be asking yourself constantly "How are we going to test this?" If you can't test the software you are building, you shouldn't be building it.
Create Several Models in Parallel	Because each type of model has its strengths and weaknesses, no single model is sufficient for your modeling needs. By working on several at once, you can easily iterate back and forth between them and use each model for what it suits best.
Create Simple Content	You should keep the actual content of your models your requirements, your analysis, your architecture, your design as simple as you possibly can while still fulfilling the needs of your project stakeholders. The implication is that you should not add additional aspects to your models unless they are justifiable.
Depict Models Simply	Use a subset of the modeling notation available to you. A simple model that shows the key features you are trying to understand perhaps a class model depicting the primary responsibilities of classes and the relationships among them often proves to be sufficient. For example, the models depicted in Figure 8-3 and Figure 8-4 are both fairly simple and use minimal notation, yet they depict important information.
Display Models Publicly	This supports the principle of Open and Honest Communication on your team, because all the current models are quickly accessible to it. It also satisfies your project stakeholders because you aren't hiding anything from them.
Iterate to Another Artifact	Whenever you are having difficulties working on one artifact perhaps you are working on a use case and find that you are struggling to describe the business logic that's a sign that you should iterate to another artifact. By iterating to another artifact, you are freed immediately because you are making progress working on that other artifact. For example, as you're developing a use case, you may discover that your stakeholders are having trouble describing the usage logic, so you decide to change tack and work on sketching a few supporting screens. A few minutes later, your stakeholders suddenly realize what needs to occur in the use case as the result of approaching the problem from another direction (in this case UI design).
Model in Small Increments	With incremental development you model a little, code a little, test a little, then deliver a little. No more big design up front (BDUF) where you invest weeks or even months creating models and documents.
Model with Others	Software development is a lot like swimming: It's very dangerous to do it alone.
Prove IT with Code	A model is an abstraction, one that should accurately reflect an aspect of whatever you are building. To determine if it will actually work, you should validate that your model works by writing the corresponding code.
Use the Simplest Tools	The vast majority of models can be drawn on a whiteboard, such as the diagram in Figure 8-3, on paper, and even on the back of a napkin. Note that AM has nothing against computer-aided software engineering (CASE) tools if investing in a CASE tool is the most effective use of your resources, by all means use it to its maximum benefit.

Figure 8-4. A free-form diagram depicting high-level technical architecture.

Table 8-5. The supplementary practices of agile modeling.

Practice	Description
Apply Modeling Standards	Developers should agree to and follow a common set of modeling standards on a software project. Good sources of modeling standards and guidelines are The Elements of UML Style (Ambler 2003a) and www.modelingstyle.info.
Apply Patterns Gently	Effective modelers learn and then appropriately apply common architectural, design, and analysis patterns in their models. However, both Martin Fowler (2001a) and Joshua Kerievsky (2001) believe that developers should consider easing into the application of a pattern, that they should apply it gently.
Discard Temporary Models	The vast majority of the models 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. For example, Figure 8-4 depicts a whiteboard sketch of a potential technical architecture for Canaxia applications. The architects drew this diagram as they discussed the issue but eventually erased it in favor of another approach. The fate of most models is to be discarded like this.
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 formalized when both parties mutually agree to it and are prepared to mutually change it over time as required.
Model to Communicate	One reason why you model is to communicate with people who are external to your team or to create a contract model.
Model to Understand	You often create models to explore the problem space, to understand the requirements for the system. Similarly, you will compare and contrast potential design alternatives to understand the solution space.
Reuse Existing Resources	Agile modelers can take advantage of a wealth of resources by reusing them.
Update Only When It Hurts	You should update an artifact such as a model or document only when you absolutely need to, when not having it updated is more painful than the effort of updating it.