Introduction

This series has explored the benefits of agile processes and the requirements placed on the organizations that use them. You've learned how organizations adapt to agile development, about the different types of stakeholders, and how to apply user stories. You've walked through a case study and have seen how user stories, discussion, and prioritization can lead to quickly developed beta versions. You have reviewed how customer incentives, behavior, and the pricing models of a project each have an effect on the current and future success of a development project. And, you've learned about estimating work effort in an agile environment.

This article discusses modeling related to agile development. Learn about misconceptions of agile modeling, what a good agile model entails, choosing tools, and selecting the model to best fit your goals.

Back to top

What modeling is not

There are many misconceptions about software modeling, and about where and how you can use it. Before discussing useful agile models, this section outlines some misconceptions, or non-truths, about software modeling.

The models are the documentation.

This is a common misconception. Some folks think that if they do a few models, then that's that. There is a lot of information that is outside the scope of UML diagrams, for example, or information that could be better explained as narrative text. Screen layouts, detailed GUI design, screen flows, overview documents, and marketing documents can all give insight to the development team. Models alone aren't adequate for documentation, though they are an important component.

Modeling is slow and not agile.

If you're not used to modeled software, you might think it's time-consuming, slow, and difficult. The most important thing to remember in this context is that when you model, you should always try to design the software (not just draw diagrams that you think are required).

You model to plan and design the important parts of the application. Modeling is not for skipping communication, or in place of developing as a team. Modeling is very powerful when you use it together in pairs or on teams. Different elements of UML are very helpful while you're discussing how to implement features and how to ensure sound design. For example, the designers could all gather in front of a blackboard and discuss the design with the help of the models.

You need all the requirements to start modeling

Some people think that you can't start modeling before you have all the requirements. A key element of modeling is that you should only model the essentials. There's no point in modeling something that is not challenging, or modeling something that's obvious to everyone. You can start modeling as soon as you have some of the basic elements of the system.

If you've chosen agile methods, you've already acknowledged that the requirements will change, and that the application will change over time. The requirements and the application represent the business and its requirements at a certain time. Three months later, they might be different. If you do your modeling with only the essentials, you don't have to change too many details when things change. When new requirements cause changes to the model, they are major changes to the application and should be planned carefully.

You need a case tool to model.

You don't need an expensive case tool. These days you can get a pretty good case tool for free as open source, or the community version of a commercial tool. You don't even need a tool, though. You can model with pen and paper. Sure, it's more difficult to make changes or distribute the models to other locations. But by drawing and discussing models, you'll gain more than with no models at all.

Modeling is a waste of time.

You might hear this from people who are not very confident in modeling. The key, remember, is to model only the essentials. When you model the essentials, elements, and design issues that need to be solved and communicated will come to light, so the work is not in vain. As the software grows and gets more complicated, it's good to have models that the team can return to.

Back to top

Agile models

Useful agile models have several characteristics. Models should:

Be needed

First and foremost, someone should need the models and the information or design decisions they contain. There's no use creating and maintaining something that nobody needs.

If you're working on the first iteration of the software and the database contains only one table, you might think you don't need a model. However, the database will get more complicated over time. Why not create the basis for the model when you create the database? It won't take long.

Have a purpose

For example, if you have a class diagram of your interfaces, it should be clear and easy to understand by the people who are figuring out how to do integrations to your software. The model should not contain more information than is needed, either. If you want to model more design issues, you can always create a new diagram.

Be adequately detailed

But not too much. If you have a class diagram with just the names of the classes, but with no connections between the classes, it is hardly of any use. If you have a sequence diagram that's four pages wide and has all the minor actions shown, that might be a bit too much information for that purpose.

Be understandable

Information should be understandable to the users of the model. Include enough so the users understand the core ideas behind the model. On the other hand, don't include things that are obvious to the users. Reading a model that contains a lot of things that you already know is annoying and wastes time.

Be accurate enough

With emphasis on enough. Sometimes developers keep polishing and polishing the models, as if they're scared that one missing piece of information or one typo would make the model worthless. That is not true. You shouldn't worry about missing little things as long as the bigger things are there.

Back to top

Doing agile modeling

As mentioned, you don't need a case tool to model. Paper, cartoon, flip chart, or something similar are adequate. Gather the team together in front of the flip chart, then draw, discuss, and design. When you're finished, draw the design on paper or take a photograph of it.

If you decide to use tools, you can overcome some of the obvious problems with designing on paper. There are plenty of tools available in different price categories. The more expensive tools typically have more support and features for working as a group. Most case tools have a simple version for free or for a trial period.

While you model, think about the users and the purpose of the model, then choose the tools accordingly. Class diagrams are very efficient if you want to show what the classes and components are for and how they're connected in the static software. Sequence and state diagrams are powerful if you want to show how classes interact during run time.

Consider a Web store shopping cart example. The short description of the functions might be: Users (typical user, corporate user, or sales representative) add a new item to the shopping cart, and might get a special price according to their shopping history or role. With a use case diagram, you can highlight the three users of this function and their relationship to the use cases. The sales representative, for example, would have access to selecting the discount rate; the customers would get the rate according to their shopping history. The users of the diagram can see the necessary relationships of the users and their actions, and nothing else. This would keep the diagram simple.

As you continue developing the software, you might add the other use cases related to shopping carts. With a class diagram you can show the static connections of the classes involved and their major roles (ShoppingCart, Item, Session, and so on). With a sequence diagram you can show how the classes work together during run time (product page calls shopping cart to add new item).

You should think about the types of models that best fit the functions you want to design. Never do a state diagram just because you think you need to; do it if it's the best way to show that information.

Your model will continue to build up as you develop the software. Sometimes you need to make major changes to the diagrams, and sometimes you just add new methods to the classes and new calls to sequence diagrams.

It's important to do the modeling in teams if at all possible. You want to ensure that all the good ideas are brought to the modeling process. Another advantage of a team effort is that the team members are more likely to take collective ownership of the model—it won't be just "the thing that Frank did." Teamwork improves the quality and can help you easily get rid of silly mistakes early in a process.

It is beneficial to talk about your thoughts with your customer (either internal or external), and explain what it is you're doing and how you're going to do it. Of course, you have to take into account the level of the customer. For some, the screen layouts and screen flows are best, and others might like to see the interfaces and more technical aspects.

Back to top

Conclusion

In this column you learned about agile modeling by discussing misconceptions and characteristics of good agile models. Lots of bells and whistles are not necessary when modeling. A simple ink drawing on paper may suffice in some situations. Teamwork is key during the actual modeling. The team should carefully select the type of diagrams that best fit your purpose.

Modeling improves the quality of the software by making communication easier, easing integrations, and ensuring that development decisions are carefully thought through. And if you do it effectively, it won't take as much time as you might think.

Resources

Learn

• Check out the other parts of this series on adopting agile development:
  • Part 1, "Is agile development right for your organization?" (developerWorks, Mar 2008)
  • Part 2, "Understanding the different facets" (developerWorks, Apr 2008)
  • Part 3, "The role of agile stakeholders " (developerWorks, May 2008)
  • Part 4, "Using user stories to define project requirements" (developerWorks, Jun 2008)
  • Part 5, "Applying user stories in a Web-based financial planning tool" (developerWorks, Jul 2008)
  • Part 6, "The buyer's viewpoint" (developerWorks, Sep 2008)
  • Part 7, "Methods for estimating work effort in agile development" (developerWorks, Nov 2008)
  
  
• Agile Software Construction, a comprehensive guide to the most popular current agile methods, also discusses modeling.
  
  
• Agile Modeling offers modeling methodology and other useful information.
  
  
• Read Wikipedia's discussion of Scrum.
  
  
• Read more about Scrum, and Adaptive Project Management Using Scrum.
  
  
• Browse the technology bookstore for books on these and other technical topics.
  
  
• In the Architecture area on developerWorks, get the resources you need to advance your skills in the architecture arena.
  
  
• Find resources to help you architect enterprise and software systems in free IT architecture kits from IBM.
  
  
• Stay current with developerWorks technical events and webcasts.
  
  

Get products and technologies

• Download IBM product evaluation versions and get your hands on application development tools and middleware products from IBM® DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
  
  

Discuss

• Read what everyone is talking about in developerWorks blogs and get involved in the developerWorks community.
  
  
• Check out Scott Ambler's blog - Strategies for Scaling Agile Software Development.
  
  
• Participate in the IT architecture forum to exchange tips and techniques and to share other related information about the broad topic of IT architecture.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• Introduction
• What modeling is not
• Agile models
• Doing agile modeling
• Conclusion
• Resources
• About the author
• Comments