Agile Modeling with eXtreme Programming (XP) 

Agile Modeling (AM) is a practices-based software process whose scope is to describe how to model and document in an effective and agile manner.  On the AM home page I state that one of the goals of AM is to address the issue of how to apply modeling techniques on software projects taking an agile approach such as eXtreme Programming (XP) Dynamic Systems Development Method (DSDM), and SCRUM to name a few.  Because the scope of XP is much greater than that of AM, XP covers the full development lifecycle, it is a candidate "base process" into which the techniques of AM may be tailored.  Furthermore, although XP clearly includes modeling as part of its process it is not as explicit about how to do so as many developers would prefer.  Hence an opportunity for AM.  Luckily XP, like AM, is also an agile practices-based methodology which makes the conceptual fit between the two methods much easier than between AM and a prescriptive process such as the Unified Process, the topic of the essay Agile Modeling and the Unified Process.
Agile Modeling (AM) is a collection of values, principles, and practices for modeling software that can be applied on a software development project in an effective and lightweight manner.  Agile models are more effective than traditional models because they are just barely good enough, they don't have to be perfect.  You may take an agile modeling approach to requirements, analysis, architecture, and design.
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 not about less modeling, in fact many developers will find that they are doing more modeling following AM than they did in the past.  AM is “touchy-feely”, it’s not hard and fast – think of AM as an art, not a science. 
AM recognizes that the values of agile development, as promoted by the Agile Alliance, are key to your being effective.  The Agile Alliance promotes:
Individuals and interactions over processes and tools
Working software over comprehensive documentation 
Customer collaboration over contract negotiation
Responding to change over following a plan

The Goals of Agile Modeling (AM):
The goals of AM are:
To define, and show how to put into practice, a collection of values, principles and practices pertaining to effective, light-weight modeling. The secret to AM isn’t the modeling techniques themselves -- such as use case models, class models, data models, or user interface models -- but how they’re applied.  
To address the issue of how to apply modeling techniques on an software projects taking an agile approach such as eXtreme Programming (XP), Dynamic Systems Development Method (DSDM), or SCRUM. To quote Kent Beck from eXtreme Programming Explained (XPE) "We will continually refine the design of a system, starting from a very simple beginning. We will remove any flexibility that doesn't prove useful. "Contrary to the claims of some of XP's detractors you do in fact invest time modeling when taking an XP approach, but only when you have no other choice. Sometimes it is significantly more productive for a developer to draw some bubbles and lines to think through an idea, or to compare several different approaches to solving a problem, than it is simply start hacking out code.  Read the essay Agile Modeling and XP for more details. 
To address the issue of how to model effectively on a Unified Process (UP) project, common instantiations of which include the Rational Unified Process (RUP) and the Enterprise Unified Process (EUP).  The EUP includes several modeling-oriented workflows -- Requirements, Business Modeling, Analysis & Design, Infrastructure Management -- which when applied at face value can become quite burdensome.  AM helps to improve the effectiveness of your modeling efforts on an UP project (or any project for that matter).  Read the essay Agile Modeling and The Unified Process for more details. 
The Scope of Agile Modeling (AM)
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 XP, DSDM, SCRUM, or UP as indicated by the goals of AM.  Figure 1 depicts this concept.  You start out 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. 
Overview of The Values, Principles, and Practices of Agile Modeling (AM)
The values of AM, adopting and extending those of eXtreme Programming, are communication, simplicity, feedback, courage, and humility.  The keys to modeling success are to have effective communication between all project stakeholders, to strive to develop the simplest solution possible that meets all of your needs, to obtain feedback regarding your efforts often and early, to have the courage to make and stick to your decisions, and to have the humility to admit that you may not know everything, that others have value to add to your project efforts. 
AM is based on a collection of principles, such as the importance of assuming simplicity when you are modeling and embracing change as you are working because requirements do in fact change over time.  You should recognize that incremental change of your system over time enables agility and that you should strive to obtain rapid feedback on your work to ensure that it accurately reflects the needs of your project stakeholders.  You should model with a purpose, if you don't know why you are working on something then you shouldn't be doing so, and that you need multiple models in your development toolkit to be effective.  A critical concept is that models are not necessarily documents, a realization that enables you travel light by discarding most of your models once they have fulfilled their purpose.  Agile modelers believe that content is more important than representation, that there are many ways you can model the same concept yet still get it right. To be an effective modeler you need to know your tools and know your models, and to be an effective teammate you should realize that everyone can learn from everyone else, you should work with people's instincts, and that open and honest communication is often the best policy to follow to ensure effective teamwork.  Finally, a focus on quality work is important because nobody likes to produce sloppy work and that local adaptation of AM to meet the exact needs of your environment is important.
To model in an agile manner you will apply AM's practices as appropriate.   Fundamental practices include creating several models in parallel, applying the right artifact(s) for the situation, and iterating to another artifact to continue moving forward at a steady pace.  Modeling in small increments, and not attempting to create the magical "all encompassing model" from your ivory tower, is also fundamental to your success as an agile modeler.  Because models are only abstract representations of software, abstractions that may not be accurate, you should strive to prove it with code to show that your ideas actually work in practice and not just in theory.  Active stakeholder participation is critical to the success of your modeling efforts because your project stakeholders know what they want and can provide you with the feedback that you require.  There are two fundamental reasons why you create models, either you model to understand an issue (such as how to design part of your system) or you model to communicate what your team is doing (or has done).  The principle of assume simplicity is a supported by the practices of creating simple content by focusing only on the aspects that you need to model and not attempting to creating a highly detailed modeling, depicting models simply via use of simple notations, and using the simplest tools to create your models.  You travel light by discarding temporary models and updating models only when it hurts.  Communication is enabled by displaying models publicly, either on a wall or internal web site, through collective ownership of your project artifacts, through applying modeling standards, and by modeling with others.  Your development efforts are greatly enhanced when you consider testability, apply patterns gently, and reuse existing artifacts.  Because you often need to integrate with other systems, including legacy databases as well as web-based services, you will find that you need to formalize contract models with the owners of those systems. Read this essay for a better understanding of how AM's practices fit together. 
I would argue that AM is an agile approach to modeling that at its core AM is simply a collection of practices that reflect the principles and values shared by many experienced software developers. My experience is that these practices can be applied to most software development projects, you don't have to be working on an project following an agile software process (such as XP) to take advantage of the approaches described by AM, although one of AM's goals is to explain how to model when following the XP approach. A project team doesn't need to apply all of the practices, principles, and values of AM to benefit from it -- I have always been a firm believer that you should tailor your software process to reflect the unique needs of your environment -- although it is my opinion that like XP you are much more likely to succeed if you do adopt all of AM.

The Values of Agile Modeling (AM)
The values of AM include the values of XP: communication, simplicity, feedback and courage, extending them with the fifth value of humility: 

Communication.  Models promote communication between your team and your project stakeholders as well as between developers on your team.

Simplicity. It’s important that developers understand that models are critical for simplifying both software and the software process—it’s much easier to explore an idea, and improve upon it as your understanding increases, by drawing a diagram or two instead of writing tens or even hundreds of lines of code.

Feedback. Kent Beck says it best in Extreme Programming Explained: “Optimism is an occupational hazard of programming, feedback is the treatment.” By communicating your ideas through diagrams, you quickly gain feedback, enabling you to act on that advice.

Courage. Courage is important because you need to make important decisions and be able to change direction by either discarding or refactoring your work when some of your decisions prove inadequate.

Humility. The best developers have the humility to recognize that they don't know everything, that their fellow developers, their customers, and in fact all project stakeholders also have their own areas of expertise and have value to add to a project.  An effective approach is to assume that everyone involved with your project has equal value and therefore should be treated with respect.


The Principles of Agile Modeling (AM)
Agile Modeling (AM) defines a collection of core and supplementary principles that when applied on a software development project set the stage for a collection of modeling practices. Some of the principles have been adopted from eXtreme Programming (XP) and are well documented in Extreme Programming Explained, which in turn adopted them from common software engineering techniques.  Reuse!   For the most part the principles are presented with a focus on their implications to modeling efforts and as a result material adopted from XP may be presented in a different light.



Core Principles:
Assume Simplicity. As you develop you should assume that the simplest solution is the best solution. Don't overbuild your software, or in the case of AM don't depict additional features in your models that you don't need today. Have the courage that you don't need to over-model your system today, that you can model based on your existing requirements today and refactor your system in the future when your requirements evolve. Keep your models as simple as possible. 
Embrace Change. Requirements evolve over time. People's understanding of the requirements change over time. Project stakeholders can change as your project moves forward, new people are added and existing ones can leave. Project stakeholders can change their viewpoints as well, potentially changing the goals and success criteria for your effort. The implication is that your project's environment changes as your efforts progress, and that as a result your approach to development must reflect this reality. 
Enabling The Next Effort Is Your Secondary Goal. Your project can still 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 to ensure that your system robust enough so that it can be extended over time.  As Alistair Cockburn likes to say, when you are playing the software development game your secondary goal is to setup to play the next game.  Your next effort may be the development of the next major release of your system or it may simply be the operations and support of the current version you are building.  To enable it you will not only want to develop quality software but also create just enough documentation and supporting materials so that the people playing the next game can be effective.  Factors that you need to consider include whether members of your existing team will be involved with the next effort, the nature of the next effort itself, and the importance of the next effort to your organization.  In short, when you are working on your system you need to keep an eye on the future.   
Incremental Change. An important concept to understand with respect to modeling is that you don't need to get it right the first time, in fact, it is very unlikely that you could do so even if you tried. Furthermore, you do not need to capture every single detail in your models, you just need to get it good enough at the time. Instead of futilely trying to develop an all encompassing model at the start, you instead can put a stake in the ground by developing a small model, or perhaps a high-level model, and evolve it over time (or simply discard it when you no longer need it) in an incremental manner. 
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 not to have resources frittered away by your team. Furthermore, they deserve to have the final say in how those resources are invested or not invested.  If it was your resources, would you want it any other way?  
Model With A Purpose. Many developers worry about whether their artifacts -- such as models, source code, or documents -- are detailed enough or if they are too detailed, or similarly if they are sufficiently accurate. What they're not doing is stepping back and asking why they're creating the artifact in the first place and who they are creating it for. With respect to modeling, perhaps you need to understand an aspect of your software better, perhaps you need to communicate your approach to senior management to justify your project, or perhaps you need to create documentation that describes your system to the people who will be operating and/or maintaining/evolving it over time. If you cannot identify why and for whom you are creating a model then why are you bothering to work on it all? Your first step is to identify a valid purpose for creating a model and the audience for that model, then based on that purpose and audience develop it to the point where it is both sufficiently accurate and sufficiently detailed. Once a model has fulfilled its goals you're finished with it for now and should move on to something else, such as writing some code to show that the model works. This principle also applies to a change to an existing model: if you are making a change, perhaps applying a known pattern, then you should have a valid reason to make that change (perhaps to support a new requirement or to refactor your work to something cleaner). An important implication of this principle is that you need to know your audience, even when that audience is yourself. For example, if you are creating a model for maintenance developers, what do they really need? Do they need a 500 page comprehensive document or would a 10 page overview of how everything works be sufficient? Don't know? Go talk to them and find out. 
Multiple Models. You potentially need to use multiple models to develop software because each model describes a single aspect of your software. “What models are potentially required to build modern-day business applications?”  Considering the complexity of modern day software, you need to have a wide range of techniques in your intellectual modeling toolkit to be effective (see Modeling Artifacts for AM for a start at a list and Agile Models Distilled for detailed descriptions).  An important point is that you don't need to develop all of these models for any given system, but that depending on the exact nature of the software you are developing you will require at least a subset of the models. Different systems, different subsets. Just like every fixit job at home doesn't require you to use every tool available to you in your toolbox, over time the variety of jobs you perform will require you to use each tool at some point. Just like you use some tools more than others, you will use some types of models more than others. For more details regarding the wide range of modeling artifacts available to you, far more than those of the UML as I show in the essay Be Realistic About the UML, please refer to the white paper The Object Primer -- An Introduction to Techniques for Agile Modeling. 
Quality Work. Nobody likes sloppy work. The people doing the work don't like it because it's something they can't be proud of, the people coming along later to refactor the work (for whatever reason) don't like it because it's harder to understand and to update, and the end users won't like the work because it's likely fragile and/or doesn't meet their expectations. 
Rapid Feedback. The time between an action and the feedback on that action is critical. By working with other people on a model, particularly when you are working with a shared modeling technology (such as a whiteboard, CRC cards, or essential modeling materials such as sticky notes) you are obtaining near-instant feedback on your ideas. Working closely with your customer, to understand the requirements, to analyze those requirements, or to develop a user interface that meets their needs, provides opportunities for rapid feedback. 
Software Is Your Primary Goal.  The goal of software development is to produce software that meets the needs of your project stakeholders in an effective manner.  The primary goal is not to produce extraneous documentation, extraneous management artifacts, or even models.  Any activity that does not directly contribute to this goal should be questioned and avoided if it cannot be justified in this light. 
Travel Light. Every artifact that you create, and then decide to keep, will need to be maintained over time. If you decide to keep seven models, then whenever a change occurs (a new/updated requirement, a new approach is taken by your team, a new technology is adopted, ...) you will need to consider the impact of that change on all seven models and then act accordingly. If you decide to keep only three models then you clearly have less work to perform to support the same change, making you more agile because you are traveling lighter. Similarly, the more complex/detailed your models are, the more likely it is that any given change will be harder to accomplish (the individual model is "heavier" and is therefore more of a burden to maintain). Every time you decide to keep a model you trade-off agility for the convenience of having that information available to your team in an abstract manner (hence potentially enhancing communication within your team as well as with project stakeholders). Never underestimate the seriousness of this trade-off. Someone trekking across the desert will benefit from a map, a hat, good boots, and a canteen of water they likely won't make it if they burden themselves with hundreds of gallons of water, a pack full of every piece of survival gear imaginable, and a collection of books about the desert. Similarly, a development team that decides to develop and maintain a detailed requirements document, a detailed collection of analysis models, a detailed collection of architectural models, and a detailed collection of design models will quickly discover they are spending the majority of their time updating documents instead of writing source code.


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.


Core Practices:
Active Stakeholder Participation. An expansion of XP's On-Site Customer which describes the need to have on-site access to users that have the authority and ability to provide information pertaining to the system being built and to make pertinent and timely decisions regarding the requirements, and prioritization thereof. AM expands XP's On-Site Customer practice to have project stakeholders -- including direct users, their management, senior management, operations staff, and support (help desk) staff -- actively involved in the project. This includes making timely resourcing decisions by senior management, public and private support for the project by senior management, active participation of operations and support staff in the development of requirements and models pertaining to their respective areas. 
Apply The Right Artifact(s). Each artifact has its own specific applications. For example, a UML activity diagram is useful for describing a business process, whereas the static structure of your database is better represented by a physical data or persistence model. Very often a diagram is a better choice than source code -- If a picture is worth a thousand words then a model is often worth 1024 lines of code when applied in the right circumstances (a term borrowed from Karl Wieger’s Software Requirements) because you can often explore design alternatives more effectively by drawing a couple diagrams on whiteboards with your peers than you can by sitting down and developing code samples. The implication is that you need to know the strengths and weaknesses of each type of artifact so you know when and when not to use them.  Note that this can be very difficult because you have Multiple Models available to you, in fact the essay Artifacts For Agile Modeling: The UML and Beyond lists over 30 types of models and it is by no means definitive. 
Collective Ownership. Everyone can work on any model, and in fact any artifact on the project, if they need to. 
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 project lifecycle, and some even promote the concept of writing tests first before writing software (this is an XP practice). 
Create Several Models in Parallel. Because each type of model has its strengths and weaknesses no single model is sufficient for your modeling needs. For example when you are exploring requirements you may need to develop some essential use cases or user stories, an essential UI prototype, and some business rules. In combination with the practice of iterating to another artifact agile modelers will often discover that they are far more productive working on several models simultaneously than if they are only focusing on one at any given time. 
Create Simple Content. You should keep the actual content of your models -- your requirements, your analysis, your architecture, or 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 -- if you do not have a requirement to add system auditing features then don't add that features to your models. Have the courage to trust that you can in fact add this feature when, and if, it is ever asked of you. This is along the lines of XP's practice of Simple Design. 
Depict Models Simply. When you consider the potential diagrams that you could apply (UML diagrams, user interface diagrams, data models, and so on) you quickly realize that the majority of the time you only require a subset of the diagramming notation available to you. A simple model that shows the key features that you are trying to understand, perhaps a class model depicting the primary responsibilities of classes and the relationships between them, often proves to be sufficient.  Yes, you could model all the scaffolding code that you will need to write, all the getter and setter operations that your coding standards tell you to use, but what value would that add? Very little. 
Display Models Publicly. You should display your models publicly, often on something called a "modeling wall" or a "wall of wonder." This supports Open and Honest Communication on your team because all of the current models are quickly accessible to them, as well as with your project stakeholders because you aren't hiding anything from them. Your modeling wall is where you post your models for everyone to see; the modeling wall should be accessible to your development team and other project stakeholders. Your modeling wall may be physical, perhaps a designated whiteboard for your architecture diagram(s) or a place where you tape a printout of your physical data model. Modeling walls can be virtual, such as an internal Web page that is updated with scanned images.  See Ellen Gottesdiener's Specifying Requirements With a Wall of Wonder for a similar viewpoint. 
Iterate To Another Artifact. When you are working on a development artifact -- such as a use case, CRC card, sequence diagram, or even source code -- and find that you are stuck then you should consider working on another artifact for the time being. Each artifact has its strengths and weaknesses, each artifact is good for a certain type of job. Whenever you find 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, then that's a sign that you should iterate to another artifact. For example, if you are working on an essential use case then you may want to consider changing focus to start working on an essential UI prototype, a CRC model, a business rule, a system use case, or a change case. By iterating to another artifact you immediately become "unstuck" because you are making progress working on that other artifact. Furthermore, by changing your point of view you often discover that you address whatever it was that causing you to be stuck in the first place.  See the essay Iterate to Another Artifact for more thoughts. 
Model In Small Increments. Incremental development in which you organize a larger effort into smaller portions that you release over time, hopefully in increments of several weeks or a month or two, increases your agility by enabling you to deliver software into the hands of your users faster. 
Model With Others. When you Model With a Purpose you often find that you are modeling to understand something, that you are modeling to communicate your ideas to others, or you are seeking to develop a common vision on your project. This is a group activity, one in which you want the input of several people working together effectively. You will often find that your development team needs to work together to create the core set of models critical to your project. For example, to develop the metaphor or architecture for you system, you will often need to model with a group of people to develop a solution everyone agrees on as well as one that is as simple as possible. Most of the time the best way to do this is to talk the issue through with one or more people. 
Prove It With Code. A model is an abstraction, one that should accurately reflect an aspect of whatever you are building.  But will it work? To determine so, you should prove your model with code. You've developed a sketch of an HTML page for accepting billing address information? Code it and show the resulting user interface to your users for feedback. You've developed a UML sequence diagram representing the logic to implement a complex business rule? Write the testing code, the business code, and run the tests to ensure that you've gotten it right. Never forget that with an iterative approach to software development, the norm for the vast majority of projects, that modeling is only one of many tasks that you will perform. Do some modeling, do some coding, do some testing (amongst other things). 
Use The Simplest Tools. The vast majority of models can be drawn on a whiteboard, on paper or even the back of a napkin. Whenever you want to save one of these diagrams you can take a picture of it with a digital camera, or even simply transcribe it onto paper. This works because most diagrams are throwaways; their true value comes from drawing them to think through an issue, and once the issue is resolved the diagram doesn’t offer much value. As a result a whiteboard and markers are often your best modeling tool alternative: Use a drawing tool to create diagrams to present to important project stakeholders and occasionally use a modeling tool if and only if they provide value to my programming efforts such as the generation of code. Think of it like this: If you’re creating simple models, often models that are throwaways because if you are modeling to understand you likely don’t need to keep the model(s) around any more once you do understand the issue, then you likely don’t need to apply a complex modeling tool.

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

Refactoring. This is a coding practice in which you make small changes, called refactorings, to your code to support new requirements or to keep your design as simple as possible.  From the view of AM this practice ensures that your design remains clean and clear as you work on your code. Refactoring is an integral part of XP.  You can read more about code refactoring and database refactoring here. 
Test-First Design. This is a development practice where you first consider and then code a test case before writing the business code which satisfies this test case.  From the point of view of AM this practice forces you to think through your design before you write your code, removing the need for detailed design modeling. Test-first design is an integral part of XP and you can read more about it here.

When Is a Model Agile?
To understand AM you need to understand the difference between a model and an agile model. A model is an abstraction that describes one or more aspects of a problem or a potential solution addressing a problem. Traditionally, models are thought of as zero or more diagrams plus any corresponding documentation.  However non-visual artifacts such collections of CRC cards, a textual description of one or more business rules, or the structured English description of a business process are also considered to be models. An agile model is a model that is just barely good enough.  But how do you know when a model is good enough?  Agile models are good enough when they exhibit the following traits: 
1. Agile models fulfill their purpose.  Sometimes you model to communicate, perhaps you need to communicate the scope of your effort to senior management, and sometimes you model to understand, perhaps you need to determine a design strategy to implement a collection of Java classes.  For an agile model to be sufficient it clearly must fulfill the purpose for which it is created.

2. Agile models are understandable. Agile models are understandable by their intended audience.  A requirements model will be written in the language of the business that your users comprehend whereas a technical architecture model will likely use technical terms that developers are familiar with.  The modeling notation that you use affects understandability – UML use case diagrams are of no value to your users if they don’t understand what the notation represents.  In this case you would either need to use another approach or educate them in the modeling technique.   Style issues, such as avoiding crossing lines, will also affect understandability – messy diagrams are harder to read than clean ones.  The level of detail in your models, see below, can also affect understandability because a highly detailed model is harder to comprehend than a less detailed one.  Simplicity, see below, is similarly a factor that affects understandability.

3. Agile models are sufficiently accurate.  Models often do not need to be 100% accurate, they just need to be accurate enough.  For example, if a street map is missing a street, or it shows that a street is open but you discover it's closed for repairs, do you throw away your map and start driving mayhem through the city?  Likely not.  You might decide to update your map, you could pull out a pen and do it yourself or go to the local store and purchase the latest version (which still might be out of date), or you could simply accept that the map isn't perfect but still use it because it is good enough for your purposes – you can use it to get around because it does accurately model most of the other streets in your town.  The reason why you don't discard your street map the minute your find an inaccuracy is because you don't expect the map to be perfect nor to you need it to be.  Similarly, when you find a problem in your requirements model, or in your data model, you would choose to either update the model at that point or accept it as it is – good enough but not perfect.  Some project teams can tolerate inaccuracies whereas others can't: the nature of the project, the nature of the individual team members, and the nature of the organization will decide this.  Sufficient accuracy depends both on the audience of the model as well as the issues that it's trying to address.

4. Agile models are sufficiently consistent.  An agile model does not need to be perfectly consistent with itself or with other artifacts to be useful.  If a use case clearly invokes another in one of its steps then the corresponding use case diagram should indicate that with an association between the two use cases that is tagged with the UML stereotype of <>.  However, you look at the diagram and it doesn’t!  Oh no, the use case and the diagram is inconsistent!  Danger Will Robinson, Danger!  Red alert!  Run for your lives!  Wait a minute, your use case model is clearly inconsistent yet the world hasn’t come to an end.  Yes, in an ideal world all of your artifacts would be perfectly consistent, but no, it often doesn’t work out that way.   When I’m building a simple business application I can tolerate some inconsistencies.  Granted, sometimes I can’t tolerate inconsistencies – witness NASA’s recent learning experience regarding the metric and imperial measuring systems when they accidentally slammed a space probe into Mars in 1999.  The point to be made is that an agile model is consistent enough and no more, you very often do not need a perfect model for it to be useful.

5. Agile models are sufficiently detailed.  A road map doesn't indicate each individual house on each street.  That would be too much detail and thus would make the map difficult to work with. However, when a street is being built I would imagine the builder has a detailed map of the street that shows each building, the sewers, electrical boxes, and so on in enough detail that makes the map useful to him.  This map doesn’t depict the individual patio stones that make up the walk way to each, once again that would be too much detail.  Sufficient detail depends on the audience and the purpose for which they are using a model – drivers need maps that show streets, builders need maps that show civil engineering details.

Consider an architecture model.  Depending on the nature of your environment a couple of diagrams drawn on a whiteboard that are updated as the project goes along may be sufficient.  Or perhaps several diagrams drawn using a CASE tool is what you need.  Or perhaps the same diagrams supported with detailed documentation is required.  Different projects have different needs.  In each of these three examples you are in fact developing and maintaining a sufficiently detailed architecture model, it's just that "sufficiently detailed" depends on the situation.


6. Agile models provide positive value.  A fundamental aspect of any project artifact is it should add positive value.  Does the benefit that an architecture model brings to your project outweigh the costs of developing and (optionally) maintaining it?  An architecture model helps to solidify the vision to which your project team is working towards, which clearly has value.  But, if the costs of that model outweigh the benefits, then it no longer provides positive value.  Perhaps it was unwise to invest $100,000 developing a detailed and heavily documented architecture model when a $5,000 investment resulting in whiteboard diagrams would have done the job.

7. Agile models are as simple as possible.  You should strive to keep your models as simple as possible while still getting the job done.  Simplicity is clearly affected by the level of detail in your models, but it also can be affected by the extent of the notation that you apply.  For example, UML class diagrams can include a myriad of symbols, including Object Constraint Language (OCL), yet most diagrams can get by with just a portion of the notation.  You often don't need to apply all the symbols available to you so limit yourself to a subset of the notation that still allows you to get the job done.

Therefore, the definition for an agile model is that it is a model that fulfills its purpose and no more; is understandable to its intended audience; is simple; sufficiently accurate, consistent, and detailed; and investment in its creation and maintenance provides positive value to your project.  

A common philosophical question is whether or not source code is a model, and more importantly is it an agile model.  If you were to ask me outside of the scope of this writing effort my answer would be yes, source code is a model, albeit a highly detailed one, because it clearly is an abstraction of your software.  I would also claim that well written code is an agile model.  Be that as it may I will distinguish between source code and agile models for the simple reason that I need to treat the two different from one another – agile models help to get you to source code.


What Is(n't) Agile Modeling
I am a firm believer that when you are describing the scope of something, be it a system or in the case of AM a methodology, that you should describe both what it is and what it isn’t.  The following points describe the scope of AM:

1.      AM is an attitude, not a prescriptive process.  AM comprises a collection of values that agile modelers adhere to, principles that agile modelers believe in, and practices that agile modelers apply.  AM describes a style of modeling, when used properly in agile environments, that results in better quality software and faster development while avoiding over-simplification and unrealistic expectations.  AM is not cookbook approach to development – if you’re looking for detailed instructions for creating Unified Modeling Language (UML) sequence diagrams or drawing user interface flow diagrams then you need to pick up one of the many modeling books listed in the essay Modeling Artifacts.  In particular I highly suggest my own book The Object Primer 2/e (although naturally I’m biased).

2.      AM is a supplement to existing methods, it is not a complete methodology.  The primary focus of AM is on modeling and its secondary focus is on documentation.  That’s it.  AM techniques should be used to enhance modeling efforts of project teams following agile methodologies such as eXtreme Programming, Dynamic Systems Development Method (DSDM), and Crystal Clear. AM can also be used with prescriptive processes such as the Unified Process although will not be as successful the less agile the process is.

3.      AM is a way to work together effectively to meet the needs of project stakeholders.  Agile developers work as a team with their project stakeholders, who in turn take a direct and active role in the development of the system.  There is no “I” in “agile” (Canadian spelling, eh).

4.      AM is effective and is about being effective.  As you read more about AM one of the things that should become poignant to you is AM’s ruthless focus on being effective.  AM tells you to maximize the investment of your project stakeholders, to create a model or document when you have a clear purpose and understand the needs of its audience, to apply the right artifacts to address the situation at hand, and to create simple models whenever you can.

5.      AM is something that works in practice, it isn’t an academic theory. The goal of AM is to describe techniques for modeling systems in an effective manner, one that is both efficient and sufficient for the task at hand.

6.      AM is not a silver bullet.  Agile modeling is an effective technique for improving the software development efforts of many professionals.  That’s it, nothing more.  It isn’t magic snake oil that will solve all of your development problems.  If you work hard; if you stay focused; if you take AM’s values, principles, and practices to heart; then you will likely improve your effectiveness as a developer.

7.      AM is for the average developer, but is not a replacement for competent people.  AM’s values, principles, and practices are straightforward, many of which you have likely been following or wish you had been following for years.  You don’t have to walk on water to be able to apply AM’s techniques, but you do need to have basic software development skills.  The hardest thing about AM is that it prods you to learn a wide range of modeling techniques, a long and continuing activity.  Learning to model can seem difficult at first, and it is, but you can do it you choose to learn a technique at a time.

8.      AM is not an attack on documentation.  Agile modelers create documentation that maximizes their investment in its creation and maintenance.  Agile documentation is as simple as possible, as minimal as possible, has a distinct purpose that is directly related to the system being developed, and has a defined audience whose needs are understood.  

9.      AM is not an attack on CASE tools.  Agile modelers use tools that provide positive value by helping to make then more effective as a developer.  Furthermore, they always strive to use the simplest tool that gets the job done.

10.   AM is not for everyone.  More on this in the essays listed below.



When Will Agile Modeling Likely Work For You?
Agile Modeling isn’t going to work for everybody; it isn’t a panacea that works in every situation.  Nor is it guaranteed to work even in situations where conditions are perfect – you can still make mistakes implementing AM within your organization.  Having said that, my experience is that AM has the potential to be effective when the following factors hold true:

1.      You are taking an agile approach to software development.  AM isn’t a complete methodology, it is presented under the assumption that it will be applied within the scope of another process.  For this to work successfully there must be a conceptual fit between AM and this other process, otherwise you will be forced to hobble one or more of AM’s techniques and therefore not truly be doing AM.

2.      You are working iteratively and incrementally.  Effective communication and feedback, two of AM’s practices, require an iterative and incremental approach to software development.

3.      Uncertain or volatile requirements.  Martin Fowler, in The New Methodology, points out that if your project is exploratory in nature, and many are, then it is very likely that an agile approach to development is best suited.  When your requirements aren’t certain, or actively changing, then you need to follow a software process that reflects this fact.  AM deals with changing requirements by embracing change, but taking an incremental approach to development, by seeking rapid feedback, and insisting on active participation of project stakeholders so that the requirements may be quickly and effectively explored.

4.      Your primary goal is to develop software.  This is one of AM’s core principles, something that is not always the case for many projects.  For example, sometimes a project team’s primary goal is to make money from your customers (often the case in outsourcing situations) or simply to specify the system so it can be given to another team to implement.  Even worse, some development efforts are simply a political exercise with no intention of delivering anything more than a perception that something is being done.  The goal of software development should be to produce systems that meet the needs of their users in an effective manner – if you are doing anything less then AM is not for you.

5.      You must have active stakeholder support and involvement.  Fowler also believes that for agile software development efforts to be a success you should have the active support and involvement of your project stakeholders. A project stakeholder is anyone potentially affected by the development and/or deployment of a software project.  This includes direct users, indirect users, managers, senior managers, operations staff members, support (help desk) staff members, testers, developers working on other systems that integrate or interact with this one, and maintenance professionals.  To be successful with AM you need to know who your project stakeholders are, you must have access to stakeholders on a daily basis who are able to provide information and make decisions in a timely manner, and have full management support for your project.

6.      The development team must be in control of its destiny.  Agile software development, and Agile Modeling is particular, is new to most organizations.  Adopting agile approaches will be difficult at best for many organizations because it is a significantly new way to work for most people.  To be successful my experience is that project teams must be given the opportunity to succeed or fail on their own merits.  The must be in a position to try new techniques and be given the resources, including time, to let them run their course.  Your organizational environment must have minimal politics, implying that both management and other groups within your organization need to get out of your way. 

7.      A true champion for AM exists.  Whenever you adopt something new there will always be challenges.  People don’t like to change, they are often happy working in the non-agile way that they are used to.  Others see things differently than you, or simply don’t recognize the problems that you are trying to address by adopting AM.  Perhaps they are promoting their own pet approaches to development, approaches that don’t fit well with AM.  Perhaps AM threatens the current power structure within your organization.  Regardless of the situation there will always be people who will fight change.  To be successful at change someone must exist that champions the new cause, in this case adoption of AM, someone willing garner support of project stakeholders and to protect and nurture AM efforts as they take root within your organization.  Change takes time, and champions buy you that time.

8.      You require responsible and motivated developers.  Fowler points that agile software development requires developers that have the discipline to work together to develop quality software. The implication is that you need a healthy team environment, one in which people trust one another and help each other to succeed. Contrary to what many of the detractors of agile development will tell you, my experience is that you don’t need people that can walk on water instead you simply need people who want to get the job done and who have the ability to work with others effectively.

9.      You have adequate resources available to you.  You will see that agile modeling requires people to work together closely.  The implication is that you need “co-location space(s)”, such as a dedicated modeling room to work in, a public wall to display your models on, and ideally even shared workstations for pair development efforts.  Furthermore you need access to modeling tools such as whiteboards, index cards, markers, and CASE tools as necessary.  I’ve seen lack of basic resources such as decent chairs, tables, food, drink, and top-notch workstations dramatically hamper software development efforts.  If your project team is being nickel-and-dimed to death then I have to question if your project is important to your organization – if it isn’t cancel it now and invest your efforts on something more productive.

 


But This Isn't My Situation....
So what do you do when one or more of these factors does not hold true?  Try to change your situation.  No champion for AM exists?  Then become the champion.  Not allowed to work iteratively and incrementally?  Negotiate with senior management, convince them that there are better ways to work, ask them to give you a chance to prove it to them.  Don’t have adequate resources?  Communicate the importance of this to your management.  Once you’ve changed the situation the best you can, if you’re still missing a few factors then you need to choose one of the following options:

1.      Partially adopt AM.  You can adopt as many of the principles and practices of AM as possible, you won’t be truly doing AM but you will likely be more productive as a developer.  Once your organization discovers that there are better ways to develop software perhaps they will be more willing to change the factors required to fully adopt AM.  In other words, ease into agile modeling.

2.      Give up on AM within your organization.  Personally, I don’t like this option but I have to admit that it’s a valid one.  The reality is that AM isn’t for everyone and perhaps your organization is one where AM simply isn’t a good fit.

3.      Start looking for employment elsewhere.  There are a lot of organizations out there that are choosing to succeed at the software development game, organizations that are more than willing to hire motivated software developers. 

  

When Won’t Agile Modeling Work For You?
I suspect that you are likely to run into trouble with Agile Modeling in the following situations: 

One or more of the factors listed above isn’t there.  

Your organizational culture is geared towards prescriptive processes.  There are many organizations that simply aren’t interested in taking an agile approach to software development.  These organizations are happy with the status quo and that’s fine by them.  This likely includes organizations such as Government agencies, large established firms (banks, insurance companies, telecommunications firms, …), and consulting firms that specialize in serving these organizations. This isn’t to say that it’s impossible to adopt AM in these organizations, but it is likely that an extraordinary effort such as an off-site effort will be required to be successful.  

You have a large and/or distributed team.  Agile modeling works very well on teams that are co-located in the same work area, particularly when the developers are co-located in a shared work room (often called a “tiger team” room).  You can attempt to apply AM on large or distributed teams, I discuss this very situation with respect to architectural modeling, but you will find that communication challenges quickly get in the way.



When Are You Agile Modeling? 
1. Your customers/users are active participants in your requirements and/or analysis modeling efforts. 
2. Changing requirements are welcomed and acted upon accordingly – there is no “requirements freeze”. 
3. You are working on the highest priority requirements first, as prioritized by your project stakeholders, and in turn focusing on highest risk issues as work progresses. 
4. You are taking an iterative and incremental approach to modeling. 
5. Your primary focus is on the development of software, not documentation or the models themselves. 
6. You are modeling as a team where everyone’s input is welcome. 
7. You are actively trying to keep things as simple as possible – You are using the simplest tools available to you and creating the simplest model(s) that do the job. 
8. You are discarding most, if not all, of your models as development progresses. 
9. Customers/business owners make business decisions, developers make technical decisions. 
10. The content of your models is recognized as being significantly more important than the format/representation of that content. 
11. How you will test what you are describing with your model(s) is a critical issue being continually considered as you model. 
  

When Aren’t You Agile Modeling? 
1. Your goal is to produce documentation, such as a requirements document, for sign-off by one or more project stakeholders. 
2. You are using a case tool to specify the architecture and/or design of your software BUT not using that specification to generate part or all of your software. 
3. Your customers/users have limited involvement with your efforts.  For example they are involved with initial development of requirements, perhaps are available on a limited basis to answer questions, and at a later date will be involved in one or more acceptance reviews of your work. 
4. You are focusing on a single model at a time.  Common examples are “use case modeling sessions”, “class modeling sessions”, or “data modeling sessions.”  The root cause of this problem is typically “one artifact developers” such as people specialized in data modeling or user interface modeling – with AM generalists should be leading the effort. 
5. You are working towards a freeze of one or more of your models – In other words you are taking a serial approach. 
6. You are delivering models and/or documentation to another team who will then evolve the system further.  In other words you are “handing off” your work in a serial manner.