A modeling session is an activity
where one or more people focus on the development of one
or more models. Modeling sessions are an important part of any software
development effort because they provide an opportunity
for people to collaborate together in order to
communicate their needs, to come to a better
understanding, and ideally to work towards a solution.
Traditionally the effectiveness of modeling
sessions seems to range widely, from being very
productive to virtually useless.
My experience is that to make modeling sessions
effective you need to rethink your approach to them,
focusing on what works and excluding what doesn’t.
Let’s consider the following issues:
The duration of effective modeling
sessions often range from several minutes to several
days, with the majority of sessions lasting between ten
and thirty minutes.
Why such a wide range?
To answer this question you need to first
consider when modeling sessions occur – modeling
occurs throughout your entire development efforts.
It is important to understand that your focus
changes throughout the project lifecycle, at the
beginning of the lifecycle you are typically more
concerned with understanding “the big picture”, in
the middle of your lifecycle you are more concerned with
building specific parts of your system, and at the end
of the lifecycle your focus is on transitioning your
system into production.
This change in focus will motivate different
styles of modeling sessions, including different
durations, throughout your effort.
You are likely to hold longer,
modeling sessions at the beginning of the project
this phase of your project which there is a great need
to define the scope for the project and to set the
initial requirements, as well as to
based on those requirements. To
reach these goals you often find that you need to hold
initial modeling sessions that may take several hours or
even several days because you have a lot of ground to
cover at the start of your project. My experience is that modeling sessions of greater length
than two or three days puts your project at risk – the
longer you go without feedback the greater the chance
that what you are modeling does not reflect what
actually needs to occur in the case of requirements or
what will actually work in practice in the case of
implores that you to
reduce the time between modeling something and verifying
your model, either by reviewing it with someone else or
by following the practice
Prove It With Code.
Another issue with long modeling sessions is that
fatigue begins to set in among participants, modeling
can be a mentally draining activity, reducing the
quality of their work. Furthermore, the need of
participants to return to their regular jobs makes it
difficult for many participants to invest more than a
couple of days at a time.
Sometimes there is significant
pressure to have longer modeling sessions.
Many people will argue that you want to get
requirements identification over with as soon as
Embrace Change tells you that
this is a naïve goal at best because your
stakeholder’s understanding of what they need will
evolve as the system does.
Another common argument for longer sessions is
that key personnel are only going to be available once,
so you’d better take advantage of them while you can. Common justifications for this include the fact that some
people must travel great distances to attend your
modeling sessions or they are too busy to take time away
from their regular jobs to attend a series of sessions.
The travel issue can be dealt with by applying
alternative means of
such as videoconferencing and email.
The argument that someone is too busy to
participate is a red herring – it’s far easier to
schedule time for several small sessions than one large
will also argue that it’s a lot of work to organize
modeling sessions so therefore it’s better to have a
few large ones than a lot of smaller ones.
My advice is to loosen up a bit, make them less
formal and therefore easier to organize.
You are likely to hold short
modeling sessions, typically ten to twenty minutes in
length, during construction. I called these "model
storming" sessions because they are impromptu and
quick. At this point in time your focus is implementing specific
requirements, ideally “small requirement chunks”
(for more on this concept see Agile
What are examples of small requirement chunks? On
eXtreme Programming (XP) project you
would be implementing a user story, on a
Development (FDD) project you’d be implementing a feature, and on a
Rational Unified Process (RUP)
a portion of a use case.
You’ll be working very iteratively at this
point, working with your project stakeholder to explore
the pertinent requirements, perhaps creating an
essential UI model or discussing the logic of a business
rule, then moving forward to discuss a potential
solution for that requirement, often creating a
whiteboard sketch to facilitate the discussion, and then
moving on to code and test the solution.
Agile developers iterate quickly between these
steps, modeling requirements with their project
stakeholder(s) for a few minutes and then modeling the
potential solution for a few minutes (ideally in a small
group of two or three developers following the practice
With Others). When
you work on small requirement chunks and proceed
iteratively you quickly discover that short modeling
sessions are sufficient.
How do you keep a modeling session
Prefer stand-up modeling sessions around a
plain old whiteboard (POW) or
table because most people are only willing to stand up
for short periods of time.
Make it a habit to hold short modeling
sessions, therefore when they go longer people will
start to feel uneasy about it.
Keep the modeling session focused on a
single topic, one of the advantages of working on a
single small requirement chunk at a time.
Stop modeling once you’ve fulfilled
your goal as the principle
Model With a Purpose
A common problem that I see again
and again is something that I call “single artifact
modeling sessions”, so common in fact that I’ve been
tempted to write it up as a process anti-pattern.
Common examples of single artifact modeling
sessions, when you take them at face value, include
use-case modeling sessions, data modeling sessions, and
even class modeling sessions.
The problem is that the modeling effort is too
narrowly focused, although each one of those artifacts
are important in their own right they simply aren’t
robust enough to be effective.
I’ve seen use case modeling sessions that
produced bloated use cases because the team started to
record business rules, technical requirements, and even
information about domain entities in their use cases
because they didn’t consider working on other
seen data modeling sessions that resulted in what
appeared to be a great data model, at least at first,
but that eventually proved to need significant
refactoring – the data modelers focused only on
data-related issues and didn’t consider critical
behaviors because “that was something the application
programmers would worry about.”
Similarly I’ve seen class modeling sessions
produce models that resulted in horrendous performance
because the object modelers chose to ignore database
object-oriented analysis and design (OOA&D)
methodology was based strictly on the UML, the industry
standard, and because it still doesn’t include a data
model they ignored these critical design issues.
Besides, they felt that was something that the
data administrators would deal with.
Why do single artifact modeling
sessions occur? Many
times they are driven by people who exhibit the
“single artifact developer” anti-pattern, developers who focus on a single artifact such
as use cases, data models, or class models.
When this is your focus, naturally it makes sense
to you that you should have modeling sessions whose
focus is the creation of that single artifact.
This clearly goes against the tenets of AM, which
tells that you need Multiple Models in your
intellectual toolbox, that you should
Models In Parallel.
A better approach is to hold what I
call phase modeling sessions, a modeling session where
your focus is on creating models pertinent to the major
phases of traditional development such as requirements,
analysis, architecture, and design.
In requirements modeling sessions your focus
would be on defining what your project stakeholders want
your system to do, analysis modeling sessions focus on
fleshing out the requirements, architecture modeling
sessions focus on identifying a high-level strategy for
how your system will be built, and design modeling
sessions focus on identifying a detailed strategy for
building a portion of your system. In each of these
modeling sessions your team works on several models at
once, as appropriate to the phase. For example, in a design modeling session you may work on UML
class diagrams, UML state charts, and physical data
that teams following the RUP may want to consider these
workflow modeling sessions to stay consistent with RUP
|The best approach is simply to hold
agile modeling sessions.
Agile software development is highly iterative,
particularly on a day-to-day basis, where it is quite
common to identify a requirement, analyze it, and
propose a potential design strategy within minutes if
not seconds. My
experience is that this is the way that people actually
work, including both developers and stakeholders.
For example, when a stakeholder tells me that
they need to maintain the surface address for their
customers I quickly start thinking about changing the
design of the customer editing screen, adding a new
class called SurfaceAddress that the Customer class will
interact with, and then making changes to my database on
the back end to support this new requirement. Within seconds I go from thinking about requirements through
analysis and then to design.
From the project stakeholder side of things I
have often run across stakeholders who not only had a
requirement but also had a strategy for fulfilling that
requirement, it’s common for power users that work
with both the system and who create ad-hoc reports from
the database to have ideas about how things should be
this case the power user is jumping from requirements
straight to design.
Yes, it’s not the role of your stakeholders to
determine how a system should be built, that’s a
responsibility of developers (see Active
Stakeholder Participation), so you’ve got an issue
to deal with in this situation.
If this is the way that people actually work,
they quickly iterate between phases, then doesn’t it
make sense that your software process reflect this fact? This is where agile modeling sessions come in.
In an agile modeling session you apply the
practices of AM, and in particular you
Models In Parallel, you
Apply The Right
Artifact(s) as needed, and you
Iterate to Another
Artifact as needed.
An agile modeling session is one where you model
requirements when you need to, where you model your
design when you need to, and so on. Yes, you still want to consider requirements issues, analysis
so on when you are modeling, it is just that you will be
iterating back and forth between them.
My advice is to never have single
artifact modeling sessions, even if your intention is in
fact to work on several artifacts at once.
This can be hard in some organizations,
particularly those that have been following traditional
approaches in the past and therefore may be predisposed
to highly-specialized efforts such as data modeling
session or organizations that have bought into the
“use-case driven” marketing rhetoric that dominates
object-oriented development methods right now.
Phase modeling sessions are often advisable at
the beginning of a project when fundamental issues such
as the scope of the effort and what should your
architecture be are yet to be determined.
They are also appropriate when you are first
adopting agile software development practices and your
organization is still struggling with the inherent
cultural changes required to do so – phase modeling
sessions may be a palatable baby step away from single
artifact modeling sessions.
Agile modeling sessions are common for short
modeling sessions during construction as well as for
teams experienced in agile software development when
they hold longer modeling sessions that are common at
the beginning of a project.
There are two categories of roles
in modeling sessions: active participants and supporting
participants. The active participant category contains three basic roles:
Project stakeholders who are there to provide
information about the business and to help prioritize
requirements; analysts who specialize in working
directly with project stakeholders to potentially
gather/elicit information from them, document that
information, and/or validate that information; and developers
who are there to work on the models.
Active participants are first-class modeling
citizens, they are the ones doing the “real work” of
modeling, they are the ones who are critical to the
success of your project.
You need to be careful with how you
involve analysts, sometimes known as
or requirements analysts, on your project.
Although they specializing in working with
project stakeholders, clearly a very good thing, and can
often prove adept acting as a bridge between project
stakeholders and hard-core developers whose
communication skills may be lacking, the can also act as
a barrier to project productivity.
The problem is that when a business analyst is
involved on a project many developers will choose to use
them as a crutch, to let the analyst focus on working
with stakeholders and thereby freeing themselves up to
focus on the technology.
This isn’t very good, what you really want is
developers interacting closely with project stakeholders
and applying their technical skills to build the
In AM there are two primary ways that analysts
can be effective. First,
in situations where the developers are co-located with
project stakeholders the analysts can help to build
initial rapport between stakeholders and developers and
mentor the developers in communication and modeling
the same time the developers should mentor the analysts
in the technology, remember the principle Everyone
Can Learn from Everyone Else, to make them more
effective. Second, when your team does not have ready
access to project stakeholders, clearly a serious
problem that threatens your likelihood of success, they
can gather information from project stakeholders for the
developers and present that information in a format that
the developers need.
The problem with this is that you are introducing
an opportunity for information to be distorted and
misinterpreted by not having direct communication.
Think back to the “telephone game” that you
used to play as a child where one child whispered a
message to another, who then whispered that message to
another, and so on until it got back to the original
more people in between the greater the distortion.
The supporting participant category
encapsulates three roles: facilitator, scribe, and
modeling sessions work perfectly well without anyone in
these roles, particularly
model storming sessions when people are modeling to understand a portion of
the system that they are working on.
However, larger modeling sessions,
ones early in the project, will often have people
fulfilling these roles.
Let’s explore them in detail:
A facilitator is someone who is responsible
for planning, running, and managing modeling
sessions. As a result facilitators have good
meeting skills, they understand the modeling
process, and they ask valid, intelligent questions
to elicit information from the active participants. The role of facilitator is often taken up by the coach, an XP
role, or team-lead of your project – this is a
senior person that the developers and stakeholders
should trust and respect and who should have good
communication and modeling skills.
Large organizations may have professional
meeting facilitators on staff that are typically
used for more formal modeling sessions, as discussed
advantage of professional meeting facilitators are
that they are very thorough and good at their jobs,
the major disadvantage is that they are often better
suited for prescriptive processes and may need some
coaching in agility.
Although smaller and/or informal modeling
sessions may not have a designated person whose only
role is to facilitate there still needs to be
someone(s) responsible for ensuring that the
modeling session is run effectively.
A scribe is a person responsible for
recording information during a modeling session.
As a result scribes need good listening skills, good
oral communication skills (they will often need to
ask questions to determine exactly what the active
participants mean), and they have an ear for
business logic and technical details.
There are two schools of thought regarding
who to put in the scribe role: a professional
scribe, often a technical writer, or a developer. I prefer putting a developer in that role, both to help grow
them as communicators as well as to ensure that they
are actually picking up what is being discussed.
It can be a good lesson in humility to hear a
user tell you what they actually want and how they
actually work with your software, as opposed to the
really neat features that you mistakenly believe
they can’t wait to receive. To be fair, and to ensure that everyone on your team has the
opportunity to improve their skillset, you should
make this role a rotating one that an individual
Finally, if you’re going to have scribes in
your modeling sessions, you may decide to simply
record all information in the models that you are
creating, then you are best to have two or even
three people scribing – you can’t write as fast
as several people can talk, and because each person
has their own unique background they will pick up
(as well as miss) different types of information.
Traditionally an observer
is someone who is not there to participate in a
modeling session but instead is supposed to sit back
and watch what occurs so that they can learn the
they are a facilitator in training or they are
involved with an upcoming project that wants to take
the same approach that your team is following.
Someone who sits there and does nothing? That doesn’t sound right.
A more agile approach is to put
“observers” to work, as active participants if
they have domain knowledge or modeling skills or
worst case as scribes.
The goal of an observer is to learn the
process, and the best way to learn things is through
hands-on experience, therefore by having them
involved with the modeling session not only do you
increase the number of people actually adding value
in your modeling session you also improve their
Two birds, one stone.
How many people should be involved
with a modeling session?
Just barely enough.
Every single person should have a valid reason
for being there, not just a political reason such as
“Sally Jones insists that someone from her group
Sally Jones provides someone then they should come to
the modeling session prepared to work, and be willing to
follow through on any action items that they are
assigned during the modeling session such as obtaining
more information or being involved in a follow up
effort. There is often significant political pressure for too many
people to be involved in a modeling session,
particularly at the start of a project, pressure that is
hard to counteract.
I will very often hold a large requirements
gathering session at the beginning of a project that has
way too many people, twenty or thirty people in these
meetings are common although sometimes you can have
several hundred people in some situations, just to let
everyone know that their voices are being heard as well
as to help identify the handful of project stakeholders
that can actually contribute something of value.
I’ll also do the same thing when it comes to
architecture, involving a wide range of technical people
throughout the organization.
The problem is that there are diminishing rates
of return once you’ve reached groups of seven or eight
people – there is less of a
chance that a new person will bring new information to
the group, assuming you’re picking participants in an
intelligent manner, and there is less opportunity for an
individual to actively participate because you are
dividing the amount of “air time” between a greater
number of people.
First and foremost, just because a
modeling session is formal it doesn’t mean that it is
necessarily less agile.
Yes, formality has a bad reputation among many
developers but that doesn’t mean that a formal session
cannot be an effective one.
At one end of the spectrum you have very formal
modeling sessions such as Joint Application Development
(JAD) sessions. A JAD is a facilitated
and highly structured meeting that has specific roles
(facilitator, participant, scribe, and observer),
defined rules of behavior including when to speak, and
suggestions for room organization (typically a U-shaped
a JAD it is common practice to distribute a well-defined
agenda and an information package which everyone is
expected to read. Official
meeting minutes are written and distributed after a JAD,
including a list of action items assigned during the JAD
that the facilitator is responsible for ensuring are
At the other end of the spectrum are ad-hoc
modeling sessions where the impetus for having them is
often the realization that you need some help.
People are quickly gathered, hopefully the
“right” people are readily available, you work
together, and once you’re done you quickly disband.
The formality of modeling sessions
can be anywhere in between these two extremes.
Table 1 suggests when each
style may be applicable.
Because your immediate needs often include
applicability factors from each type of formality you
need to decide how formal to make your session.
For example, how formal would you want to make a
ten-person, half-day modeling session where all ten
people work at the same physical location and can be
scheduled within a two-day notice?
How about a five-person, two-day modeling session
where two people need to fly in from another location?
The answer is the same for both situations: just
formal enough. The
greater the formality the more work you need to do to
hold the modeling session, and according to the
maximize stakeholder ROI any
work that you do should have positive value for your
an agenda if it will help people to prepare properly for
the session, don’t forget that your agenda could be as
simple as an email.
Distribute meeting minutes if appropriate, it
could be as simple as an email listing point-form action
items assigned to individuals and an URL pointing to a
web page of digital pictures of the diagrams that you
created during the modeling sessions.
Create Simple Content
applies to management artifacts as well as models.
When Each Formality Style is Applicable.
Modeling Session Style
Formal (e.g. JAD)
Large groups (> 8
Long modeling sessions (>
1 day is typical)
Participants from different
Participants from different
organizations or organizational areas
Project has ability to
tolerate increased time required of formal
Regulatory requirement to
hold formal modeling sessions
Informal (e.g. ad-hoc)
Smaller, co-located groups
People are readily available,
willing, and able to participate
Shorter modeling sessions
(<one hour is typical)
Time-to-market a critical
factor for your project
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2 is an
important reference book for agile modelers,
describing how to develop 35
types of agile
models including all 13
UML 2 diagrams.
Furthermore, this book describes the techniques
Full Lifecycle Object Oriented Testing
(FLOOT) methodology to give you the fundamental
testing skills which you require to succeed at
agile software development. The book also
shows how to move from your agile models to
source code (Java examples are provided) as well
as how to succeed at implementation techniques
(TDD). The Object Primer also includes a
chapter overviewing the critical database
development techniques (database refactoring,
legacy analysis, and
database access coding) from my award-winning
Agile Database Techniques
Agile Modeling: Effective Practices for Extreme
Programming and the Unified Process is the seminal
book describing how agile software developers approach
documentation. It describes principles and
practices which you can tailor into your existing
software process, such as
Rational Unified Process (RUP), or the
Agile Unified Process (AUP), to streamline your
modeling and documentation efforts. Modeling and
documentation are important aspects of any software
project, including agile projects, and this book
describes in detail how to
architect, and then
design your system in an agile manner.
The Elements of UML 2.0 Style describes a collection
of standards, conventions, and
for creating effective
UML diagrams. They are based on sound, proven
software engineering principles that lead to diagrams
that are easier to understand and work with. These
conventions exist as a collection of simple, concise
guidelines that if applied consistently, represent an
important first step in increasing your productivity as
a modeler. This book is oriented towards
intermediate to advanced UML modelers, although there
are numerous examples throughout the book it would not
be a good way to learn the UML (instead, consider
The Object Primer). The book is a brief 188
pages long and is conveniently pocket-sized so it's easy
to carry around.
We actively work with clients around the world to
improve their information technology (IT) practices,
typically in the role of mentor/coach, team lead, or trainer. A full
description of what we do, and how to contact us, can be
found at Scott W.
Ambler + Associates.