When Are(n’t) You Agile Modeling (AM)?

One of the biggest challenges that agile development methods face is developers claiming to be following the method, when in reality they aren’t, who then run into trouble and then proceed to blame the method which they weren’t following properly to begin with. We’re seeing this in the case of eXtreme Programming (XP) where hackers choose to hear only part of XP’s message – typically that you need less documentation – but claim to be following all of XP’s tenets. The hackers invariably produce shoddy work and/or produce software that doesn’t reflect the actual needs of their users resulting in XP being unfairly blamed for the hacker’s failure. Ideally I would like to avoid this problem with Agile Modeling (AM), although realistically the best I can hope for is to define when you are (and are not) agile modeling.

When Are You Agile Modeling?

Your customers/users are active participants in your requirements and/or analysis modeling efforts.
Changing requirements are welcomed and acted upon accordingly – there is no “requirements freeze”.
You are working on the highest priority requirements first, as prioritized by your stakeholders, and in turn focusing on highest risk issues as work progresses.
You are taking an evolutionary (iterative and incremental) approach to modeling.
Your primary focus is on the development of software, not documentation or the models themselves.
You are modeling as a team where everyone’s input is welcome.
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.
You are discarding most, if not all, of your models as development progresses.
Customers/business owners make business decisions, developers make technical decisions.
The content of your models is recognized as being significantly more important than the format/representation of that content.
You actively seek to prove your models with code, because you know that the longer you model without concrete feedback the greater at risk you are.

When Aren’t You Agile Modeling?

Your goal is to produce documentation, such as a requirements document, for sign-off by one or more stakeholders.
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.
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.
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.
You are working towards a freeze of one or more of your models – In other words you are taking a serial approach.
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.

It’s important to note that although you may not be agile modeling, often due to environmental circumstances beyond your control, that you can still apply some of the practices of AM on your team. However, just because you’re using a plain old whiteboard (POW) to draw sketches on doesn’t necessarily imply that you are agile modeling, all it implies is that you’re drawing sketches on a whiteboard.