Modeling is an important part of every software process, even Extreme Programming (XP). Unfortunately, many developers will tell you that modeling is a dysfunctional activity whose sole purpose is to create documentation, yet when you watch them in practice, they'll often model quite effectively. How can modeling be both dysfunctional and effective? The answer is simple: Many IT professionals are in denial. Tool vendors, academics and industry groups want us to believe that modeling is a complex endeavor that requires great discipline and complex tools. Observation of actual modeling sessions reveals that most modeling is performed quickly, using simple tools and techniques.
Impromptu Modeling
In my experience, the majority of modeling sessions involve just two or three people who discuss an issue while sketching on paper or a whiteboard. These "model-storming sessions are typically impromptu events: A project team member will identify an issue he needs to resolve and ask another teammate or two to model with him, typically for only five to 10 minutes (it's rare to model storm for more than 30 minutes). They gather around a shared modeling tool (for example, the whiteboard), explore the issue until they understand it, and then continue with their work (often, coding).
 [click for larger image] Project-Level AMDD With an agile modeling approach, modeling styles vary based on your development stage. |
You'll model storm to analyze requirements. For example, a user may tell you that the system you're building must display a chart representing the bonus schedule for sales staff. Together with a few team members, you sketch what the screen should look like, drawing several examples until you come to a common understanding of what must be built. Sketches such as these are inclusive models because you're using simple tools and modeling techniques, thus following the Agile Modeling (AM) practice of Agile Stakeholder Participation.
Because model storming is also commonly used for architecture and design, agile developers, including Extreme Programmers (XPers), don't always go straight to code once they've chosen to work on a requirement (contrary to what opponents of agile development may say). Java programmers often work through complex code by sketching a quick UML sequence diagram, XPers may create Class Responsibility Collaborator (CRC) cards on index cards to explore detailed structural design problems, and Visual Basic programmers may choose to draw flow charts to model a complex business rule.
Model Storming in Practice
A few months ago, I was invited to assess the work of a team following an agile instantiation of the Rational Unified Process (RUP), a project in which model storming was a common practice. At the project's start, the team had taken a more traditional approach, investing time in creating well-documented requirements and design specifications. As the project progressed, they discovered that they rarely used these documents, and that keeping them updated was consequently of little value. However, they understood that modeling before writing code was a very good idea and as a result, their modeling was mostly of the model-storming variety. Interestingly, their physical data model (PDM) was the only model that they deemed important enough to keep up-to-date—mainly because they generated the database schema from it.
As part of my assessment, I decided to take a field trip to the team's working environment to see how they really worked. Their open workspace enabled a high level of communication, and their user representatives had offices a few meters away. On every flat wall surface, including cabinet doors, the team had put up whiteboards covered in sketches.
I asked about the various diagrams—what they depicted, how they were used, and when they were created—and was told that approximately 80 percent had been created within the last two or three weeks. Most models created were kept on the board long enough to guide programming efforts, and then erased to make way for new models. A wide range of models was used, including screen sketches, UML state machine diagrams and several freeform diagrams. The diagrams were also of varying quality; one of the "screen sketches looked like a two-year-old had drawn it, but its meaning was clear to the people involved—the value is in the modeling, not the model. All but one of the models were drawn by a group, in accord with the AM practice Model with Others, to ensure high-quality models and transference of skills among team members.
A Perfect Storm
How do you support model storming within your environment? First, the more whiteboard space, the better. Some companies are reluctant to put up whiteboards—apparently, interior decorating concerns such as having attractive prints on the wall are far more important to them than making software development teams effective. Pretty pictures are nice, but whiteboards are far more important. Beyond available whiteboard space, you also must ensure that the whiteboards are visible to people once they're back at their workstations, so that they can easily work from them.
You'll need to develop a protocol for working on the whiteboards, to determine decisions such as when it's OK to erase something. I've provided some suggestions at www.agilemodeling.com.
Your team culture is also critical to your success: In modeling, members must feel comfortable helping others and asking others for help. Overall, you must recognize that this is a normal and effective way to work.
Ancient Modeling Secret
Is this process one of modeling's best-kept secrets? I can't remember a project in which we didn't model storm—but I can't remember reading a book or article that discussed this technique in any great detail. Wouldn't it be nice if the IT industry started talking about what we actually do in practice, instead of what we think we should be doing? Call me nave, but I rely on what works—and model storming does exactly that.
|
Beyond the Storm There are other kinds of modeling, depending on where you are in the development cycle.
Model-storming sessions are short, simple and just in time, and I believe that they comprise 90 percent of all IT modeling activities. With an Agile Model Driven Development (AMDD) approach (see "Project-Level AMDD), there are clearly other kinds of modeling based on where you are in your development. At a project's start, one or more modelers may work with a group of project stakeholders to explore their initial requirements and project scope. In parallel, team members should also model a candidate system architecture to provide technical guidance. Neither of these efforts require a lot of documentation; in fact, you're better to travel as light as possible. The goal is to reach consensus before moving on to development cycles (iterations). Craig Larman's heuristic is to have one day of initial modeling at the start of a project for each month of your project; a six-month project would therefore need roughly a week of initial modeling. Your initial modeling efforts provide a foundation for your project; your model-storming efforts help you think through how you'll build on that foundation.
Not Just Whiteboards A common misconception about Agile Modeling (AM) is that it's only about whiteboard modeling—and I can see how people may get that impression, considering how often I talk about whiteboards. But keep in mind the AM practice Use the Simplest Tools: Sometimes the simplest tool is in fact a complex, computer-aided software engineering (CASE) tool such as Computer Associates' ERWin, Borland's TogetherCC or Project Technology's BridgePoint. I favor these implementation tools because working software can be generated from the detailed modeling you create using them. Another critical feature of CASE tools is the ability to reverse-engineer a model: It's quite common to use TogetherCC to generate UML models to visually render existing Java code to help you to understand it.
Some of your models, including whiteboard sketches, will evolve into official documentation, but these activities should be viewed as documentation, not modeling—making a diagram look pretty really isn't modeling, nor is writing descriptions of what that diagram represents. Treating the documentation activity as any other requirement and identifying its associated costs usually results in the realization that documentation isn't a priority for your stakeholder (or one that he's willing to pay for). This is exactly what you want to happen, because you need a lot less documentation than you may believe (as the team I assessed clearly discovered). —SA |
Senior Contributing Editor Scott Ambler is author of the Productivity Award--winning Agile Database Techniques (Wiley, 2003)
