Agile Modeling in Teams

Software development is a lot like swimming--it's dangerous to do it alone. Experience shows that modeling is best done by groups of people to gain a diverse range of input. This, in fact, is one of the motivating factors of Agile Modeling (AM)'s "Model With Others" practice. Let's examine the three styles of modeling teams:

1. Development pairs. Many agile software development teams adopt the practice of having developers work together in pairs. In fact, pair programming is an explicit XP practice, and this includes modeling in pairs, as well. It is quite common for you and your development pair to discuss an idea or approach by working on a model together, perhaps creating a sketch on a whiteboard or writing a few CRC cards. These modeling efforts typically last for several minutes and result in a temporary model that's soon discarded in favor of source code.

Although pair development may appear less than productive because two people seem to be doing the job of one, this approach is actually quite effective. Studies, such as "Strengthening the Case for Pair Programming" by Lauren Williams, Robert R. Kessler, Ward Cunningham and Ron Jeffrie (IEEE Software, July/August 2000), have shown that pair development results in greater consistency, efficiency, quality and job satisfaction among developers. My own experience is that pair development works--I've found that although many people will be skeptical at first (good for them!), with a month-long trial, the vast majority will be exceptionally reluctant to go back to their old "single developer" ways.

2. Small impromptu/ad hoc teams. An impromptu or ad hoc modeling team is one that is put together quickly, often in a matter of seconds, to address a specific issue; having done so, it just as quickly disbands. Agile developers will often form small ad hoc modeling teams, often composed of two or three people, when they realize that they need help with what they're working on. Perhaps they require more information about the business domain from a project stakeholder, or need technical help from another developer. It's easy to put together an ad hoc modeling team when your development team is co-located--when you know who's the best person to work with, you can simply walk over to her and ask for help--and when you don't know who can help, you simply shout out something like "Does anyone know anything about XYZ?" It's much harder to put together a distributed ad hoc modeling team because it takes longer to identify who can help you, it becomes difficult to work together because you need to either communicate at a distance via e-mail or phone, or you need to wait until you can meet physically.

3. Designated modeling teams. Sometimes you'll have designated teams of people who are brought together specifically to model. At the beginning of a project, you may decide to have a requirements modeling session in which you gather a group of users to help identify initial system requirements and to determine your project's scope. Individuals are assigned to a modeling team, the team fulfills its task over one or more modeling sessions, and eventually the team disbands. Yes, some of the users may become involved with the project on a full-time basis in the role of "customer" or "user representative," but that's a different issue. It's common to have a designated architecture team for a project, often comprising all the developers on small project teams or a subset of developers on large project teams.

On agile software development projects, small teams, either development pairs or small ad hoc teams, perform the vast majority of modeling. This makes a lot of sense: Ad hoc modeling efforts fit well with the highly iterative and incremental agile approaches. Furthermore, many agile developers, particularly those on Extreme Programming (XP) teams, choose to work in pairs because they find this method very effective. However, important work still occurs in designated modeling teams at a project's onset; such groups must gather initial requirements and perform initial architecture or design modeling, and are more likely to hold more formal modeling sessions than pair modelers or ad hoc modeling teams do.

Recently on the Agile Modeling Mailing List:

Iterative vs. Incremental. An interesting discussion started regarding the definitions of the terms "iterative" and "incremental." Iterative development is a nonserial approach in which you're likely to do some requirements definition, some modeling, some programming and some testing on any given day. Incremental development is an approach that organizes a project into several releases (potentially internal ones) instead of a single "big-bang" release. Part of the confusion in the industry was attributed to the Rational Unified Process (RUP)'s use of the term "iteration" where "increment" would have been far more accurate.

Logical Data Modeling. A discussion regarding the appropriate use of logical data models (LDMs) spilled over from a data modeling mailing list into the AM mailing list. Many data modelers see LDMs as a core model in the data world, preferring to use them for conceptual and domain modeling activities at both the project and enterprise level. Object and component developers certainly didn't see things this way, preferring to use Class Responsibility Collaborator (CRC) cards or UML class diagrams for such activities. In the end, agile modelers will follow the practice Apply the Right Artifact(s), using LDMs only when they are the best option, which is often the case when building a data-rich system such as a data warehouse, but isn't the case for object-oriented or component- based software systems. More on this issue in a future Agile Modeling Newsletter.

Increased Popularity of Software Process. In January, I spoke at the OOP 2002 conference in Munich, Germany. Several people noted that process-related talks, particularly those discussing XP, RUP and AM, were very well attended. Does this indicate a major shift in the industry, suggesting that software professionals are finally interested in techniques over technologies? Time will tell.

Recommended Online Resources

Agile Modeling Mailing List.
http://www.agilemodeling.com/feedback.htm

Cetus OO Links Page
http://www.cetus-links.org/
This portal has a very large collection of links to OO modeling white papers.

Enterprise Application Architecture
The home page for Martin Fowler's upcoming architecture book can be found at http://www.martinfowler.com/isa/index.html

Modeling Style Web Site
http://www.modelingstyle.info/
This Web site, a work in progress, presents a collection of pages that describe techniques for creating effective UML artifacts such as use case and class diagrams.

Misconceptions About XP by Ron Jeffries
http://www.xprogramming.com/xpmag/Misconceptions.htm
This is an interesting essay that identifies and addresses many of the misconceptions that you may have about XP.

Pair Programming Site
http://pairprogramming.com/
This Web site is the starting point if you want to learn more about pair programming; the site includes the results from studies showing that pair programming is more effective than developing alone.