Defining “Agile Model”: When Is a Model Agile?
- Agile models fulfill their purpose. Sometimes you model to communicate, perhaps you need to communicate the scope of your effort to senior management, and sometimes you model to understand, perhaps you need to determine a design strategy to implement a collection of Java classes. For an agile model to be sufficient it clearly must fulfill the purpose for which it is created.
- Agile models are understandable. Agile models are understandable by their intended audience. A requirements model will be written in the language of the business that your users comprehend whereas a technical architecture model will likely use technical terms that developers are familiar with. The modeling notation that you use affects understandability – UML use case diagrams are of no value to your users if they don’t understand what the notation represents. In this case you would either need to use another approach or educate them in the modeling technique. Style issues, such as avoiding crossing lines, will also affect understandability – messy diagrams are harder to read than clean ones. The level of detail in your models, see below, can also affect understandability because a highly detailed model is harder to comprehend than a less detailed one. Simplicity, see below, is similarly a factor that affects understandability.
- Agile models are sufficiently accurate. Models often do not need to be 100% accurate, they just need to be accurate enough. For example, if a street map is missing a street, or it shows that a street is open but you discover it’s closed for repairs, do you throw away your map and start driving mayhem through the city? Likely not. You might decide to update your map, you could pull out a pen and do it yourself or go to the local store and purchase the latest version (which still might be out of date), or you could simply accept that the map isn’t perfect but still use it because it is good enough for your purposes – you can use it to get around because it does accurately model most of the other streets in your town. The reason why you don’t discard your street map the minute your find an inaccuracy is because you don’t expect the map to be perfect nor to you need it to be. Similarly, when you find a problem in your requirements model, or in your data model, you would choose to either update the model at that point or accept it as it is – good enough but not perfect. Some teams can tolerate inaccuracies whereas others can’t: the nature of the initiative, the nature of the individual team members, and the nature of the organization will decide this. Sufficient accuracy depends both on the audience of the model as well as the issues that it’s trying to address.When I was a teenager I worked in restaurants, starting out as a dishwasher and working my way up to swing manager. As a swing manager I was taught how to close out the restaurant for the day, an important part of which was closing the till at the end of the day. The manager who taught me this was a firm believer in having an accurate count of the money in the till, and if it didn’t add up exactly to the sales for the day we needed to recount. Not only did this include counting the paper money but the coins as well, an effort that on average took twenty minutes each evening. A few months later she transferred to another restaurant and a new manager took over. We were closing together one night and he saw me counting the coins and couldn’t believe I was wasting my time counting them one by one. He then showed me how he counted coins – in his hands he’d pick up each denomination of coin one at a time, look at them, guess how much they added up to, and as long as his count was within a few dollars he’d accept it and move on. A twenty-minute activity was reduced to five minutes because he realized that his count just needed to be close and not exact. He was getting home fifteen minutes earlier six nights a week fifty weeks a year, a savings of seventy-five hours a year over a thirty year career.
- Agile models are sufficiently consistent. An agile model does not need to be perfectly consistent with itself or with other artifacts to be useful. If a use case clearly invokes another in one of its steps then the corresponding use case diagram should indicate that with an association between the two use cases that is tagged with the UML stereotype of <>. However, you look at the diagram and it doesn’t! Oh no, the use case and the diagram is inconsistent! Danger Will Robinson, Danger! Red alert! Run for your lives! Wait a minute, your use case model is clearly inconsistent yet the world hasn’t come to an end. Yes, in an ideal world all of your artifacts would be perfectly consistent, but no, it often doesn’t work out that way. When I’m building a simple business application I can tolerate some inconsistencies. Granted, sometimes I can’t tolerate inconsistencies – witness NASA’s recent learning experience regarding the metric and imperial measuring systems when they accidentally slammed a space probe into Mars in 1999. The point to be made is that an agile model is consistent enough and no more, you very often do not need a perfect model for it to be useful.Regarding accuracy and consistency there is clearly there is an entropy issue to consider here as well. If you have an artifact that you wish to maintain, what I call a “keeper”, then you will need to invest the resources to update it as time goes on. Otherwise it will quickly become out of date and effectively useless to you. For example, I can tolerate a map that is missing one or two streets but I can’t tolerate one that is missing three quarters of the streets in my town. There is a fine line between investing just enough effort to keep your artifacts accurate enough, investing too much effort that you are needlessly slowing your efforts down, and not investing enough to keep your artifacts useful to you.
- Agile models are sufficiently detailed. A road map doesn’t indicate each individual house on each street. That would be too much detail and thus would make the map difficult to work with. However, when a street is being built I would imagine the builder has a detailed map of the street that shows each building, the sewers, electrical boxes, and so on in enough detail that makes the map useful to him. This map doesn’t depict the individual patio stones that make up the walk way to each, once again that would be too much detail. Sufficient detail depends on the audience and the purpose for which they are using a model – drivers need maps that show streets, builders need maps that show civil engineering details. Consider an architecture model. Depending on the nature of your environment a couple of diagrams drawn on a whiteboard that are updated as the initiative goes along may be sufficient. Or perhaps several diagrams drawn using a CASE tool is what you need. Or perhaps the same diagrams supported with detailed documentation is required. Different teams have different needs. In each of these three examples you are in fact developing and maintaining a sufficiently detailed architecture model, it’s just that “sufficiently detailed” depends on the situation.
- Agile models provide positive value. A fundamental aspect of any artifact is it should add positive value. Does the benefit that an architecture model brings to your initiative outweigh the costs of developing and (optionally) maintaining it? An architecture model helps to solidify the vision to which your team is working towards, which clearly has value. But, if the costs of that model outweigh the benefits, then it no longer provides positive value. Perhaps it was unwise to invest $100,000 developing a detailed and heavily documented architecture model when a $5,000 investment resulting in whiteboard diagrams would have done the job.
- Agile models are as simple as possible. You should strive to keep your models as simple as possible while still getting the job done. Simplicity is clearly affected by the level of detail in your models, but it also can be affected by the extent of the notation that you apply. For example, UML class diagrams can include a myriad of symbols, including Object Constraint Language (OCL), yet most diagrams can get by with just a portion of the notation. You often don’t need to apply all the symbols available to you so limit yourself to a subset of the notation that still allows you to get the job done.
Defining “Agile Model”
An agile model is a model that fulfills its purpose and no more; is understandable to its intended audience; is simple; sufficiently accurate, consistent, and detailed; and investment in its creation and maintenance provides positive value.
An agile definition is:
An agile model is a model that is just barely good enough.
A common philosophical question is whether or not source code is a model, and more importantly is it an agile model. If you were to ask me outside of the scope of this writing effort my answer would be yes, source code is a model, albeit a highly detailed one, because it clearly is an abstraction of your software. I would also claim that well written code is an agile model. Be that as it may I will distinguish between source code and agile models for the simple reason that I need to treat the two different from one another – agile models help to get you to source code.