Agile versus Formal modeling

In response to a recent discussion over at Yahoo on the requirements Engineering list, a question was posed as to why “just enough” was ever okay when creating a model.  After all incomplete models or improper use of a modeling standard has to be bad… right?  I believe there is another perspective on modeling to consider.  That is, WHY a model is being created.  I see 3 reasons for modeling;

• Modeling to communicate,
• Modeling to understand, and
• Modeling for reference.

In reverse order, Modeling for reference is the traditional goal.  It is intended to read by someone (usually at some future point in time) new to, or somehow removed from the original development effort.  The model needs to neither mislead nor have important gaps and must comply with the standards for that model type.  After all the standards allow a reader to understand the model without the original context.

Modeling to understand is a more requirements gathering effort.  The creator is the likely consumer and it is intended to be an aid, not a deliverable.  Simple and well understood things need not be included instead the models tend toward fragments being analyzed instead of depictions of the whole.  Think of them as quickly taken notes and relevant doodles done in your own handwriting using symbols likely to be meaningful only to yourself.  As such models for understanding can be, but are not required to be good historical notes about how or why a decision was made.  They are not intended to be good tools for later reference.

Last, modeling to communicate is done to share ideas or restate an understanding for validation.   They are semi-structured whiteboard-like drawings which, once done communicating their point go quickly out-of-date.  They tend to use symbols understood by the parties involved which may vary wildly from the official standards of the model type.  It is far less important to be right than to be understood.  However, should the model persist too long, or should someone from outside of the original discussion get their hands on it, clarity becomes the first causality.

Comments

• Anonymous
  April 06, 2011
  This reminds me of "No plan survives first contact....". I find myself often using the model to communicate. Usually to explain Agile, either to a client who really wants it and doesn't know why, or to a recruiter asking me "What is Scrum anyway....". In the projects of the past that require software models, infrastructure models, and process models, they aren't really consumed anyway.  We spent all of these hours modeling something that isn't going to look like the end product when "they" are done changing it anyway.  If you, as a PM, want to model things, try a model that is a result or byproduct of the plan to lay the historical ground work for the next project versus planning your own.  A graphical history is more likely to be used than a lengthy document, and I will actually resemble what you built.   Then of course, the client requires a model before you starting building, we write agile on the wall more for inspiration than bragging rights and down the two-week waterfall we go...  I love this business......