In-Depth

AM principles

• By Sott W. Ambler
• April 1, 2002

Readers familiar with Extreme Programming (XP) will recognize the similarity among these core agile modeling principles and many of the principles of XP. When applied to a software development project, these values set the stage for a collection of Agile Modeling (AM) practices.

In addition to these core principles, Scott Ambler and others in the AM community have defined several supplementary principles. These are listed on the Official Agile Modeling Web site (http://www.agilemodeling.com/).

Assume Simplicity: Keep your models as simple as possible. Do not depict additional features that you do not need today. Have the courage not to over-model your system, and the confidence that you can model based on your existing requirements; then refactor your system in the future as your requirements evolve.

Embrace Change: Requirements evolve over time, and so do people's understanding of them. Project stakeholders come and go as your project moves forward, and they can change their goals in unexpected ways. To maximize your effectiveness, your approach to development must reflect this reality.

Enabling The Next Effort Is Your Secondary Goal: While you are working, keep the future of the system you are developing in mind. Your project can still be considered unsuccessful if you fail to deliver software that is robust enough to be extended over time. As Alistair Cockburn likes to say, in the software development game, your secondary goal should be to set up to play the next game. Be sure you have an awareness of the nature of the next project -- whether you are called upon to develop the next major release of your system, or are simply involved in the operations and support of the current version. And you will want to consider whether the next project will include members of your existing team, and the importance of the next effort to your organization.

Incremental Change: When it comes to modeling, you do not need to get it right the first time. In fact, it is very unlikely you could if you tried. Furthermore, you do not need to capture every detail in your models. Consequently, there is no point in trying to develop an all-encompassing model at the start of a project. Instead, begin with a small model or perhaps a high-level model, and evolve it over time in an incremental manner. Or simply discard each model when you no longer need them. To put it simply, each model just has to be good enough at the time.

Maximize Stakeholder Investment: Your project stakeholders are investing resources -- time, money, facilities, etc. -- to have software developed that meets their needs. Your team should not fritter those resources away. And they deserve to have the final say in how those resources are invested. If it were your time and money, would you want it any other way?

Model With A Purpose: Many developers worry about the level of detail in their artifacts (models, source code, documents, etc.) and whether they are sufficiently accurate. That is putting the cart before the horse. The first thing you should consider is why you are creating a particular model, and for whom. Perhaps you need to understand an aspect of your software better. Maybe you need to communicate your approach to senior management to justify your project. Possibly, you need to create documentation that describes your system to the people who will be operating it and maintaining/evolving it over time. Once you have a clear and valid purpose for your model, and an understanding of the audience for it (even if that audience is just you), you can develop it with a level of detail and accuracy that is appropriate for that purpose and that audience. This principle also applies to changing existing models.

Multiple Models: Considering the complexity of modern-day software, you need to take advantage of the wide range of modeling techniques available to you. And you will probably need to use multiple models because each model describes a single aspect of your software. You will not need every model for every system you develop, but you will require at least a subset of the models.

Quality Work: Nobody likes sloppy work. The people doing the work do not like it because it is not something they can be proud of. The people coming along later to refactor the work do not like it because it is harder to understand and update. And the end users will not like the work because it is likely to be fragile or to not 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, analyze those requirements or develop a user interface that meets their needs [and] 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, management artifacts or models. Any activity that does not directly contribute to this goal should be questioned and avoided if it cannot be justified in light of this principle.

Travel Light: Every artifact that you create and keep will need to be maintained over time. Whenever a change occurs, you will need to consider the impact of that change on all models and then act accordingly. The fewer models you keep, the less work you have to perform to support a change -- and the more agile you are. Similarly, the more complex and/or detailed your models, the more likely it is that a given change will be harder to accomplish. Every time you decide to keep a model, you trade agility for the convenience of having that information available to your team in an abstract manner. Never underestimate the seriousness of this tradeoff. A development team that decides to 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 it is spending the majority of its time updating documents instead of writing source code.
-- Printed with the permission of Scott W. Ambler