Model Storming: An Agile Core Practice
Analysis Model Storming
You will model storm to analyze requirements. For example, a stakeholder may tell you that the system you’re building must be able to edit student information. Together you create a sketch of what the screen will look like, see Figure 1, drawing several examples until you come to a common understanding of what needs to be built. Sketches such as this are inclusive models because you”re using simple tools and modeling techniques, this enabling the Agile Modeling (AM) practice of Active Stakeholder Participation. Note that you may also have created a model such as this as part of your iteration modeling efforts, the “rules” aren’t carved in stone.
Design Model Storming
Agile developers, including XPers, don’t always go straight to code once they’ve chosen to work on a requirement (contrary to what detractors of agile development will tell you). This is because model storming is also very common for architecture and design. Java programmers will often work through complex code by sketching a quick UML sequence diagram (see Figure 2), XPers will create Class Responsibility Collaborator (CRC) cards on standard index cards (see Figure 3) to explore detailed structural design problems, and Visual Basic programmers may choose to draw flow charts to model a complex business rule (see Figure 4). Regardless of the model(s) that you need to create, you’re still model storming.
It’s important to understand that you don’t require a whiteboard to model storm, you just need a shared, inclusive tool that people can work with easily. For example, the CRC cards of Figure 3 are written on index cards, not drawn on a whiteboard.
Why Does This Work?
Why does model storming on a JIT basis work much better than trying to model everything up front? For several reasons:
- The requirements are going to change throughout the initiative, like it or not.
- By waiting to analyze the details JIT, you have much more domain knowledge than if you had done so at the beginning of an initiative. For example, if a requirement is to be implemented three months into it, if you explore the details of that requirement at that point you have three months more domain knowledge than if you had done so at the beginning, therefore you can ask more intelligent questions.
- If you’ve been delivering working software on a regular basis your stakeholders now have three months worth of experience with the system that you’ve built. In other words, they can give you better answers.
- Modeling everything up front in detail appears to result in significant wastage. Yes, during iteration 0 you’ll want to do some initial requirements envisioning and some initial architecture envisioningbut that doesn’t mean you need to dive deep into the details.
Having said that, sometimes you’ll need to model complex requirements, or model legacy assets, a bit ahead of actually implementing them. This is actually a rare occurrence, regardless of what traditional modelers may hope for, but it does happen every so often.
Adopting Model Storming
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 is far more important to them than making software development teams effective. My advice is to not only have a lot of whiteboard space available to people, you also need to ensure that it’s 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, particularly when it”s ok to erase something. Your team culture is also critical to your success, it must be acceptable to ask people for help and in turn to be asked to model with others. You need to recognize that this is a normal and effective way to work. I can’t remember a team where we didn’t model storm, yet I also can’t remember reading a book or article which talked about this technique in any great detail. Wouldn’t it be nice if the IT industry could start talking about what we actually do in practice, instead of what we think we should be doing?