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?

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 evolutionary (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. 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 project 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 project.  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.

Recommended Resources

		The Object Primer 3rd Edition: Agile Model Driven Development with UML 2 is an important reference book for agile modelers, describing how to develop 35 types of agile models including all 13 UML 2 diagrams.  Furthermore, this book describes the techniques of the Full Lifecycle Object Oriented Testing (FLOOT) methodology to give you the fundamental testing skills which you require to succeed at agile software development.  The book also shows how to move from your agile models to source code (Java examples are provided) as well as how to succeed at implementation techniques such as refactoring and test-driven development (TDD).  The Object Primer also includes a chapter overviewing the critical database development techniques (database refactoring, object/relational mapping, legacy analysis, and database access coding) from my award-winning Agile Database Techniques book.
		Agile Modeling: Effective Practices for Extreme Programming and the Unified Process is the seminal book describing how agile software developers approach modeling and documentation.  It describes principles and practices which you can tailor into your existing software process, such as XP, the Rational Unified Process (RUP), or the Agile Unified Process (AUP), to streamline your modeling and documentation efforts.  Modeling and documentation are important aspects of any software project, including agile projects, and this book describes in detail how to elicit requirements, architect, and then design your system in an agile manner.
		The Elements of UML 2.0 Style describes a collection of standards, conventions, and guidelines for creating effective UML diagrams. They are based on sound, proven software engineering principles that lead to diagrams that are easier to understand and work with.  These conventions exist as a collection of simple, concise guidelines that if applied consistently, represent an important first step in increasing your productivity as a modeler.  This book is oriented towards intermediate to advanced UML modelers, although there are numerous examples throughout the book it would not be a good way to learn the UML (instead, consider The Object Primer).  The book is a brief 188 pages long and is conveniently pocket-sized so it's easy to carry around.

Let Us Help

We actively work with clients around the world to improve their information technology (IT) practices, typically in the role of mentor/coach, team lead, or trainer.  A full description of what we do, and how to contact us, can be found at Scott W. Ambler + Associates.