Agile Models Are Paintings, Not Photographs.
Photograph of the night sky Models are useful as tools of discovery. The process of creating a model is just as important as the model itself, often more. When you are unsure about how to proceed you can model to get your direction. When confronted with code that defies understanding modeling can help. Models include flowcharts, class diagrams, interaction diagrams, UI mock ups, etc. There are many different model types well suited to learning new things about your project.
 Models can become very anti-agile if you let them. Don't think of models like a photograph, instead consider them like a painting. Above is a photograph of the night sky. It correctly notes the position and size of all the stars. Above right is a Van Gogh painting of the night sky. The artist is communicating something important about the sky. Van Gogh is telling us his impression of what a night sky means. This is exactly how you want to approach modeling.
 "If you understand your painting beforehand, you might as well not paint it." Salvador Dali could just as easily have been talking about Agile models. Create them to understand. Printing huge models generated by a tool from code is another way to view your code but it isn't an Agile model. A painting of your code that highlights important objects and interactions for a specific operation or process step is an Agile model.
 The best modeling tools are an old fashioned fountain pen and an artist's blank sketch book with pages that pull out. These simple tools let each model be unique with a language of its own. Some things will be exaggerated, others omitted. A model should express the modeler's
Van Gogh, Starry Night
thoughts and subjective point of view. So be creative, use a drop shadow to indicate more important objects, put a shinning star on newly created objects, try drawing little stacks to show collections. UML was created to document complexity, not expose it. Instead of the typical class hierarchy diagram try an instance diagram to find complexity. Don't let conventions stop you from communicating your thoughts rather than details.
 Don't spend time getting everything just right. You certainly don't want to spend time getting all the lines straight. When modeling ask yourself a simple question: How much effort should I put into this model if it will be thrown away tomorrow? That is how you know when you are done modeling.
 CRC cards can be used two different ways. Originally a card would have class name, responsibilities, and collaborations. The second way is more Agile. Get your team together and use cards as instances instead of classes. Move the cards around with your hands to show messages and interactions. Stack them to show collections. Overlap them to show collaborations. Designing this way uses the artistic right side of your brain, the side that understands relationships and movement. You will find that you don't need to label more than a few cards to tell them apart.
 Sometimes the activity of modeling can be more important than the model. Agile CRC cards are an expression of that. You model together as a team. At the end the model disappears but the understanding, insight, and team collaboration remains. Designing this way is more dynamic and object oriented than static versions.
 Create a model to answer specific questions, keep the answer short and concise. If you think others could learn from your model you can keep the document, but make it Agile. Saving a document is an implicit agreement to keep it up to date or destroy it. Restrict documents to one page and post them on a wall. Then you can easily update them by finding all the old versions and replacing them with the new edition. If you decide to destroy it, just pull down all the obsolete pages and throw them out.
Agile documents on a wall
 Depending on your project you may also need some larger documents for validation or standards compliance. Those are not Agile documents but need to be created and archived anyway. Don't use your Agile process as an argument to avoid creating them. Create them just-in-time and as efficiently as possible.
 Having a model printed out with straight lines and square corners in a specially labeled binder does not mean you have a good design, it just means you have a well documented one. I have found that a huge UML document is an excellent way to hide a complex design. Agile modeling can help discover areas of complexity and eliminate them. You can use tools that create diagrams as an alternative to browsing source code, but not as an alternative to Agile modeling. Agile Process Proverbs home | Agile Process Proverbs | About the Author

Copyright 2009 Don Wells all rights reserved.