Agile Modeling: Frequently Asked Questions (FAQ)

The goal of this FAQ is to help you to understand the Agile Modeling (AM) methodology a bit better.

1.1 What is Agile Modeling (AM)?

1.2 What is an agile model?

1.3 How does AM fit in?

1.4 What pain does AM address?

1.5 What benefits does AM provide?

1.6 How do I get started with AM?

1.7 How does AM relate to the Agile Alliance (AA)?

1.8 How did AM get its start? (Video)

2. AM in Practice

2.1 What is Agile Model Driven Development (AMDD)?

2.2 Do extreme programmers (XPers) model?

2.3 How much modeling do I need to do up front?

2.4 How much modeling should we do during development?

2.5 When do I stop modeling?

2.6 When should we update our models and documents?

2.7 Are models and documents different?

2.8 How much documentation do I need to write?

2.9 What do I do when I have an idea for a new requirement?

3. AM and “Other” Modeling Approaches

3.1 Can the UML be agile?

3.2 Why should we embrace changing requirements?

3.3 What is the difference between AM and “traditional modeling”?

3.4 Where do CASE tools fit in?

3.5 Where does the Model Driven Architecture (MDA) fit in?

1. Agile Modeling Fundamentals

1.1 What is Agile Modeling (AM)?

Agile Modeling (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. Simply put, Agile Modeling (AM) is a collection of values, principles, and practices for modeling software that can be applied on a software development team in an effective and streamlined manner. 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. 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.

Read the essay What Is(n’t) Agile Modeling? for greater details.

1.2 What is an agile model?

Agile models are more effective than traditional models because they are just barely good enough, they don’t have to be perfect. A paper prototype could be an agile model, a whiteboard sketch could be an agile model, a Visio diagram could be an agile model, or a physical data model (PDM) created using a CASE tool could be an agile model. The type of model, or the tool with which it was created doesn’t really matter. What is important is that the model is just good enough for the task at hand.

1.3 How does AM fit in?

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 RUP as depicted in the figure below. 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.

Figure. AM enhances other software processes.

1.4 What pain does AM address?

Within many traditional environments modeling and documentation are almost always dysfunctional efforts which rarely add value and sometimes even cause a team to grind to a virtual halt under the weight of the artifacts being generated. As a result many developers think that modeling and documentation are a waste of their time, and in traditional environments they’re often correct. It doesn’t have to be this way.

AM describes techniques which enable your modeling and documentation efforts to be very streamlined and effective, you can gain the benefits of modeling without the dysfunctional costs of useless documentation. Don’t get me wrong, you still document, it’s just that you do so in a very smart way.

1.5 What are the benefits of Agile Modeling?

The benefits of AM are:

Cost effectiveness. AM defines a collection of values, principles and practices pertaining to effective, streamlined modeling and documentation. By creating models and documents which are just barely good enough you maximize stakeholder ROI.
It defines explicit techniques for agile teams. AM addresses the issue of how agile developers model and document on software initiatives 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 improve modeling and documentation on teams following scaling frameworks. AM addresses the issue of how to model effectively on a team following a scaling framework such as SAFe, LeSS, or Nexus.

1.6 How do I get started with Agile Modeling?

My advice is to ease into AM gradually. You should actively strive to keep your approach to modeling as collaborative and simple as possible. Recognize that you only need to create models which are just good enough for your task at hand — models don’t need to be perfect (they never are) nor do they need to be complete, they just need to fulfill the needs of their audience right now. Model with others whenever possible, in particular the audience for your model, to ensure that you understand their needs. Of course, you should read and try to adopt as many of the principles and practices of AM as you can.

The essay Where Do I Start? provides detailed advice by job role.

1.7 How does AM support the Agile Alliance?

AM supports the Agile Alliance.

1.8 How did Agile Modeling get its start?

2. Agile Modeling In Practice

2.1 What is Agile Model Driven Development (AMDD)?

AMDD is the agile version of Model Driven Development (MDD). The following figure depicts a high-level lifecycle for AMDD for the release of a system. The initial modeling activity includes two main sub-activities, initial requirements envisioning and initial architecture envisioning. These are done during cycle (iteration) 0, the first iteration before you start into development cycles. The other activities – iteration modeling, model storming, reviews, and implementation – potentially occur during any cycle, including cycle 0. The time indicated in each box represents the length of an average session: perhaps you’ll model for a few minutes then code for several hours.

The fundamental idea is that you do just enough modeling to determine your strategy for proceeding. In the case of initial envisioning you want to model just enough to identify and agree to the initial scope of your work as well as the potential architecture for your solution. During iteration modeling, part of your iteration planning efforts, you will do just enough modeling to understand what you need to do that iteration. With model storming you will work through higher level issues that are not well addressed with code. This might be an inclusive modeling session with your stakeholder(s) to understand their requirements, or could be a quick design session with other developers to determine how to build something.

Figure 2. Taking an AMDD approach on an initiative (click to enlarge).

2.2 Do extreme programmers (XPers) model?

Yes. They create user stories, free-form sketches, and acceptance tests on a regular basis. XP even has the practice “Stand-Up Design Session” which is another term for model storming. What XPers do is take a very agile approach to their modeling efforts, in fact AM has it’s roots in XP. This is different from traditional modeling, and as a result when many traditionalists first look at XP they think that XPers aren’t modeling at all because the XPers are traveling light. See Agile Modeling Throughout the XP Lifecycle for a detailed discussion.

2.3 How much modeling do I need to do up front?

Just enough to give you a basic understanding of the high-level requirements and of a potential architectural solution. Don’t create a detailed CASE tool model when a Visio diagram will do. Don’t create a Visio diagram when a whiteboard sketch will do. Don’t write a detailed use case when an index card with bullet points will do. Everything works in your documents and models, but not always when you go to build it. The longer you spend up front modeling, the longer you defer the benefit gaining concrete feedback by proving your models with code.

You don’t need to get the details right away and even if you do they’ll change anyway. If you can do the detailed modeling up front, then surely you could also do it on a just in time (JIT) basis as well.

2.4 How much modeling should we do during development?

Just enough to get the job done, and the best way to do that is to model with a purpose and to model with the audience for your work. When you know why you’re creating a model, and what your audience (e.g. programmers, stakeholders, …) then you can model just enough. If you don’t know what they want, then you’re forced to guess what they need and will often do far more than what is required. Better still, because you model with the audience for your model(s) they learn as you do the work, the end result being that they will need far less written documentation than if they hadn’t been involved.

2.5 When do I stop modeling?

When the model fulfills its immediate purpose (therefore it doesn’t make much sense to continue working on it) OR you’re stuck (therefore you should stop being stuck and go work on something else for awhile). This idea is captured in the practice Iterate To Another Artifact.

2.6 When should we update our models and documents?

Only when it hurts enough to warrant the investment of your valuable time. Too many teams get bogged down by bureaucrats striving to get “complete documentation”, or “fully consistent” documentation, or “fully traceable” documentation or some such nonsense. The end result is that far too much time is wasted on updating documentation, and not enough on software development. Take an agile approach to documentation and travel as light as possible.

2.7 Are models and documents different?

Yes, in fact they’re orthogonal concepts. What I mean by that is that models are not necessarily documents and documents are not necessarily models. A whiteboard sketch is a model, but it’s not a very good document. A pocket novel is a document, but it’s not really a model. Sometimes models evolve into documents, but more often than not they’re discarded once they’re no longer needed.

Why is this an important distinction? Because many programmers equate the term model to document, and because they’re experiences with documentation almost always prove bad, they think that modeling isn’t a very good idea. Many developers first experience with traditional modeling is to be handed mounds of requirements and design documentation which they don’t understand, and then they rarely follow, or they’re asked to create mounds of documentation after the fact because some bureaucrat wants to make it look as if the team followed the official documentation-heavy process. Frustratingly, many developers take a near-AM approach in practice, often sketching on whiteboards and paper, but they don’t realize that they’re modeling because they’re not using a CASE tool or they’re not producing useless documentation. Hopefully AM will help to make developers aware that modeling can be quite effective in practice.

2.8 How much documentation do I need to write?

Just enough to get the job done, and that’s often far less than you need. Travel as light as possible and take an agile approach to documentation in general.

2.9 What do I do when I have an idea for a new requirement?

Developers are really smart people who often have ideas for features which they believe that a system should exhibit. That’s great! However, they need to remember that stakeholders are the source of requirements, not developers, so what they need to do is suggest the requirement to their stakeholder(s). The stakeholder(s) should consider it and prioritize it accordingly, putting it on the stack with all of the other requirements. The developers should then implement the requirement when it hits the top of the stack.

3. Agile Modeling and “Other” Modeling Approaches

3.1 Can the UML be agile?

Yes. You can apply the UML is a very agile manner or in a very non-agile manner, it’s really up to you. Keep your models simple, use the simplest tools, and model just enough to get the job done and you’ll stay fairly agile.

An important issue, however, is that the UML really isn’t sufficient for business application development, so you need to learn more than just UML techniques if you want to get the job done. Luckily, as you can see at Agile Models Distilled, there are a lot of options available to you.

3.2 Why should we embrace changing requirements?

Absolutely. People change their minds for many reasons, and do so on a regular basis. They’ll be working with an existing system and realize that they missed a requirement. Or, you’ll show them your work to date and they’ll realize that what they asked for really isn’t what they want after all. Or perhaps a competitor will release a new product which implements features that your product doesn’t. Perhaps new legislation requires new features, or changes to existing features, in your software.

If you try to “freeze” the requirements early in the lifecycle you pretty much guarantee that you won’t build what people actually need, instead you’ll build what they initially thought they wanted. That’s not a great strategy. A better approach is to treat requirements like a prioritized stack: each iteration you take a bunch of requirements off the stack and implement them, allowing your stakeholders to add to, remove from, or reprioritize existing items on the rest of the stack. It’s easy to support changing requirements, you just need to choose to do so.

3.3 What is the difference between AM and “traditional modeling”?

This is hard to answer because I don’t know what “traditional modeling” within your environment. In many organizations the traditional approach to modeling is to develop relatively detailed models before coding begins. Sometimes these models are kept up to date, sometimes they are not, and sometimes they’re even used to generate code (often a good thing). Each of these models are often created by a single, expert person who typically spends most of their time working alone. There is often a requirements/business analyst who elicits requirements from stakeholders and then captures the information in a requirements document. This requirements document is provided to the architect who develops a high-level architecture model. This model is the used by the designer(s) who create detailed design model(s), which in turn are provided to the programmers who may or may not actually follow them. This approach to model sounds great in theory, but typically results in a lot of documentation being written which for the most part gets ignored during the actual development process. In other words, it’s merely bureaucratic window dressing.

In some organizations the traditional approach to modeling is to start with some modeling up front, to abandon the effort of maintaining it during development, then once the system is delivered they go back (sometimes) and “clean up” the documentation to make it look as if they actually did the modeling. This is completely dysfunctional, but it happens.

With Agile Modeling you model with others, you should never work alone because it’s simply too dangerous to do so (you’ll inject errors without realizing it). You model just enough for the goal at hand because you know you can come back to the model later if you need to. You travel as light as possible, discarding temporary models (most models should be temporary) and keeping only the models which you actually need. You work closely with stakeholders, using inclusive modeling techniques which support active stakeholder participation. This means that a lot of your modeling is done with simple tools, although sometimes you’ll use a complex CASE tool if it adds value.

3.4 Where do CASE tools fit in?

CASE, computer aided software engineering, is an old-school term for software-based modeling tool (SBMT). I prefer the term case because it’s pronounceable. One of the practices of AM is to Use the Simplest Tool, and sometimes the simplest tool is a CASE/SBMT tool. If the tool adds actual value, and is the best one available to you, then use it. Personally, I find most CASE tools to be a colossal waste of time, either they’re too hard to use or they’re oriented towards traditional, documentation-heavy approaches. If the tool doesn’t generate and reverse engineer code, and do it very easily, then there’s a pretty good chance that it’s not adding value.

3.5 Where does the Model Driven Architecture (MDA) fit in?

For business application development the MDA is proving to be virtually inconsequential, arguably nothing more than a marketing campaign for the CASE tool vendors. For embedded software development MDA appears to have gained significant ground. If you’re thinking about taking an MDA approach I highly suggest that you determine if you’re ready for the MDA. If it is, then the Roadmap for Agile MDA is likely a good starting point.